Main Site Documentation

TinyBooter, TinyCLR, Cerberus Firmware Clarification


#1

Hello all,

After writing this, I have realized that is pretty much a wall of text. So, TLDR: I don’t understand TinyBooter, TinyCLR, flashing firmware, etc. very well and want to know more! A few direct questions are:

1. How does TinyBooter get flashed to the chip initially? Does it come pre-loaded on all STM chips or does GHI load TinyBooter before sending it out? 

2. If making a different board with a 'blank microcontroller', would TinyBooter HAVE to be loaded using ST-Link and the SWDIO/SWCLK pins? Or can it be done the same way updates of Cerb firmware is done using the 'Boot Mode'?

3. What is the difference between TinyCLR and the Cerberus firmware? From my understanding, TinyCLR is the way the chip interpretes code ('runs .NET instructions') and the Cerberus firmware describes pins/timers/other peripherals on the board itself.

Thanks! If you have time or are interested, there is more after the sig.

Sivat

Now for the ‘Too long but still read’ version:

I’ve been trying to understand the basics of the firmware/software that is needed on a STM chip (for me, the STM32F405 loaded on the Cerberus) to get things from a ‘blank/new’ chip to fully operational/NETMF/can use Visual Studio/other awesomeness.

I’ve already found loads of information* but can’t help feel I still am not grasping the idea completely (specifically, the differences between TinyBooter, TinyClr, Cerberus Firmware and how they get uploaded to the board). So, in an effort to better understand, I come to you! If anyone can help fill in the holes in my knowledge, it would be greatly appreciated! So, to start, I’ll try to explain what I already know (or think that I know) in an effort to show I’ve tried doing my homework!

The first thing that runs on power up is the boot loader (TinyBooter). This is stored in the very beginning of the F4’s Flash memory and normally runs the CLR of NETMF (TinyCLR - ‘Common Language Runtime’). If the board is brought up in ‘Boot Mode’ (Specifically ‘boot from system memory’, taken from the STM32F405 datasheet) if certain pins are kept high or low (Boot0 = 1 and Boot1 = 0). This stops TinyBooter from starting TinyCLR and instead has the chip wait for further instructions (explained as a ‘command interpreter’ in the slide-show below). In this mode, we are able to update do specific things, like clear all flash memory, load custom TinyBooter firmware, update TinyCLR, etc. This can be done using DFU via USB.

After TinyCLR begins to run it either starts the main application or waits for further instructions if started in the ‘boot mode’ as before. In this boot mode, we are able to update any Flash memory not relating to TinyBooter or TinyCLR, which essentially means flashing new software applications. This can be done using DFU via USB.

Next is the NETMF application that I develop in Visual Studio in C#. To get this onto the microcontroller, I use the Visual Studio’s Debug button, which compiles and flashes the code to the chip. This all seems very magical and straight foward to me, mostly because all of the hard stuff has already been done. From here I have the option of using MFDeploy to download the HEX and deploy the same program to other chips, but the FIRST deployment MUST be done with Visual Studio via USB.

Phew That was a lot. Does anyone have any corrections/extras to add? Thanks a lot!


#2

You mostly answered to yourself.
STM32F4 series has a ROMboot that is started via Boot0 pin as you know (but today all MCU/MPU chips has the same feature e.g. SAM9x35 on the G400D/S boards). This boot rom let you use DFU software from ST to flash code/data to memory of the STM32F. This can be a native program, or, in NETMF specific case, it is TinyBooter. Then Tinybooter has the ability to load TinyCLR. Then TinyCLR has the ability to load your VS c# compiled code and run/debug it. Tinybooter is a very simple startup code that initialize all the clocks and bus of the STM32 including USB and implements the transfer protocol to load TniyCLR from MFDeploy (or Fezconfig).
Obviously you can flash firmware (tinybooter or your native code whatever developed) using ST/LINK or JLINK Jtag/SWDIO.

Note: the ROM boot code is OTP flashed by ST and it’s always there in every chip.


#3

You might want to take a look at this presentation:

Current version also here: http://www.mountaineer.org/netmf-for-stm32/.

See slides 42 to 45 in particular.

Cuno


#4

I would like to add that on systems with limited resources you can use TinyCLR without TinyBooter.


#5

@ Architect - Sorry to be daft, it’s late, and I’m not quite grasping the “no booter” scenario. Upon reset, the chip bootstraps the CLR? What is the disadvantage of this? Why do we have TinyBooter on all these boards when it’s not needed?


#6

Tinybooter makes it easier to load/update firmware. MFDeploy talks to TinyBooter to do that.