Closed Sheyne closed 7 years ago
So far, digging through with the debugger, I've found that things seem to be hanging at:
PT_YIELD_UNTIL(pt, current_buffer->status != LEPTON_STATUS_TRANSFERRING);
in lepton_task.c (line 94).
Putting breakpoints at various locations in lepton.c haven't been triggered, so my guess is that something breaks the stream, and theres nothing to restart it.
I'm trying to investigate the
void HAL_SPI_ErrorCallback(SPI_HandleTypeDef *hspi)
but I've not yet figured out how to get UART debugging messages to my console. Do I need any other special hardware for this in addition to a ST Link?
Thanks for looking into this Sheyne.
Yes, to get the debugging messages you need to be reading from the USART2 lines, as well as compile the code with that uart debug support. I have a header soldered on the back of my board with jumpers going to a USB-UART converter. You should have access to the same signals at the end of the JTAG breakout board -- that was designed to plug into Arduino-compatible "FTDI" USB-UART converters. I haven't actually tried this myself as I don't have one, but looking at the schematic, the same signals go out that flat flex.
@PureEngineering is that right regarding the FTDI on the JTAG breakout? I know we talked about this but can't remember what you said about the cross over... it's either set up to talk to the ESP or the PT1 but I'm not sure which. Either way, you can take care of this with some jumper wires.
@kekiefer I'm using a ST LINK V2 and the JTAG ZIF socket on the PT1. Preferably I'd be able to fix this without new hardware. I do have interactive debugging working in eclipse.
Any suggestions for what tools I should be able to use to see the output with?
You won't lose JTAG. I'm saying you can access the UART lines with the breakout board on the end connector. You just need a USB to UART converter.
I use minicom, you can also use screen or putty depending on what your development system is.
@Sheyne your Novacoast email bounces back every email that has a link in it. You might want to get that checked out. Here is the cable to get: http://www.digikey.com/product-detail/en/ftdi-future-technology-devices-international-ltd/TTL-232R-3V3/768-1015-ND/1836393. It's on Amazon too but a lot more expensive.
Sheyne/purethermal1-firmware@d26d7d5 patches the issue. It's not a complete solution because it masks the issue by detecting that the frame stream died and starting it up again, but some mechanism like this should probably be present anyway to make sure that other bugs like this one don't kill the stream. We probably shouldn't close the issue until the underlying cause is found.
I agree that this seems like a reasonable check to have in place. If you send a PR I'll merge it.
We've been able to consistently get the video stream to crash by spamming UVC requests for 2-5 minutes. Specifically sending one UVC command (get uptime) every time a new frame comes in is enough to cause a the video stream to go down. I've also found that doing UVC requests (again, get uptime) as fast as possible for about the same time will also reproduce the crash.