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.

[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.

[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.

[waclawek.jan]

What is "crash handler"?

JW

[BillThePlatypus]

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

[Pavel A.]

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

-- pa

[BillThePlatypus]

No, it is battery powered.

[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