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

dsPIC33f Bootloader issues. Help!

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



Joined: 25 Oct 2011
Posts: 27

View user's profile Send private message

dsPIC33f Bootloader issues. Help!
PostPosted: Sun Dec 04, 2011 8:17 pm     Reply with quote

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

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Sun Dec 04, 2011 8:40 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Sun Dec 04, 2011 9:11 pm     Reply with quote

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

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Sun Dec 04, 2011 10:44 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Dec 05, 2011 5:31 am     Reply with quote

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

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Mon Dec 05, 2011 5:42 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Dec 05, 2011 5:57 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Dec 05, 2011 6:35 am     Reply with quote

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

View user's profile Send private message

PostPosted: Wed Dec 07, 2011 6:27 am     Reply with quote

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

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Wed Dec 07, 2011 2:07 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Thu Dec 08, 2011 11:21 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Dec 12, 2011 5:31 am     Reply with quote

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.
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