SD booloder for debug

[hooper]

Hello pals,

I have wrote a SD bootloader. this bootloader seems to work properly but a single strange bug has to be identified and fixed
Supose I have two programs PA and PB. I amd doing the following stages:

1. program the MCU with the Bootloader application. and shut down the MCU power.
2. Copy the PA program ( its hex file of course) to the SD and insert it to the card slot.
3. Power up the board. now the bootloader starts updating the Flash with the PA program.
When finished it lunches the program and the program deletes the hex file from the SD.
4. I power down and then power up the board. since there is no more hex file on the SD card
The bootloader ( that is invoked on power up) finds the already loaded program from stage3 and
launches it.
5. I have powered down the board and added again the hex of PA to the SD card. on power up, as expected
the bootloader (since found an hex file on SD) started to load the PA and at the end he launched it and deleted the
hex file from the SD
6. Until now everything behaved correctly. Now I have power down the board and inserted to the SD card the hex file of the
PB program. On power up the bootloader started to load the PB program. when loading has finished it went to the launching
stage of the program but failed to launch it !!

conclusions:
- The Bootloader application can load and launch application from SD card.
- After loading and launching application he can do it again ( ssee staage #3)
- After loading a different application it fails to launch it ( although lokkks like succeeded to load it to the flash)

If some one would like to find the problem and fix it I will be happy to deliver him the project and assist him. the code has many comments and is not complicated.

I would like to add a 'trick' that I have used to implement the bootloader:
1. since the bootloader application and the PA and PB applications are compiled with MikroC, all of them will include the BootVT
function that is automatically inserted y MikroE to a fixed address of 0xBFC00380. Now since at this address is already the BootVT
of the bootloader code that has been loaded to the MCU via MikroProg, I have decided in my bootloader to neglect this part of the
hex file of the application that I am loading. thus when the bootloader hits this address in the hex file he trying to load it just skips
it. The idea was that since this BootVT is used as exception handler for the bootstrap stage of the MCU I should keep the
one that has been loaded by the Mikroprog since the bootloader is the application that is running upon power up.
by the way, the address of BootVT cannot be changed. it is fixed and #pragma funcorg will not move it.

there is difference btween the bootVT of the PA to the one of PB:

-----------PA BootVT-------------------

Code: Select all

____BootVT:
0xBFC00380        0x3C1E9D04  LUI        R30, 40196
0xBFC00384        0x37DE0534  ORI        R30, R30, 1332
0xBFC00388        0x03C00008  JR        R30
0xBFC0038C        0x70000000  NOP        
; end of ____BootVT

--------PB BootVT-------------------

Code: Select all

____BootVT:
0xBFC00380        0x3C1E9D04  LUI        R30, 40196
0xBFC00384        0x37DE0798  ORI        R30, R30, 1944
0xBFC00388        0x03C00008  JR        R30
0xBFC0038C        0x70000000  NOP        
; end of ____BootVT

I just wonder if this trick might cause me problems or it is the source to my boot-loading problem?
My asumption was that this difference does not matter since it reflects different positions of the __BootGenExcept function.

As I have wrote, I am willing to deliver the code for anyone that will try to find ad solved the PA and PB problem.
an one that is interested, please reply here in the forum. I do promise to explain every line in the code.


Regards,
M. Hooper

[hooper]

hi

problem SOLVED

[filip]

Hi,

Please, can you post the solution here ?

Regards,
Filip.

[hooper]

hi Filip,

I will send the SD Bootloader within few days.
It can be easily modified to USB Bootloder ( just modifying the reading hex functions and calling them
from the USB interrupt, and, of course adding some logic if USB stick has been removed before the end of the bootloading...)
I think that the main process has been explained here by me in several posts, but for the publishing to be complete I will do it again
when I publish it (with the source code).

Regards,
M. Hooper

[hooper]

Hi Filip,

Attached to this post my SD bootloader project.
You might distribute the code and use it without any restrictions.
This project might be used by everyone but it is emphasized that it is published here AS IS
and usage of this code is on your own risk.

Using the bootloader:
In order to use this bootloader your user application should be located in the program Flash at and above 0x9D004000.
Almost all the space below this address is used to store the bootoader code.
Thus, add in your user application the following macros:

Code: Select all

#define USER_APP_RESRT_ADDR 0x9D004000
#define ConfigMem();  \
        OrgAll(USER_APP_RESRT_ADDR); \
        FuncOrg(__BootStartUp,USER_APP_RESRT_ADDR);

In the main function of the user application call the function ConfigMem(). This will ensure that your user application will be linked to the apropriate location in the program Flash.

Actually, this is only all that is needed to prepare the application for being loaded by the bootloader.
Now, since it is a SD bootloader the hex file of the user application should be moved to the SD card.
For some inter-company reasons we have decided to rename it when moved to the SD card to the name BootImg.asr (but it is still the original hex file that has been generated by the MikroC for PIC32 compiler). of course you can change the name to what ever you like, but remember to update the program with the new name.

now burn the bootloader to the mcu ( using any programmer like Mikroprog), inser the Sd card to the slot and power up the board ( or reset the mcu).

On power up the bootloader searches for the existence of the hex file (BootImg.asr) on the SD card. if the file is found this means a new version or firmware need to be loaded and it is starting to load it to the mcu. upon end load the bootloader will launch the loaded application and the process is finished.
Now, if you power up again the board (or reset the mcu) the bootloader will find again the hex file and wil try to load it again.This is something that we really dont want to happen. to prevent bootloading every power up, the hex file should be deleted from the SD card (or at least renamed) at the end of the loading process. This can be done in two places: either the bootloader code after loaading the hex file and befor launching the loaded application or by the application itself when it is launched. I have implemented the second option, although Computer Science specialists will argue with me that from the theoretical point of view this should be done by the bootloader application. So in any case you should add the following code either to the booloader code or the user application code:

Code: Select all

void deleteBootImgFromSD(){
  /*
     if BootImg.asr exists on SD card delete it
     in order to prevent bootloading each power up
  */
  #define  FILE_READ 0x01
  char *fileName = "BootImg.asr";
  Mmc_Fat_Init();
  if ( Mmc_Fat_Exists(fileName) ){
      Mmc_Fat_Assign(fileName,0xA0);
      Mmc_Fat_Delete();
  }
}

if you decide to implement the hex file deletion in the user application you can call it right immediately after the call to ConfigMem()
If it is implemented in the bootloader code call the function in the function that launches the application immediately at the beginning of the function.

Attention:
The Bootloader erases all the flash pages that belong to the program flash from the address of 0x9D004000. this means that if you use some section of this flash to keep your application specific data then it will be lost when you use this bootloader to upgrade your firmware. you can adjust the bootloader application to preserve some space that you need.

Check sum
each hex line contains a checksum. Decent application should check this value to verify that the hex lined are received without an error. Unfortunately, although it is such a simple task I have not accomplished it and thus you are encouraged to add it to the bootloader.

USB Bootloader
This SD bootloader can be easily modified to a USB bootloader. Just replace the Mmc_Fat access functions to the file with the appropriate calls to FAT32 and use the USB HOST library...

adjusting to your board
This project is written for my designed board. You might be needed to adjust it to your hardware (SD card connection and SPI channel number).

The project files
the project code is delivered here in a compressed rar format.
The directory "include" contains the *.h files of the project.

Regards,
M. Hooper

[feuerwolf]

Thank you very much for sharing this Master Hooper. Thats how community works!
I always failed at the hex parser part...

[feuerwolf]

hallo hooper,
is there any special reason why you use FAT16 and MMC mikroelektronika Library instead of FAT32? Because i tried to get your code run, but microe MMC lib did not work with my FAT16 micro sd cards, which do work as fat16 on my STM32 projects. So i know the micro SD cards are properly formated and i know my hardware works. Tried it on my own hardware and on Fusion V7 board. With MMC lib it was not possible to init the sd cards, the Mmc_fat_init always returns: 1 - if FAT16 boot sector was not found . Even their plain example code wasn't working as described. Ahhh well anyway...

Only reason i could think about why you did not use mikroE FAT32 lib is due to size of bootloader code. At least code size and mikroe FAT32 was an issue with my own bootloader project.

I will use your bootloader in combination with FatFS library from Chan which is very lightweight and works with FAT32
http://elm-chan.org/fsw/ff/00index_e.html

Is there a point i did miss?
thanks

[hooper]

Hi
The reason for using FAT16 is simple. My application is using FAT32 for HOST USB. Since Mikroe FAT32 library does not support multi device and I was too lazzy to write my own wrapper to their driver thus I have decided to use the MMC instead.
Since I am not in front of my code now I think that I am using different pins than those that are used in the Fusion board. May be this is your problem.
The bootloader is working fine on my board.
I have not used Chan's file system library but it looks great. Please tell me if you succeded with it.
If still you face problems then do not hesitate writing me.

Goog luck,
M.Hooper

[feuerwolf]

hi,
thanks for your reply. I wont investigate in the mmc issue because i definetely need Fat32 anyway. So either i will use mikroE Fat32 or Chan FatFS system depending on how the code will work out.
I have one more question about your prototype:
enResult getHexAsciiLine(char *ptrHexLineBuffer);

Just for understanding. *ptrHexLineBuffer points to the first character in the the line of the new HEX file, which is always a ":" in mikroE hex files. And it steps to the next line every call. So that in the do/while loop in runBootloader() every single line will be decoded one after another?

[hooper]

Hi

The functiondelivers a pointer to a buffer that will be filled with the next line read fro the hex file.
Recall that I have not checked the checksum of the line. I do recommend checking it and return the eresult according the checksum checking result

[feuerwolf]

Thanks again M. Hooper for your work.
I made a SD Card bootloader based on your files. It uses FAT32 (mikroE library) and is made for mikroE Fusion board. I published the Project on libstock which i hope is fine for you M. Hooper.

https://libstock.mikroe.com/projects/vi ... bootloader

[hooper]

Indeed it is a good idea to publish it in Libstoc.
Thank you for crediting me there.
Hope this will help other developers as well.

Good luck
M. Hooper

[hosseinildar]

Dear Hooper,
I need to a bootloader via USB memory stick.can you help me?
My MCU is STM32F407.

Best Regards
H.KIAN

[hooper]

Hi hosseinildar,


It should be easy to change the SD boot loader to a USB boot loader.
Actually you have to replace the reading functions to read from the USB.

You can also choose a different solution: if you have on your system both Sd card AND a USb
memory stick, you can in the booting procedure, copy the hex file from the USB to the SD and then run the SD boot loader by
Sending the MCUa reset request.

[hosseinildar]

Hi Hooper,
Very thanks for your prompt reply,
I don't have SD on hardware but I have USB .
Now I want update my application via a USB memory stick only. already my board made .
Best Regards
H.KIAN