View previous topic :: View next topic |
Author |
Message |
cassioriguela
Joined: 25 Oct 2011 Posts: 27
|
dsPIC33f Bootloader issues. Help! |
Posted: Sun Dec 04, 2011 8:17 pm |
|
|
Hello friends,
I'm developing a bootloader for dsPIC30FJ128GP802. I have read a lot of topics about bootloader layout then I want show my plan for developing it and know your opinion about this layout.
I have a external flash memory that it'll save code applicattion, so my bootloader is a function that checks external memory if I have a code to be programmed. if there is a code, then it is programmed to program memory.
I intend to start bootloader function after reset. Then, the function will verify if the application is corrupted and program again, taking the data from external memory. so I'm protected from power cyclins.
I will put bootloader function at a codeblock at 0x400. I have read about problems with interrupts and reset vector in simular layout. Do you see any problem?
Great Thanks,
Sorry my bad english. |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Sun Dec 04, 2011 8:40 pm |
|
|
The method you described will work ok however I have a couple of suggestions.
A method I use to to add a parameter block containing bootloader specific flags. This typically consumes between 16 and 32 bytes of program memory depending on the type of bootloader. This block MUST in an erase sized block of program memory that does not contain any bootloader code (this enables the parameter block to be erased without erasing part of the bootloader. Because this block is only written to by the bootloader during the bootloader process it can share a PIC erase size memory block with the application.
For example, if the bootloader finishes at 0x33D0 the bootloader paramter block could be located on the next PIC erase size boundary at 0x3400. If the block is 32 bytes then the application can start at 0x3420.
In the parameter block I include a unique key (3 to 8 character field) that identifies the image that was last bootloaded. When the bootloader boots up it reads the external source (program memory, SD card, USB key etc) and reads the key field from a config file. If the keys do not match then a bootload is required. The bootloader then loads the application into program memory. The last step of this process is updating the parameter block with the new key. This way a matching key can only occur if the bootload process finishes successfully.
A bootloader origin of 0x0400 is fine. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
cassioriguela
Joined: 25 Oct 2011 Posts: 27
|
|
Posted: Sun Dec 04, 2011 9:11 pm |
|
|
Andrew, thank you for replying.
I want to do exactly what you described, but I'm thinking about saving bootloader flags at end of external memory, what do you think ?
I'm concerned with interrupt and reset vector, because I have read about of problems with them. Do I need protect them too ? or remapping interrupt vector ?
Thanks,
Great wishes! |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Sun Dec 04, 2011 10:44 pm |
|
|
cassioriguela wrote: | Andrew, thank you for replying.
I want to do exactly what you described, but I'm thinking about saving bootloader flags at end of external memory, what do you think ?
I'm concerned with interrupt and reset vector, because I have read about of problems with them. Do I need protect them too ? or remapping interrupt vector ?
Thanks,
Great wishes! |
You can put the flags where ever you like. However, from a support perspective, it is easier at the end of the bootloader because it will be in the same location irrespective of the amount of program memory available for the PIC, As you change PIC family members you do not have to remap the flags.
If you are placing the bootloader at 0x0400 and the bootloader does not use interrupts then you should not have any problems. This is the way all my bootloaders for PIC24/dsPIC processors work. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
cassioriguela
Joined: 25 Oct 2011 Posts: 27
|
|
Posted: Mon Dec 05, 2011 5:31 am |
|
|
Thank you again, Andrew.
I just have some questions
I always want to start after a reset with bootloader function. I was thinking of writing my application and bootloader together in first programming. But, How to start bootloader function after a reset ? Putting bootloader function after a #ORG ?
Thanks,
Great Wishes. |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Mon Dec 05, 2011 5:42 am |
|
|
cassioriguela wrote: | Thank you again, Andrew.
I just have some questions
I always want to start after a reset with bootloader function. I was thinking of writing my application and bootloader together in first programming. But, How to start bootloader function after a reset ? Putting bootloader function after a #ORG ?
Thanks,
Great Wishes. |
In my implementation the bootloader is always in control on reset. It is upto the bootloader to pass control to the user application. With the exception of my PIC32 bootloaders, all other discover the application entry point by intercepting the rest vector of the application during bootload.
If coding the application in CCS then two lines are required to coexist with my bootloaders.
#build (reset = 0x0000:0x0007)
#org BootloaderStart BootloaderEnd {}
The build statement ensures the only code in bytes 0x0000 to 0x0007 in the application hex file is the reset vector which the bootloader directs to a special location (bootloader parameter block in my terminology). The org statement prevents the application from overlaying the bootloader. No interrupt vector remapping is required as my bootloaders do not use interrupts (the exception is my USB bootloaders which are encrypted variants of Microchips bootloaders). Personally I consider bootloaders that require interrupts to be poorly designed. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
cassioriguela
Joined: 25 Oct 2011 Posts: 27
|
|
Posted: Mon Dec 05, 2011 5:57 am |
|
|
Thank you again, Andrew.
One more issue. In first programming, do you program bootloader and application together ?
Thanks,
Best Wishes ! |
|
|
cassioriguela
Joined: 25 Oct 2011 Posts: 27
|
|
Posted: Mon Dec 05, 2011 6:35 am |
|
|
asmallri wrote: | cassioriguela wrote: | Thank you again, Andrew.
I just have some questions
I always want to start after a reset with bootloader function. I was thinking of writing my application and bootloader together in first programming. But, How to start bootloader function after a reset ? Putting bootloader function after a #ORG ?
Thanks,
Great Wishes. |
In my implementation the bootloader is always in control on reset. It is upto the bootloader to pass control to the user application. With the exception of my PIC32 bootloaders, all other discover the application entry point by intercepting the rest vector of the application during bootload.
If coding the application in CCS then two lines are required to coexist with my bootloaders.
#build (reset = 0x0000:0x0007)
#org BootloaderStart BootloaderEnd {}
The build statement ensures the only code in bytes 0x0000 to 0x0007 in the application hex file is the reset vector which the bootloader directs to a special location (bootloader parameter block in my terminology). The org statement prevents the application from overlaying the bootloader. No interrupt vector remapping is required as my bootloaders do not use interrupts (the exception is my USB bootloaders which are encrypted variants of Microchips bootloaders). Personally I consider bootloaders that require interrupts to be poorly designed. |
Andrew,
You have wrote #build (reset = 0x0000:0x0007) but, reset vector in dsPIC is 0x0002:0x00004, is it right ?. How should I write it ?
I tried to write as you described but ccs doesn't accept it.
Thanks |
|
|
cassioriguela
Joined: 25 Oct 2011 Posts: 27
|
|
Posted: Wed Dec 07, 2011 6:27 am |
|
|
Hello.
Andrew, thank you for helping.
If anybody can help me. I have another issue about bootloader. If I remap interrupt vector. Could I use old space of interrupt vector for programming app code ? Or I'll lose it ?
Thanks. |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Wed Dec 07, 2011 2:07 pm |
|
|
If you remap the vectors then you cannot use the old location for interrupt as they are need to map to the new vectors.
With the bootloader architecture you have described there is no need to remap any vectors and to do so would add unnecessary interrupt service latency. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
cassioriguela
Joined: 25 Oct 2011 Posts: 27
|
|
Posted: Thu Dec 08, 2011 11:21 am |
|
|
Thank you again, Andrew.
I won't remap interrupt vector, I just want to know about this issue.
Now, I have problems in saving reset vector before erasing IVT and app area. When I call read_program_memory(), dsPIC get hangs. I read program memory with MPLAB and it doesn't changed. Somebody has idea what is it happening ? My CCS version is 4.099.
Thanks. |
|
|
cassioriguela
Joined: 25 Oct 2011 Posts: 27
|
|
Posted: Mon Dec 12, 2011 5:31 am |
|
|
Hello dear friends.
I have some new strange problems.
When I read program memory with read_program_memory I have a problem with SPI and it does'n work. I'm using a SPI memory and after using read_program_memory I can't read anything from memory. Somebody know what's going on ?
Thanks. |
|
|
|