Posted on May 17, 2011 at 14:04Attached is my rough disassembly and annotation of the boot loader from my STM32.
Personally I think it is small enough that it would be easier just to recode it, or a better one dealing with S-Records, Intel Hex, or X/Y Modem. If you start jumping into specific ROM addresses you need to be concerned about chip/stepping issues with assorted versions of the loader.
>>As a side point - where does the bootloader read the Boot0 pin?, and can we read it in our code?
Hard to say, mostly done in hardware initialization in order to pick the appropriate boot vector address, and memory mapping. The primary boot loader code does not read the pin, but does look at the ROP state and disables certain functions. Want to see how it booted? check the memory which is mapped/shadowed at zero. In the ROP state code running in FLASH/ROM can read data in FLASH/RAM/ROM. Code running in FLASH/ROM can copy and execute code in RAM which can also access all the memory. Code booted from RAM in the ROP state cannot however touch or execute code in FLASH/ROM. Technically, I think it can execute, but it can't read values from the PC relative literal pool so you are basically SOL.
There is some conjecture that the STM32 might execute some hidden code, or copy something to RAM or other shadowed memory at zero during initial startup. Weird things happen with a RAM boot, don't assume it reads the boot vector. Different STM32 variants start execution of user code at 0x140 and 0x1E0 when you boot into RAM.
