CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

bootloader IVT question in dsPIC33EP256MU814

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
naughty_mark



Joined: 29 Aug 2012
Posts: 97

View user's profile Send private message

bootloader IVT question in dsPIC33EP256MU814
PostPosted: Tue Apr 16, 2013 6:04 pm     Reply with quote

Hi, everyone

I am back again~ Very Happy
Recently, I am using dsPIC33EP256MU814 with CCS compiler version 4.133 to program a bootloader code. Because currently CCS compiler can not support bootloader feature in dsPIC33EP series microchip, my program is just a mimic bootloader which is put into main flash address, and I write a LED blink test code and ask compiler locate it some specific address in the main flash memory. The mimic bootloader code works well.
But what I am worrying about is because I use some of interrupts in my bootloader code such as UART1, TIMER and EI, and in dsPIC33EP series microchips, the main flash program and auxiliary flash program share the same IVT address (auxiliary flash program only has a auxiliary IVT for contain the entry address of IVT). My question is, when CCS support EP auxiliary program and I can put my bootloader code into auxiliary flash memory, and when I use it to download my main program which also contains interrupts code, will the bootloader program be corrupted or effected when the new IVT contents written into the IVT address?

Thanks for you help.
Kind Regards
Mark
jeremiah



Joined: 20 Jul 2010
Posts: 1355

View user's profile Send private message

PostPosted: Wed Apr 17, 2013 5:41 am     Reply with quote

I am not as familiar with the auxiliary flash feature, so my comments are more of a general nature:

1. CCS does support bootloaders for the dsPIC series, but they don't support auxiliary flash yet (or at least last I looked). I am not pointing this out to be knit picky, but just to kinda brace you for any comments like "I've done bootloaders in dsPIC before" and such. Supporting bootloaders is a much more general issue than just auxiliary flash. You don't "need" it for a bootloader at all. It's a nice to have feature though.

2. If you are overwriting the same IVT address that the bootloader uses or the same IVT remapping that the bootloader uses, then yes you will corrupt the bootloader.

3. One nice feature of PIC series chips is that they have 2 IVT sections, a primary and an alternate. What a lot of people who need interrupts in their bootloader do is use the alternate IVT for the bootloader, and simply remap the primary IVT to the application section. That way, the bootloader and the application have two different IVT so there is no need to risk corrupting the bootloader. Then, just before you call your application you disable all the bootloader interrupts (as well as the global interrupt) and switch from using the alternate IVT to using the primary so the application will be able to use its interrupts.

The #build is a very handy pre processor directive for getting some of this to work (also #ROM will be useful for remapping your interrupts for the application).
naughty_mark



Joined: 29 Aug 2012
Posts: 97

View user's profile Send private message

PostPosted: Wed Apr 17, 2013 4:17 pm     Reply with quote

jeremiah wrote:
I am not as familiar with the auxiliary flash feature, so my comments are more of a general nature:

1. CCS does support bootloaders for the dsPIC series, but they don't support auxiliary flash yet (or at least last I looked). I am not pointing this out to be knit picky, but just to kinda brace you for any comments like "I've done bootloaders in dsPIC before" and such. Supporting bootloaders is a much more general issue than just auxiliary flash. You don't "need" it for a bootloader at all. It's a nice to have feature though.

2. If you are overwriting the same IVT address that the bootloader uses or the same IVT remapping that the bootloader uses, then yes you will corrupt the bootloader.

3. One nice feature of PIC series chips is that they have 2 IVT sections, a primary and an alternate. What a lot of people who need interrupts in their bootloader do is use the alternate IVT for the bootloader, and simply remap the primary IVT to the application section. That way, the bootloader and the application have two different IVT so there is no need to risk corrupting the bootloader. Then, just before you call your application you disable all the bootloader interrupts (as well as the global interrupt) and switch from using the alternate IVT to using the primary so the application will be able to use its interrupts.

The #build is a very handy pre processor directive for getting some of this to work (also #ROM will be useful for remapping your interrupts for the application).

Thanks for your help, Jeremiah.
#build and #rom are good ideas.
Actually yesterday after I posted this topic, I tried to avoid using interrupt in my bootloader code, and it worked! so I don't need to bother if IVT written may corrupt bootloader code. Wink But more critical things I need to think about is how to generate hex file which can use auxiliary flash to load my bootloader code, I tried to modify hex file manually, but failed, looks the microchip doesn't have correct "reset" or "goto" instruction in relevant address. Rolling Eyes
Anyway, thanks a lot!
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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