cancel
Showing results for 
Search instead for 
Did you mean: 

Need help to get started with bootloader program

Vu.Andy
Associate III
Posted on June 29, 2016 at 19:11

I've read a few documentations from STMicro but still not sure what the actual steps to do a proper bootloading.

 

Here is what I understand so far.

1. First the bootloader firmware is already on the uC so I don't have to worry about that part correct?

 

All I have to do is develop a PC program that scan the bin. file and send to the appropriate port such as UART, CAN, I2C ....

2. To download the program, I have to configure the BOOT pin for proper boot loading.

   

Based on the AN2606, Table 2, there are various options to configure the BOOT pin but which one should I choose?

 

3. Assuming I have configure the BOOT pins correctly, and assuming I am using CAN port, the next step is to send data to the CAN port with the command stID=0x79 ...

4. But the implementation is complicated.

 

For hardware wise, what type of type of USB to CAN bridge do I need?

 

Is there a ready-made solution? I guess I can use another STboard as the bridge correct?

5. What tool is needed to develop the software?

 

Assuming a GUI is needed, then one has to use Windows Visual Studio to develop the interface.

 

So one has to develop either a driver or some type of command line

 

along with the GUI as well.

I know some are using Keil to develop the bootloader, but I am confused because we are not technically required to develop any firmware correct?

 

We just need a piece of software to send data to the CAN bridge with the correct format so to activate the on-chip bootloader correct?

 

So I can use VisualStudio and probably a USB to CAN driver to develop the GUI to send data to the CAN bus correct?

Well it's just my opinion but let me know if this is correct.

6. Technically the STLink is bootloader correct?

 

But looking at the schematic, I don't see the boot pins being used, so what mechanism is used by the STlink to download the firmware to the chip?

 

Seems like JTAG.

 

On the Nucleo board, the UART pins and JTAG are used.

 

So this might be an obvious question then why a ''bootloader'' is needed at all because anyone can get a STLink or something similar to download the firmware?

Are there any commercially available bootloaders, both hardware and software, that can be purchased right now?

 

I just want to learn how it is being done.
5 REPLIES 5
Posted on June 29, 2016 at 21:19

You are muddling a lot of different concepts.

The JTAG/SWD debugger is a hardware scan-chain implementation giving the external pod access to internal gates/registers in the design. It is independent of the System Loader, or anything you have running on the chip.

The System Loader is a ROM based loader you can access via USB, USART, CAN, etc using the BOOTx to run the code in ROM instead of your own code in FLASH. Being as it is in ROM, it comes like this in otherwise blank chips from the factory. 

If you don't like the protocol provided by the System Loader, you can write your own loader code that resides in FLASH. This is commonly referred to as IAP or In-Application Programming. Your own loader can use protocols you choose, it can verify your application before executing it, and it can provide a means of recovering or debricking a device.

At a minimum you are likely to want to write a customer facing application on the PC (Windows, whatever) that hides the interaction with the loader, which might be rather basic. The loader could also present a serial interface to a PC based terminal and permit downloading of new firmware using an existing protocol like X or Y-Modem.

PC side applications would need to be written using Visual Studio, or whatever the platform supports. If you have a product that doesn't interface nicely you might have to write drivers, or interact with other drivers at a system/ioctl type level. How much of this you can do will depend on the skills and experience you bring to the party.

Code running on the STM32, ie loaders, applications, will need to be built with Keil, IAR,  GNU/GCC, etc.

On STM32 devices you'd nominally pull BOOT0 High and reset for it to enter the System Loader, you'd then communicate with that via ONE of the interfaces it is documented to support. In many cases you can jump directly into the ROM System Loader from your own app/loader if that makes things easier. ie my loader can reboot into the System Loader which then presents as a DFU device connected via USB.

Interfacing via JTAG/SWD using an ST-LINK or J-LINK, is going to be at least an order of magnitude more complex than just opening a COM Port and talking to a ROM based loader. The test stations are easy to build and replicate in production.

CAN will be complicated by your ability to communication with your chosen interface, and it's driver stack. ie not just a CreateFile against COM30

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Vu.Andy
Associate III
Posted on June 30, 2016 at 18:56

Thanks for the detail information.  Being new, I am still a bit confused partly due to the terminology. 

When people refer to designing a ''bootloader'', do they mean the actual bootloader that already embeded in the processor?  Or do they mean design the software that works with the existing bootloader supplied by STMicro?

Assuming Keil is used and you need a GUI for the interface.  What .bin or .exe file do you need from Keil? 

Based on my understanding, this program is not going to be flashed onto the chip, then why Keil is needed at all?  The program only needs to talk to the UART or CAN bus only.

Also I am trying to get started so do you have any recommendation how to get started?

Does anyone have an existing example or website that I can get started?

Thanks.

Posted on June 30, 2016 at 19:27

They could mean ST's or their own, you don't need ST's, and it won't execute unless the BOOTx pins are set, or you jump into it.

To write Windows apps you'd need to use Windows/Microsoft tools. Doesn't sound like you have any experience doing that.

For CAN, you'd need to talk to device drivers, or DLLs supporting such interfacing.

ST provides several IAP examples, the Flash Loader Demonstrator has source code, and the protocol for the System Loader isn't that complicated.

This book has a chapter on loaders and updating 

http://shop.oreilly.com/product/0636920017776.do

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Vu.Andy
Associate III
Posted on July 01, 2016 at 19:49

For the BOOT pin, can I manually set it (by using a jumper), then run the bootloader through the CAN bus, then put the BOOT pin back to normal mode?

I am thinking if I can have access to a USB to CAN bridge, I can create a program using Windows to talk to the uC CAN bus.  Once the program finish running, I then can set the BOOT pin back and put the uC to the original application state.

I guess no one could give me a definite answer why Keil or some other ARM tool is needed at all since all I am trying to do is just talking to the CAN bus or some other bus.

Again, this may be obvious to those who has been working with bootloader but I am new to this.

Thanks.

Posted on July 01, 2016 at 21:13

I think I've been reasonably clear, but to reiterate, to use the ROM Based System Loader you need to be able to write an application for the PLATFORM you plan on doing the update from. Some people that will be WINDOWS, others LINUX, and another subset using some other embedded platform which could include an STM32 system or one running an ATMEL ARM9.

Is suspect doing CAN will be slower and/or more complicated, due to the 8-byte payload limitation. I'd suggest you try the serial first and work yourself up the complexity ladder from there.

Do you have any preexisting experience with programming Windows applications, or general embedded stuff?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..