 |
 |
| View previous topic :: View next topic |
| Author |
Message |
allenhuffman
Joined: 17 Jun 2019
Posts: 617
Location: Des Moines, Iowa, USA
|
| #define CONST=ROM "ROM data" issue (0x2AAAAAAA???) |
 Posted: Fri Jan 10, 2025 12:11 pm |
 |
|
CCS is looking at this, so I will update this with more information when I have it.
I am placing some const data in a program, and noticed it would only return 0xFFs. Some experimenting (using #org to move the data lower) would make data show up, but there does seem to be an issue with ROM allocation currently. For example, look at what happens in the .lst file:
| Code: |
002AEE: 21E9 0000 ED00 0021 0000 00F1 0021 0000 !......!.....!..
002AF6: 21F5 0000 F900 0021 0000 00FF !......!....
002AFC: 0000 0000 0000 00FF ........
2AAAAAAA: 2032 00EF C300 0020 0020 0000 4180 0000 2..... . ..A...
2AAAAAB2: 4010 00BA 0100 0060 00EF 0000 0600 0000 @......`........
2AAAAABA: 4552 0000 5300 0054 0000 0041 0052 0000 ER..S..T...A.R..
|
You can see there is this sudden jump.
I can also move the data around where the "ROM data" all looks to be in plausible memory, but the compiler does not generate any code referencing those areas.
Quirky problem. Hopefully an easy solution.
Just sharing this in case someone else runs into it.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002. |
|
 |
allenhuffman
Joined: 17 Jun 2019
Posts: 617
Location: Des Moines, Iowa, USA
|
|
| Posted: Fri Jan 10, 2025 3:15 pm |
|
|
I did some more testing today, and the same/similar problem happens when using #rom.
I used some simple ROM memory like:
| Code: | #define SEGMENT0_DEST 0x0
#define SEGMENT0_SOURCE 0x4000
#define SEGMENT0_SIZE 16
#rom int8 SEGMENT0_SOURCE =
{ 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff, 0x42 }
#define SEGMENT1_DEST 0x0
#define SEGMENT1_SOURCE 0x5000
#define SEGMENT1_SIZE 16
#rom int8 SEGMENT1_SOURCE =
{ 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff, 0x42 }
#define SEGMENT2_DEST 0x0
#define SEGMENT2_SOURCE 0x6000
#define SEGMENT2_SIZE 16
#rom int8 SEGMENT2_SOURCE =
{ 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff, 0x42 }
#define SEGMENT3_DEST 0x0
#define SEGMENT3_SOURCE 0x7000
#define SEGMENT3_SIZE 16
#rom int8 SEGMENT3_SOURCE =
{ 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff, 0x42 }
|
Then passed them into a routine that does the read_program_memory() and dumping the buffer:
| Code: | DEBUG_PRINTF ("SEGMENT0:\r\n");
HexDump (SEGMENT0_DEST, SEGMENT0_SOURCE, SEGMENT0_SIZE);
DEBUG_PRINTF ("SEGMENT1:\r\n");
HexDump (SEGMENT1_DEST, SEGMENT1_SOURCE, SEGMENT1_SIZE);
DEBUG_PRINTF ("SEGMENT2:\r\n");
HexDump (SEGMENT2_DEST, SEGMENT2_SOURCE, SEGMENT2_SIZE);
DEBUG_PRINTF ("SEGMENT3:\r\n");
HexDump (SEGMENT3_DEST, SEGMENT3_SOURCE, SEGMENT3_SIZE); |
Some of them work, depending on where I place them, and others show up in the .hex and .lst file, but read_program_memory() just gives me FFFFFF00FFFFFF00.
Fun.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 617
Location: Des Moines, Iowa, USA
|
|
| Posted: Fri Jan 10, 2025 3:22 pm |
|
|
This thing I think triggers this versus a normal program is when I specify a different starting location in ROM and changing the vectors.
| Code: |
#BUILD (RESET=BOOTLOADER_APP_ADDRESS) // Set Reset vector location.
#BUILD (INTERRUPT=BOOTLOADER_APP_ADDRESS+0x8) // Set Interrupt vector location.
#ORG BOOTLOADER_ADDRESS, BOOTLOADER_APP_ADDRESS-1 {} // Don't use Bootloader partition.
|
If I remove those, then let the compiler build it at 0, everything works. I'm guessing it is going to end up being some rom management code that is not taking this into account or something.
We shall see...
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 617
Location: Des Moines, Iowa, USA
|
|
| Posted: Fri Jan 10, 2025 5:06 pm |
|
|
More fun...
I placed test ROM in areas to find where it breaks. I made a macro for this:
| Code: | #define MAKEROM(address) #rom int8 (address) = {\
0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,\
0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff, 0x42 \
}
|
...and used it like this...
| Code: | MAKEROM(0x5700)
MAKEROM(0x5710)
|
...and I verify that in the .lst file:
| Code: | ROM data:
005700: 2211 0033 5544 0066 8877 0099 BBAA 00CC "..3UD.f.w......
005708: EEDD 00FF FF42 00FF .....B..
005710: 2211 0033 5544 0066 8877 0099 BBAA 00CC "..3UD.f.w......
005718: EEDD 00FF 42 ....B |
...and in the .hex file...
| Code: | :10AE0000112233004455660077889900AABBCC0014
:08AE1000DDEEFF0042FFFF0030
:10AE2000112233004455660077889900AABBCC00F4
:08AE3000DDEEFF0042FF00000F
|
I test reads by doing this:
| Code: | uint8_t buffer[16];
read_program_memory (0x5700, buffer, sizeof(buffer));
read_program_memory (0x5710, buffer, sizeof(buffer));
|
And see the addresses inside the assembly:
| Code: | .................... uint8_t buffer[16];
....................
.................... read_program_memory (0x5700, buffer, sizeof(buffer));
23E8: MOV #5700,W0
23EA: MOV #0,W1
23EC: MOV #85C,W2
23EE: MOV #10,W3
23F0: CALL 2274
.................... read_program_memory (0x5710, buffer, sizeof(buffer));
23F4: MOV #5710,W0
23F6: MOV #0,W1
23F8: MOV #85C,W2
23FA: MOV #10,W3
23FC: CALL 2274 |
I think I need a new theory. The ROM is in the proper place, I see it passing in the proper values into the read_program_memory() call, but what it returns is not my values:
| Code: | 0x5700: 11 22 33 00 44 55 66 00 77 88 99 00 aa bb cc 00
0x5710: ff ff ff 00 ff ff ff 00 ff ff ff 00 ff ff ff 00
|
I assume the PIC24 can have data there, since the compiler places it from the highest address then moves down. But on this chip, this is where it begins breaking.
There are other issues, since in my "real" code, I don't even find the address I am reading in the .lst assembly, so I pruned down the code into something very simple.
When I have this set to ORG at 0x0 it works, though, so I don't think the memory is magic. The assembly calls code it put here:
| Code: | 2274: MOV W1,32
2276: CP0 W3
2278: BRA Z,22A0
227A: BTSC.B 0.0
227C: BRA 228A
227E: TBLRDL.B[W0++],[W2++]
2280: DEC W3,W3
2282: BRA Z,22A0
2284: TBLRDL.B[W0],[W2++]
2286: DEC W3,W3
2288: BRA Z,22A0
228A: DEC W0,W0
228C: TBLRDH.B[W0++],[W2++]
228E: DEC W3,W3
2290: BRA Z,22A0
2292: CLR.B [W2++]
2294: DEC W3,W3
2296: INC W0,W0
2298: CP0 W0
229A: BTSC.B 42.1
229C: INC 0032
229E: BRA 2276
22A0: RETURN |
But I don't speak PIC assembly. Anyone here who does that might spot an issue?
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19654
|
|
| Posted: Sat Jan 11, 2025 6:12 am |
|
|
Which chip is this????????
Please please please, we cannot look at what is happening without this
data. Your first post did not show what you were actually doing to generate
the problem. You now show this, but still not which chip?.
Key thing in all posting is to give all the data needed to duplicate the
problem. You know which chip you are using. We don't....  |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9377
Location: Greensville,Ontario
|
|
| Posted: Sat Jan 11, 2025 6:44 am |
|
|
It might be a PIC24 ? , there's 3 in his last line though don't yell at me if it's something else.
I know he's probably got less hair over this, needs TWO more pots of coffee and some sleep... easy to not post details like PIC and compiler. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19654
|
|
| Posted: Sat Jan 11, 2025 8:02 am |
|
|
He says it is a PIC 24, but 'which one'. Affects massively everything to
do with the memory map...... |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 617
Location: Des Moines, Iowa, USA
|
|
| Posted: Sat Jan 11, 2025 10:42 am |
|
|
No need to replicate. CCS is on it. I post these so if anyone else runs into it, they at least know it is a problem.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19654
|
|
| Posted: Sat Jan 11, 2025 12:32 pm |
|
|
It is still worth giving us the data to replicate this. Sometimes we find things
CCS miss, and also it may be a useful clue to other problems when we have
them. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 617
Location: Des Moines, Iowa, USA
|
|
| Posted: Tue Jan 14, 2025 1:49 pm |
|
|
I have replicated the problem on all three PIC24 processors listed in my signature.
When I try to recreate it with a very small program, I was unable to reproduce the problem.
Something seems to throw off the ROM allocation routine based on 1) having the program #org to a different address and 2) the size, maybe.
Hopefully they can figure it out. The "test" program I use is small, but it is placed into memory by my bootloader code, then started.
Hopefully they can dissect the PIC24 assembly that was generated and figure out what is going on with it.
Seeing their own .lst file get messed up with those huge memory locations is also interesting.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 617
Location: Des Moines, Iowa, USA
|
|
| Posted: Tue Jan 14, 2025 3:00 pm |
|
|
Some more interesting (?) observations... I decided to read the program memory out and see what was really there.
List file:
| Code: | ROM data:
004000: 2211 0033 5544 0066 8877 0099 BBAA 00CC "..3UD.f.w......
004008: EEDD 00FF FF42 00FF .....B..
005000: 2211 0033 5544 0066 8877 0099 BBAA 00CC "..3UD.f.w......
005008: EEDD 00FF FF42 00FF .....B..
006000: 2211 0033 5544 0066 8877 0099 BBAA 00CC "..3UD.f.w......
006008: EEDD 00FF FF42 00FF .....B..
007000: 2211 0033 5544 0066 8877 0099 BBAA 00CC "..3UD.f.w......
007008: EEDD 00FF FF42 00FF .....B..
008000: 2211 0033 5544 0066 8877 0099 BBAA 00CC "..3UD.f.w......
008008: EEDD 00FF FF42 00FF .....B..
009000: 2211 0033 5544 0066 8877 0099 BBAA 00CC "..3UD.f.w......
009008: EEDD 00FF 42 ....B |
.hex file:
| Code: | 004000: 00332211 00665544 00998877 00CCBBAA
004008: 00FFEEDD 00FFFF42
005000: 00332211 00665544 00998877 00CCBBAA
005008: 00FFEEDD 00FFFF42
006000: 00332211 00665544 00998877 00CCBBAA
006008: 00FFEEDD 00FFFF42
007000: 00332211 00665544 00998877 00CCBBAA
007008: 00FFEEDD 00FFFF42
008000: 00332211 00665544 00998877 00CCBBAA
008008: 00FFEEDD 00FFFF42
009000: 00332211 00665544 00998877 00CCBBAA
009008: 00FFEEDD 0000FF42 |
I do not know why it skips a line in there, but this is in the file generated by the compiler.
But after loading this program, and reading back the hex file, I see it does look like my program is reporting:
| Code: | :10800000112233004455660077889900AABBCC0042
:10801000DDEEFF0042FFFF00FFFFFF00FFFFFF005C
...
:10A00000112233004455660077889900AABBCC0022
:10A01000DDEEFF0042FFFF00FFFFFF00FFFFFF003C
...
:10E00000112233005566770099AABB00DDEEFF00B0
:10E01000FFFFFF00FFFFFF00FFFFFF00FFFFFF000C
... ^^^ data missing ^^^
|
...and the rest is ffffff00 like erased program memory.
Wouldn't it be funny if my "read program memory" problem is really a "write program memory" problem since it is my bootloader writing this memory. (Though there is still the weird issue with the compiler generating a .hex file with incorrect memory locations in it, so the compiler is not free and clear yet ;-)
Yet, it can load a 32K program that runs just fine. I am going to do some tests with write_program_memory() and see if it has any issues.
The only thing I am aware of is that you can write to the start of a flash sector and it should erase the entire sector. But I see data missing 8 bytes in, rather than a whole sector.
Off to test this...
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 617
Location: Des Moines, Iowa, USA
|
|
| Posted: Tue Jan 14, 2025 5:11 pm |
|
|
Ah, well. Nothing is ever easy ;-) But I did find a potential bug in my firmware loader that I fixed. Even fixed, it did not change the behavior of this, but I am pretty sure there is some weirdness going on with const as I get different results when I embed data using that (letting the compiler decide where it goes) versus using #rom and specifying.
I expect to have a much better understanding of what is going on, soon.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 617
Location: Des Moines, Iowa, USA
|
|
| Posted: Fri Jan 17, 2025 8:58 am |
|
|
Update on this...
The two issues both involve how the code is generated into the .hex file:
1) The subject of this thread, the weird stuff in the .hex file, is really the main thing.
2) The second thing is when embedded data is placed in the .hex, and code uses it but nothing is found in the .hex file that references the memory.
My other issues of getting 0xffffffff back from const 32-bit variables seems to be related to memory areas not getting properly programmed. I would run my code, pull the flash out using ICD Interface, and see what was there, and did see some that truly still had the FFFFFF00 pattern in areas, indicating they just didn't get programmed.
I now have the identical common code (except for addresses) working on two of the three PIC24s, but the third one behaves differently -- probably due to the config bytes being reported backwards from the other two. Working on that today.
I cannot explain what triggers the hex file to be generated like that but experiments with reserving some space at the end of the flash memory made it go away so I've just kept working with that as a workaround.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1638
Location: Perth, Australia
|
|
| Posted: Mon Jan 20, 2025 9:56 pm |
|
|
| allenhuffman wrote: |
But after loading this program, and reading back the hex file, I see it does look like my program is reporting:
| Code: | :
:10A00000112233004455660077889900AABBCC0022
:10A01000DDEEFF0042FFFF00FFFFFF00FFFFFF003C
...
:10E00000112233005566770099AABB00DDEEFF00B0
:10E01000FFFFFF00FFFFFF00FFFFFF00FFFFFF000C
... ^^^ data missing ^^^
|
...
|
When listing extracts of an Intel Hex Format file, especially for any processor with greater than a 64K address map, you need to include the most recent preceding type 4 record (Linear Extended Address record aka page). The actual address in program memory is a combination of the most recent Type 4 page and the Type 0 address offset into the target page.
The extracts shown in your listing does not provide any indication of the actual address.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
