|
|
View previous topic :: View next topic |
Author |
Message |
naughty_mark
Joined: 29 Aug 2012 Posts: 97
|
bootloader IVT question in dsPIC33EP256MU814 |
Posted: Tue Apr 16, 2013 6:04 pm |
|
|
Hi, everyone
I am back again~
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
|
|
Posted: Wed Apr 17, 2013 5:41 am |
|
|
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
|
|
Posted: Wed Apr 17, 2013 4:17 pm |
|
|
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. 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.
Anyway, thanks a lot! |
|
|
|
|
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
|