USB disconnect on STM32F4 breaks backup SRAM.

[BillThePlatypus]

I'm working on firmware for a flight controller with the STM32F405. The board communicates with a computer using VCP over USB. I'm debugging a driver for the backup SRAM, to recover in case of a firmware crash. The crash handler is programmed to save a little bit of information to backup SRAM, and then to reboot. On reboot it checks for backup information, and adjusts accordingly. It works well, unless the USB is disconnected between power on and the crash, in which case it fails to write to backup SRAM.

I wouldn't think that the backup SRAM and the USB drivers should be sharing any resources. I also don't understand the USB driver well enough to know what part of the driver is called when the USB disconnects. In my searching it seems that it is somewhat tricky to detect when USB is disconnected.

Any suggestions on how to fix this or where to look are appreciated.

[TDK]

Debug your program and figure out where it is when it’s crashing. If a hard fault, look at the registers to determine the source. You havent really provided much info.

By default, the USB uses malloc when initializing the vcp interface. I would change it to be statically initialized. Just a guess.

[waclawek.jan]

What is "crash handler"?

JW

[BillThePlatypus]

The crash is intentional. I've edited my post to better explain, but the point is that info should be written to backup sram, in case of a crash, but the write fails, but only after USB is disconnected.

[BillThePlatypus]

It's where code goes when there is a hardfault or similar. In this case it is called `HardFault_Handler`.

[TDK]

What so you mean by the write fails? It goes into a hardfault handler? Or the memory isnt what you expect? How are you determining it’s failing? Writing to sram, backup or not, is typically an easy affair.

[BillThePlatypus]

Here is how things are supposed to happen:

1. A hard fault happens. For testing purposes I have caused a hard fault intentionally.
2. The HardFault_Handler function is called
3. The handler saves key data to backup sram
4. The handler resets the MCU
5. The MCU reboots
6. The MCU checks backup SRAM for crash information
7. The MCU reports the crash information to the user

This works correctly, unless at some point between startup and step #1, the USB is disconnected. In that case, no backup memory is read on reboot, presumably because it is not being written. There are no other indications of failure.

[Pavel A.]

Is USB the only power source for the STM32? No backup battery?

-- pa

[waclawek.jan]

Single-step the hardfault handler, or debug it in any other available means, e.g. light up a LED upon entering it, light up another after writing the backup RAM, read it back immediately and verify, lighting up more LEDs upon success/failure.

Make sure you draw correct conclusions, e.g. revise the method you verify RAM content upon reset, reconnect USB before rest, etc.

JW

[BillThePlatypus]

No, it is battery powered.