View previous topic :: View next topic |
Author |
Message |
dDelage
Joined: 10 Sep 2022 Posts: 20
|
Moving Program location |
Posted: Sat Sep 10, 2022 3:08 am |
|
|
I have a program that compiles without errors. Using a ICD-U64 (2 units), either on 5V or 3.3V, across 2 (Win10 and Win11) computers and 3 devices (powered by the ICD-U64 or with added board power) I get the same errors at 0101, 0102, 0103 (a serial port data interpreter) and 2100 and 2103 (user variables). It then tells me that the chip has not been erased but erase and check blank return ok and re-burn produces the same errors.
All apps are at their most recent releases. Using PIC16F18555. ROM 38%, RAM 17%.
I'm down to thinking the chips are bad. But it occurred to me that perhaps I could move the code higher in memory to get around a bad spot.
Is there a way to do this? Open to trying anything at this point.
Thanks |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19520
|
|
Posted: Sat Sep 10, 2022 10:11 am |
|
|
You can move where a particular function locates, with #ORG.
Best thing though, would be to use this to generate a dummy function,
that is set to occupy the area you don't want code to go into. Then the
compiler will automatically move other stuff around this.
So:
Code: |
#ORG 0x100, 0x110
void dummy(void);
#ORG DEFAULT
|
Should mean the compiler will not use the area 0x100 to 110 for anything. |
|
|
dDelage
Joined: 10 Sep 2022 Posts: 20
|
Moving Program location |
Posted: Sat Sep 10, 2022 10:14 am |
|
|
Thanks for the quick reply! Busy today with other stuff but that sounds exactly what I need to try. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sat Sep 10, 2022 12:52 pm |
|
|
What are you using to do the programming ? Are you using CCSLoad or
the CCS IDE ?
Do you have this option selected: "Bulk erase chip before programming" ? |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19520
|
|
Posted: Sun Sep 11, 2022 1:43 am |
|
|
I'm puzzled by this comment:
"2100 and 2103 (user variables)"
2100 in hex, is not a legitimate address on this chip. The top of program
memory is 0x1FFF. 'Variables' are not programmed anyway, they are stored
in RAM, not the program memory.
Puzzled... |
|
|
dDelage
Joined: 10 Sep 2022 Posts: 20
|
Moving Program location |
Posted: Mon Sep 12, 2022 11:45 am |
|
|
#ORG 0x100, 0x1000 {}
Fixed that issue, lots of room left for the remaining code.
With respect to the 0x2100 result, these are factory defaults some of which can be changed by the user from a management program and some by the factory using hidden keystrokes to set the options that you pay for. The line is
#ROM 0x2100 = {0x1c,0x0a,0x02,0x0f}
Is that a problem?
Thanks,
Dave |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19520
|
|
Posted: Tue Sep 13, 2022 3:34 am |
|
|
Yes.
0x2100, is the location for the internal chip EEPROM on old chips like the
16F877. It is not the location for this in your chip.
On your chip it is 0xF000.
Your chip does not have any memory at 0x2100....
Best thing always is to use GETENV to locate things like this. So:
#rom getenv("EEPROM_ADDRESS")={0x1c,0x0a,0x02,0x0f}
Which will then put the configuration into the EEPROM whatever chip you use.
This is why you are getting the errors here.
This might even be the cause of the other errors. The programmer trying
to write to the non-existent location may be damaging the contents
around 0x100. |
|
|
dDelage
Joined: 10 Sep 2022 Posts: 20
|
Moving Program location |
Posted: Tue Sep 13, 2022 8:52 am |
|
|
Thank you, thank you. Clear, concise, and very helpful. Just got on the computer to do the rest of the debugging, looks like a good day.
Please feel free to take the rest of the day off!
Dave |
|
|
|