Hello!
I would like to ask about an issue related to Tinybooter internals that I encountered when trying to port .NET MF to a custom platform based on STM23F4.
I am working on a GCC port of .NET MF for a custom platform based on STM32F4. I got to the point when the Tinybooter compiles and executes, however after flashing the MCU via JTAG and reset, the tinybooter always erases the first flash sector of the MCU.
I am able to debug and step the code and I pinpointed the line of code that is responsible for the erasing. But I am unsure about the code surrounding it, its meaning and why it eventually leads to the erasure. I would be grateful for any help with understanding this. Below you can find the details that I have discovered so far.
-----
The target platform is based on STM32F407ZG which is the same MCU as on Discovery4, only in a bigger package (144 vs 100 pins). Thats why I use Discovery4 as my development platform.
The .NET MF port that I used as a starting point is the port made by Oberon which includes a ready made Discovery4 solution. I made some modifications to it but only in order to be able to compile it via GCC, no additions or modifications regarding its functionality. The GCC version being used is 4.7.2 included in Yagarto-20121222.
Upon stepping the Tinybooter exectuion, I localized that the flash erase takes place inside the call on line 948 in Application/TinyBooter/Commands.cpp:
g_BitFieldManager.EraseOnSignatureCheckFail();
Further inside this call, I realize that the erasure is triggered based on the results of [font="'courier new', courier, monospace;"]GetNextSignatureCheck(device, bitField)[/font] call on line 314 in Commands.cpp.
However, I was unable to decipher the meaning of the bitField data structure (I somehow realize that each bit of the BitField[n] must correspond to a block/sector/region in Flash but I lack a deeper understanding of this as well as the overall meaning of the bitField structure). I would be grateful for any explanation regarding this.
The second thing - where do the BitField values come from? When stepping inside GetNextSectorSignatureCheck(device, bitField), the values are loaded on line 262 and below in Commands.cpp. It seems to me that the data are acquired from flash on the address pointed by m_cfgPhysicalAddress (which is in my case 0x0800C000, the correct address of the first flash config. sector). But how did they get there in the first place?
The erasing itself is then performed on line 347 within EraseOnSignatureCheckFail() by calling:
device->EraseBlock( eraseAddress );
In this case the eraseAddress points to 0x08000000 which is the starting address of the MCU's flash memory. This perfectly corresponds to the observed result - after running this, the first flash sector gets wiped clean.
The MCU's memory model that is used in the .NET MF port I am working with is best illustrated in the following presentation by Oberon, slide 31:
http://www.mountaine...df?t=1339779332
To summarize, the things I am unsure about is:
- what is the precise meaning of the bitField data structure?
- where do the bitField values come from?
Thank you for any help. In case any further info is needed, let me know and I'll post it straightaway.
