dsPIC33f Bootloader issues. Help!

[cassioriguela]

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]

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]

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]

[cassioriguela]

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]

[cassioriguela]

Thank you again, Andrew.

One more issue. In first programming, do you program bootloader and application together ?

Thanks,

Best Wishes !

[cassioriguela]

[cassioriguela]

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]

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]

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]

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.