Page 1 of 1

ID Locations

Posted: Mon Oct 10, 2011 1:08 pm
by dbasnett
From the data sheet for PIC18F2480/2580/4480/4580;

"ID Locations
Eight memory locations (200000h-200007h) are
designated as ID locations, where the user can store
checksum or other code identification numbers."

How can these be accessed via FlowCode?

Re: ID Locations

Posted: Mon Oct 10, 2011 3:06 pm
by Steve
Either use #pragma data (see the BoostC help file) or use the PPP utility to add the ID locs data after the HEX file has been created.

Re: ID Locations

Posted: Mon Oct 10, 2011 8:58 pm
by dbasnett
How do you read those locations?

Re: ID Locations

Posted: Tue Oct 11, 2011 9:33 am
by Steve
You can read back the HEX file (using PPP or similar).

If you want to read back while the program is running, then only some chips allow this. Look in the datasheet for the chip for more info (usually in the "Special Features of the CPU -> ID locations" section). For example:
16F877a datasheet wrote:14.17 ID Locations
Four memory locations (2000h-2003h) are designated
as ID locations, where the user can store checksum or
other code identification numbers. These locations are
not accessible during normal execution but are
readable and writable during program/verify. It is
recommended that only the 4 Least Significant bits of
the ID location are used.
18F4455 datasheet wrote:25.6 ID Locations
Eight memory locations (200000h-200007h) are
designated as ID locations, where the user can store
checksum or other code identification numbers. These
locations are both readable and writable during normal
execution through the TBLRD and TBLWT instructions
or during program/verify. The ID locations can be read
when the device is code-protected.

Re: ID Locations

Posted: Tue Oct 11, 2011 11:09 am
by dbasnett
So using the C code component is the way to read the locations?

Re: ID Locations

Posted: Tue Oct 11, 2011 1:37 pm
by Steve
Yes - and this will only work for selected chips.

Re: ID Locations

Posted: Fri Oct 14, 2011 1:39 pm
by dbasnett
Added this to the supplementary code

#pragma DATA 0x200000, 68,101,119,97,121,110,101,66

and received the following error:



Sending program...
Erasing the PICmicro
NOTE: EEPROM data will also be erased!
Writing program memory

...

Writing EEPROM memory
Writing configuration memory
Writing id-locations
Reading program memory
Reading configuration memory
Reading data memory
Finished reading PICmicro contents
Programming failed:

Data memory check failed

(NOTE: if the PIC is code-protected, this message will be
displayed even if the program has been sent correctly)
That took 4.072 seconds

Return code = 0

FINISHED


This does not appear to affect the operation of the actual code. I did notice that the ID location in the Expert Config of the chip is NOT the address above.

Re: ID Locations

Posted: Fri Oct 14, 2011 4:11 pm
by Steve
This seems correct, so I don't know why it is failing. Is there anything else in your program other than the #pragma line?

Re: ID Locations

Posted: Fri Oct 14, 2011 7:38 pm
by dbasnett
Yes, here is the entire supplementary code:

//Definitions and function declarations:
//======================================

#pragma DATA _EEPROM,0,255,"Copyright - acme.com, 2011",255,255
#pragma DATA 0x200000, 68,101,119,97,121,110,101,66

//Function implementations:
//=========================

I did notice in the expert config of the chip(18F4580) that it has different ID locations defined (0x3FFFFE) in the Misc. section.

Re: ID Locations

Posted: Mon Oct 17, 2011 8:41 am
by Steve
The "ID Location" setting at 0x3FFFFE is the location of the built-in read-only ID of the chip (i.e. it identifies the chip type and revision). This is not the same as the User ID Locations.

Are you able to program the ID Locations using PPPv3 directly? I've tried with an 18F4455 chip and it seems to work. Also, programming this chip's EEPROM memory and ID Locations via Supplementary Code seems to work fine too.

I've also tried the same thing with an 18F4580 device and it has worked fine. I can only assume your chip is broken.
ScreenShot001.png
(99.36 KiB) Downloaded 1155 times

Re: ID Locations

Posted: Mon Oct 17, 2011 12:29 pm
by dbasnett
Using PPP the data on the chip looks fine but gives the same error. Could this be caused because I modify an EEprom location, via code, as soon as the code runs?

Re: ID Locations

Posted: Mon Oct 17, 2011 1:46 pm
by Steve
No - it should be totally independent of the program running in the PICmicro.

Re: ID Locations

Posted: Tue Oct 18, 2011 1:53 pm
by dbasnett
Defective chip seems like the answer, but other than the download to the chip all seems well.

I have attached the hex file and hope that you can download it to a 4580 and see if you get errors.

If you attach a EB004 to Port D the program should toggle D3 of the EB004 once per second. Thanks.

Re: ID Locations

Posted: Tue Oct 18, 2011 4:47 pm
by Steve
The problem with the HEX file seems to be with the EEPROM data. If I change the first character of the EEPROM memory data to 0x7F (instead of 0x80), then it works fine. It looks like for the first location, the top bit needs to be clear. I really don't know why this is the case!

Re: ID Locations

Posted: Tue Oct 18, 2011 8:39 pm
by dbasnett
I tried 127 and 64 for the first byte of the EEPROM data and still had the same error.

I have attached the new hex file(64 as first byte of EEPROM). Thanks for your help.

Re: ID Locations

Posted: Wed Oct 19, 2011 9:03 am
by Steve
I'm sorry, but I do not have the time to deal with this at the moment. We are very busy with developing Flowcode V5 and I have already spent a few hours on this issue.

To help you solve this, you should try producing programs without data memory and/or ID location data to narrow down the problem. It does seem strange though that you are getting different results to me.

Re: ID Locations

Posted: Wed Oct 19, 2011 2:24 pm
by dbasnett
Removing the supplementary code clears the error. As I have said the error does not seem to impact the operation or correctness of the data that is loaded. When things calm down I hope you have time to investigate this further. A lot of us are looking forward to v5. Good luck.