[Firmware] communication stops about 17 minutes after startup.

[thomasfla]

@luator reported that the communication fails around 17m 45s-50s after the boards are powered one.

[thomasfla]

I think it would be usefull to log the serial output of the masterboard during those 17min to know if the esp32 report a crash or an error.

To do it just need to run:
make monitor
inside the firmware folder, with the programmer connected to the masterbaord.

@luator do you think you could do this next time you have your test setup plugged in?

[luator]

To add a bit more detail:

• It fails with "error 2" (SPI timeout) on the motor boards.
• Most of the time, board 5 (i.e. the last one in the list) fails first, not sure if this is of any significance.
• There are no bad CRC checksums in the SPI communication before it fails, so it is not caused by broken pakets.

[jviereck]

Have you tried to run the master board without any motor boards? This would allow to check if the udrivers cause the issue or the master board.

[luator]

No, I haven't tried that yet. I'm a bit unsure what to expect in this case, though. Since it is somehow an issue in the SPI communication, it might be that even if the master board is causing it, the situation will simply not arise if no motor board is connected. Maybe it would make sense to test with motor boards but powering them separately, so they don't start at the same time (e.g. power the motor boards, wait 5min, then power the master board and see how long it takes until the error).

[jviereck]

Good point about not knowing what happens. Maybe the best is to run the make monitor that Thomas peoposed and see if you get any debug messages?

[luator]

Looks like the cause of the issue has been found: open-dynamic-robot-initiative/udriver_firmware#13