 |
 |
| View previous topic :: View next topic |
| Author |
Message |
allenhuffman
Joined: 17 Jun 2019
Posts: 612
Location: Des Moines, Iowa, USA
|
| "Attempted to create: 02008-023FE for ISR" [Resol |
 Posted: Tue Jan 28, 2025 9:45 am |
 |
|
I have code that works on our other PIC24s, but will not compile on the 24EP256GP202.
This PIC24 has a FLASH_ERASE_SIZED of 4096, versus 2048 on the others, so that may have something to do with this since I am trying to reserve program memory so code will not build there.
Location 0x0 is where vectors and a Bootloader will live.
0x2000 is where the high level application vectors and code will live.
For the "app" that the Bootloader loads, I move the vector table there, and I reserve the Bootloader range so it will not build there:
| Code: | #define BOOTLOADER_ADDRESS 0x0000
#define BOOTLOADER_APP_ADDRESS 0x2000 //(8K PIC, 16K HEX)
#define VECTOR_TABLE_SIZE 0x200 |
...snip...
#BUILD (RESET=BOOTLOADER_APP_ADDRESS) // Set Reset vector location.
#BUILD (INTERRUPT=BOOTLOADER_APP_ADDRESS+0x8) // Set Interrupt vector lopcation.
#ORG BOOTLOADER_ADDRESS, BOOTLOADER_APP_ADDRESS-1 {} // Don't use Bootloader partition.[/code]
This works on all our boards. But, I found the need to make a special "update the bootloader" app start its code at the next flash block. The last step it will do is to erase the first block, so I cannot have the code there or it gets erased.
This works on the other PIC24s:
| Code: | // Reserve from where code normally starts to the end of this flash block.
#org BOOTLOADER_APP_ADDRESS+VECTOR_TABLE_SIZE, BOOTLOADER_APP_ADDRESS+(getenv("FLASH_ERASE_SIZE")/2)-1 {} |
The idea is to let the redirected vectors still be at the start of 0x2000-0x21FE then have the rest of that block unused, with this app code starting at the next flash block.
Since FLASH_ERASE_SIZE comes back in bytes, I divide it by 2 to get a value to add to the word-based PIC24 addresses. (Earlier I was just hard coding values like 2095 or 4095, but wanted to make this code common between our projects.)
I get...
| Code: | --- Info 300 "BootloaderInstaller.c" Line 109(1,2): More info: Segment at 00000-01FFE (0000 used) Priv
--- Info 300 "BootloaderInstaller.c" Line 109(1,2): More info: Segment at 02000-02002 (0004 used) Priv
--- Info 300 "BootloaderInstaller.c" Line 109(1,2): More info: Segment at 02004-021FE (0000 used)
--- Info 300 "BootloaderInstaller.c" Line 109(1,2): More info: Segment at 02200-027FE (0000 used) Priv
--- Info 300 "BootloaderInstaller.c" Line 109(1,2): More info: Segment at 02800-0FFFE (0000 used)
--- Info 300 "BootloaderInstaller.c" Line 109(1,2): More info: Segment at 10000-1FFFE (0000 used)
--- Info 300 "BootloaderInstaller.c" Line 109(1,2): More info: Segment at 20000-29FFE (0000 used)
--- Info 300 "BootloaderInstaller.c" Line 109(1,2): More info: Segment at 2A000-2AFEA (0000 used) Priv
--- Info 300 "BootloaderInstaller.c" Line 109(1,2): More info: Attempted to create: 02008-023FE for ISR
*** Error 126 "BootloaderInstaller.c" Line 109(1,2): Invalid ORG range |
The range it gives "for ISR" seems to be the issue. It says 2008-23FE, rather than the 2008-21FE I would expect.
I confirmed with the data sheet (https://ww1.microchip.com/downloads/aemDocuments/documents/MCU16/ProductDocuments/DataSheets/dsPIC33EPXXXGP50X-dsPIC33EPXXXMC20X-50X-and-PIC24EPXXXGP-MC20X-Family-Data-Sheet-DS70000657J.pdf) that the vector table lives from 0x0 with program memory starting at 0x200, just like the other chips.
The normal apps we build for it have vectors at 0x0 and app code starting at 0x200, just like the other chips.
Is there something extra I need to do, or could this be a compiler issue? According to "math":
| Code: | | #org BOOTLOADER_APP_ADDRESS+VECTOR_TABLE_SIZE, BOOTLOADER_APP_ADDRESS+(getenv("FLASH_ERASE_SIZE")/2)-1 {} |
BOOTLOADER_APP_ADDRESS + VECTOR_TABLE_SIZE is 0x2000+0x200 = 0x2200
BOOTLOADER_APP_ADDRESS + FLASH_ERASE_SIZE/2 -1 is 0x2000 + (4096/2) which is 2048 -1 = 0x27FF.
Putting those in manually has the same error:
| Code: | | #org 0x2200,0x2800-1 {} |
Manually adding the extra 0x200 that seems to be getting allocated compiles:
| Code: | | #org 0x2400,0x2800-1 {} |
The other three PIC24s do not do this -- they give me a redirected 0x200 vector table. This one is acting like the vectors are twice as large, and I understand some PIC24s have two vector tables available -- perhaps the compiler thinks this chip is one of those?
Thoughts appreciated. I am hard coding and moving on, but I'm still curious.
[/url]
_________________
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.
Last edited by allenhuffman on Tue Jan 28, 2025 5:12 pm; edited 1 time in total |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9341
Location: Greensville,Ontario
|
|
| Posted: Tue Jan 28, 2025 2:14 pm |
|
|
I 'think' you should zap all those PICs and replace with ONE version !
hay, you said 'thoughts appreciated'.......  |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 612
Location: Des Moines, Iowa, USA
|
|
| Posted: Tue Jan 28, 2025 5:11 pm |
|
|
Nice! 
Here's where this stands.
Indeed, the data sheets say vectors are 0x0 - 0x200 (PIC addresses) for all three PIC24s we use.
However, the EP model has twice as many vectors in that area. I guess the other two only have the first half used.
When the #BUILD option is used to redirect vectors, the new table is twice as large since each entry is a GOTO (address) instead of just a table of addresses like those at 0x0.
For our two PIC24s that work, the space of 0x200 I reserve is enough.
For this EP PIC24, it needs to be double.
I am unsure if there is any way in the CCS compiler to obtain this information and make common code, so for now I simply hard-code the range I need to reserve on the EP, and let the other two use the common #defines.
I think this was 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: 612
Location: Des Moines, Iowa, USA
|
|
| Posted: Tue Jan 28, 2025 5:12 pm |
|
|
| temtronic wrote: | I 'think' you should zap all those PICs and replace with ONE version !
hay, you said 'thoughts appreciated'....... |
For what it's worth ... ya'll did make a change in how I build all our software. After so many times reporting odd compiler things using multi-unit compilation, and you folks saying "oh yeah, that has problems, don't do that" I did switch all the code over to #include the files. Hurts me, from a C perspective, but haven't had any weird compiler things since -- and the code got smaller ;-)
_________________
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. |
|
|
|
|
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
