Endless Flashing White Light When Solar Powered (Memory Fault?)

Hey there, I am still using the custom board I made as well as the custom firmware I made in this post, and I was able to create the custom firmware.bin files and get past my slow development problem. However; I have ran into a new issue that is relatively peculiar.

In my application, I am having the camera capture an image once per minute, then upload that image to a server over a modem. This board is connected to a Li-Po battery that is being charged by a solar panel and charger circuit. The board works fine for a few hours but eventually just starts flashing a white light as though the memory was corrupted. I am then forced to flash the board with the bootloader.dfu file as well as the firmware.bin file, I have not found another way to get the board un-bricked.

Important Findings:

  1. When disconnecting the power and rebooting - it keeps flashing the white light
  2. When the board powers on with or without a good power source, the white light stays on for a few seconds (this seems to be a sign that the flash memory is being reformatted)
  3. When connecting the bricked board to a reliable power source - it keeps flashing the white light
  4. When connecting to a reliable power source from the start - it will work correctly for at least 2 days and I have not seen any issues. (this leads me to believe that when the battery is low and the board is powering on and off over and over again, the memory is being corrupted?)

Thank you so much for all of your help, you solved my other problem and hopefully this will be my last one haha

Here is a link to what is happening: https://youtu.be/1dNqv-GNwos

How am I supposed to debug a custom board and custom firmware?

Ask a specific question please.

Hi, I understand if I’m being less than helpful here… but, please understand… you are saying to me that you took our hardware design/software and built your own custom system on it.

That’s cool. But, then you say it’s modified from our design and that you modified the firmware.

That’s cool too. Finally, you say that things are working and you need help…

The problem is that you’re own you’re own though at this point. An example, forgetting to put a RC delay on the STM32H7’s reset pin can cause it not to boot. A little detail, but, if you were building your product in contract with us we’d tell you about issues like this.

To note, you’re also asking for help support for a product that you aren’t paying for help support per-say… while I try to help everyone, you should expect that we can’t really help you effectively if you didn’t engage us before the product design.

Why don’t you try debugging the board in that “bricked” state and see what’s going on with a debugging image (DEBUG=1) ? BTW if it’s flashing an LED then some code is still running to flash that LED, so it’s Not exactly bricked, you need to figure out where it’s failing. Note that white light, which actually looks green to me but anyway, if it’s the same as our RGB LED blinking white that’s the error handler which gets called with a text error message. If you break there that’s a very good clue to start with. It also tries to log an error to the storage before flashing the LED, if by bricked you mean it doesn’t mount the storage you could dump that flash sector and/or QSPI and mount it as fat image with loop device and read the plain text message.

If you built a SWD debugger into your board you should be able to trace execution there too.

Note that we are going to start producing OpenMV cams soon with standard ARM jtag headers to make issues for folks.

I think you are on to something here. Just to be sure, the DEBUG=1 parameter shoud be passed during the ‘make TARGET=board_target’ command?

for example: ‘make TARGET=board_target DEBUG=1’

Also when the light is blinking, the board cannot mount to a serial port or as a flash device. It looks like the board is attempting to reboot multiple times in very fast succession.

*** The flashing stops when I put the board in DFU mode and erase the flash memory sector so the flash memory may be getting corrupted when it boots. Is there any way to keep the board from reformatting the flash memory on boot if the files are corrupted?

Yes, edit the code in main.c. There’s a reformat call if it can’t mount the disk. However, the files aren’t going to be readable by firmware.

1 Like

I think the filesystem gets corrupted in a way that it still gets detected valid initially, then it hardfaults when it actually tries to mount the filesystem… With the cam in that state could you try to insert an SD card ? This forces the code into the other path where it mounts the SD instead. This is possibly related:

And this:

1 Like

Could you point me to the lines where the re-format happens? I went through the main.c file in src/omv/ and cannot find it. I am not the best with C so maybe I missed it.

Thank you guys so much for the fast responses. This is a weird request, especially considering I asked how to avoid this, but it could be very helpful to me if I could somehow trigger the reformatting of the flash memory from the python scripts (like how it happens during the line you sent me).

This would be a way to completely reset the board if something goes drastically wrong

Use the low level disk methods in the pyb module and write a 0 block of data to the first sector of the flash. This will corrupt it causing a reformat to happen by our firmware.

Also, you can use the stm module to directly write to device registers and you can read the data sheet for how to erase a flash sector.

1 Like