Can system memory be erased and reproggammed?

[turboscrew]

I've been trying to get a STM32F427 to go in the system boot loader, but I haven't got any response when I send 0x7F in the USART3 (PB10, PB11). I wonder if the boot loader could be corrupt or something.

Is there any way to tell, if the chip is in bootloader? The chip is soldered in a proprietary board, so the possibilities to study the situation are somewhat limited.

If I run my own application on the mentioned chip, the USART3 seems to work just fine.

There is a switch for BOOT0 (10k pull down and 1K pullup behind the switch) and the BOOT1 is pulled down through a 10k resistor.

I tried to monitor the other boot interface lines, but couldn't detect any changes.

Does anyone know an address range where the the execution should be (PC-value) if I do a reset with debugger connected and then stop the execution?

[Tesla DeLorean]

Not by mortals..

You can READ the content of the memory it resides in, and checksum or compare it against others with the same loader fw version.

It's at 0x1FFF0000..0x1FFF77FF, or around there. And can be read from address zero when BOOT0 is HIGH. Should be documented in the RM

The loader doesn't want any noise on other pins it is monitoring, ie a GNSS receiver on USART1 PA9/PA10 will be recognized as the host because it chirps at startup.

[turboscrew]

I was thinking of comparing - both the mentioned one against another one and then comparing 0x00000000 onwards with 0x01FFF000 onwards within the same chip with BOOT0 as "1" (BOOT1 is always "0"). Just to make sure that the bootloader code isn't corrupted, and that it's mapped as it should.

Kind of good thing that debuggers don't, usually, "go" through the reset vector.

But the bootloader is very sensitive to any glitches in the other boot interface lines?

And I guess there is no way of telling which interface the bootloader has selected, unless you have access to all the possible bootloader interfaces?

On the second thought, I wonder if the bootloader uses interrupts for handling the interfaces? Then I could read the vectors and put breakpoints there.

If the break occurs, that interface is used. Figuring things out from the disassembly would take far too long.

To know the bootloader's version, I need to get connected with it first.

[Tesla DeLorean]

One could probably hot-plug the debugger, or use breakpoint or profiling techniques to understand what's going on in a dynamic system. The loader itself can be disassembled and dissected using static analysis methods. You don't need source code to debug micro-controllers.

[turboscrew]

Had to do it the hard way - soldering "antennas" to some SMD components for oscilloscope.

Turns out, the problem was CAN buffer that yanked its "tx input" high at reset. Even 10k pull-down resistor couldn't hold it down. That made the bootloader think there was something coming in from USB. For our application two pins were mapped as CAN tx/rx, and bootloader maps them as USB D+ and D-. A 10k pull-up fixed it.