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!