cancel
Showing results for 
Search instead for 
Did you mean: 

SD Card Bootloader

tkjmail2
Associate II
Posted on February 05, 2010 at 08:40

SD Card Bootloader

10 REPLIES 10
tkjmail2
Associate II
Posted on May 17, 2011 at 13:39

Yeah, Clive, that's what I want to do 🙂

But right now I haven't tried reading from a FAT formatted SD card, as I can't get the EFSL ported to my STM32F103RET6 in Ride7!
Posted on May 17, 2011 at 13:39

If you have code to initialize and read sectors, a boot loader which can pull a file from the root directory of a FAT16/FAT32 formatted volume can be built from scratch in less than a day. Boot loader only needs to support a subset of the file system, need a couple of 512 byte buffers to store and cache things. Only one sector of the FAT is needed at a time.

Read Master Boot Record (MBR), locate first partition.

Read FAT Boot Sector, determine root dir size, and cluster size, fat table, etc.

Read Root Directory Sector(s) to find ''FIRMWARE.BIN'', recover size, start cluster.

Read FAT and Data Sectors into memory as you chain through the clusters.

-Clive

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
swhite2
Associate III
Posted on May 17, 2011 at 13:39

I've written an SD card loader application for the STM32F that allows the main firmware to be updated from a file on the card. However its a commercial product so I can't share it.

I used a commercial file system library and got everything to fit in 32KB (we use a 128KB part). Works like a charm and has been working in the field for about 6 months now.

tkjmail2
Associate II
Posted on May 17, 2011 at 13:39

Finally I got the EFSL library added to the Ride7 enviroment - and now it works!

Everything in the EFSL library works, so now it's just how to update the flash by reading a file from the SD card :(

Posted on May 17, 2011 at 13:39

I'm downloading firmware updates with a wireless modem using HTTP, stashing it in an empty section of the STM32F103RET6's 512KB flash. After I validate the image, I reset the CPU and have the boot code copy a small flasher into RAM which updates the main firmware. Once this is done it resets again, running the new firmware. The boot loader is fairly compact.

Having it pull the data from an external memory, flashing 512 byte blocks at a time would work. If done compactly, it might take a couple of KB to implement.  To avoid bricking things you need to validate the image before using it.

-Clive

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
tkjmail2
Associate II
Posted on May 17, 2011 at 13:39

Is it possible that you could share this code with me?

Also, how did you make this flashing bootloader - have you read any ST documents, which you woulr recommend to me?

Thomas

Posted on May 17, 2011 at 13:39

In this thread I discuss how to reboot the processor and alter the startup behaviour here :

https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/FLASH%20Copy%20%20Vector%20Table%20Update%20%20Core%20Reboot

I program the flash in the early boot conditions because I can strongly control the environment, and there aren't random parts of the system running from flash and interrupting. To improve the chances of success flashing should be done in a quiet system.

I've been doing this a while so the process is reasonably well understood. I reviewed the STM32 TRM documents, I looked at the flashing examples and library code, and I experimented programming unused scratch areas of flash from my application code. I also tested and coded assembler routines, and the code to copy them into RAM from the app. The boot loader code is compact and written in assembler. In other words the code is efficient and very much self contained.

I'm not going to post full source, but might consider posting some blog entries on the techniques if there is general interest.

The general flow of the reset is

Check for a magic constant in RAM early in the boot, prior to executing the C runtime initialization.

Initialize the CPU, clocks and core peripherals.

Copy a block of location agnostic (ie PC relative) code and literals from it's fluid location within FLASH, to a known scratch area of RAM, and execute it.

Code in RAM, determines the size of the new flash update, then a block at a time. It checks to see if the the new data is different, erases the block if not blank, and then writes the new data, and repeats for all the blocks in the image. Once this completes the system is reset, and the processor restarts without a magic constant, and the boot loader drops into the C runtime initialization and executes the applications as normal.

-Clive

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
tkjmail2
Associate II
Posted on May 17, 2011 at 13:39

About the ''magic constant in RAM'', I used the same technique in my DFU project, where I've changed ST's DFU so I can boot into DFU by software - so I don't have to press on a button (change an input pin)

If you would like, you could write some blog posts on my blog - I would really appreciate it 🙂

http://elec.tkjweb.dk/blog

But anyways, I'm still trying to make the SD flasher myself, but right now it unfortunately doesn't look promising!

Thomas

michaelanderegg9
Associate
Posted on June 08, 2011 at 11:25

Hi clive

I'm using the FS of Keil for the communication with my SD-Card. I copied the firmware for the controller on this SD-Card and would like to flash now the controller from this SD-Card.

First I have to reboot the controller and then start the bootloader. You have posted a link, but this one doesn't work any more.

i would be very interessted in further informations about how I could handle this issue

Kindly regards

mike.