View previous topic :: View next topic |
Author |
Message |
bahnfire
Joined: 30 Apr 2009 Posts: 8
|
#ORG error on 24FJ128GA006 |
Posted: Fri May 22, 2009 11:35 pm |
|
|
I am receiving an 'Invalid ORG range' when attempting to use the full program memory space of the 24FJ128GA006 processor.
Code: | #org 0xC04, 0x157FA |
--- Info 300 ... More Info: Segment at 00000-0FFFE (0000 used)
--- Info 300 ... More Info: Segment at 10000-157FA (0000 used)
--- Info 300 ... More Info: Attempted to create 00C04-157FA for #org
*** Error 126 ... Invalid ORG range
I am using the AN1157 Bootloader that is taking up the space below 0xC04, since I cannot seem to find a good CCS PCD bootloader. If someone is aware of one that works well, please let me know (and one that might be able to support AES, as the AN1157 one does).
Thanks,
Paul |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Sat May 23, 2009 4:33 am |
|
|
I wonder what you want to achieve with the said #org statement. Because you are assigning the full ROM area, except for the bootloader, no room is left for the application. #org statement with this syntax takes effect for the following function or const definition only.
By assigning the area below 0xc04 to the bootloader, the application code is automatically placed in remaining area.
How do you intend to assign the interrupt vectors in your design? I defined fixed vectors for all used interrupts in my application (Option A, direct mapping method in AN1157) and use #org statements to place the individual handlers to these addresses. Option B doesn't work due to limitations in PCD as far as I see. |
|
|
bahnfire
Joined: 30 Apr 2009 Posts: 8
|
Ah... I think I was tired when I wrote the post |
Posted: Sat May 23, 2009 6:21 pm |
|
|
I was trying to keep out of the area where the AN1157 bootloader is (since the PCD one is a little hokey). I read the CCS manual on the ORG command, but I think it got lost in translation as it was going to the brain (not a lot of sleep).
I will try blocking from 0x000-0xC00, since that is what I am trying to do.
I will post if otherwise.
Thanks! |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Sun May 24, 2009 1:31 am |
|
|
I have assigned the bootloader memory range by importing it's image to the main application. The advantage is in creating a single production image containing the bootloader and the application code.
Code: | #import(FILE=Bootloader.hex,HEX,RANGE=0x000:0x003)
#import(FILE=Bootloader.hex,HEX,RANGE=0x200:0x75F)
#build(reset=APP_BASE) |
There are possibly other methods to achieve this, but you can't #org or #import code to the locations used for application interrupt vectors without causing an error. |
|
|
bahnfire
Joined: 30 Apr 2009 Posts: 8
|
I'll have to give that shot |
Posted: Sun May 24, 2009 9:41 am |
|
|
I wasn't able to get to the code last night (daughter was sick), but I hope to get to it today. I was thinking of using the non-remapped IVT code for AN1157. I was worried about the IVT range, since my initial main program with a timer did not function until I took the timer out. |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Sun May 24, 2009 11:25 am |
|
|
Yes, as said, my example is also using direct mapping. The IVT entries are generated by the main application. Because the IVT is actually part of the protected bootloader image, all ISRs must be assigned to fixed addresses that are unchanged between software versions. |
|
|
|