I’m able to use openocd to debug my application using the 5 steps post and I found another post from @rickkas7 where it mentions not to use the debug button, but rather, use the debug history (that helped a lot, it should be in the docs). What I’m not able to do is figure out where the firmware locks up when it stops breathing cyan (cyan on full, no breathing). I can’t quite tell from the output (sorry, my machine rebooted unexpectedly last night, so I don’t have the exact line), but it looks as if there was a SIGINT somewhere and I couldn’t do a backtrace to figure out where it happend. There was no output other than the SIGINT from gdb either.
This is just an LED controller, there are no other peripherals attached, so it’s not like I’m seeing I2C hang for me or something. I’m using FastLED 3.1.5.
Is there a way to use gdb to figure out what happens when the led breathing goes solid cyan?
I apologize, I lost the community message where he stated that (or similar?). I found that using Ctrl-D and hitting Play does not allow you to debug. The green play button tries to build and upload to the programmer shield, which fails because you need to be plugged into the Photon USB to do DFU, but then you can’t switch to the JTAG port to run the debugger.
If there is a path to doing it that way, it would be great. I just can’t get it to work.
I found the only way I could make this work was to build manually (5 steps to setup…) then DFU that image and click Run|Start Debugging (F5) so it wouldn’t try to rebuild and upload. The history comment was what I remembered from his post, but I may have not written it quite right.
I figured it out. Turns out, FastLED and system thread enabled don’t play well together. I never found the exact line, but if you delay(x) immediately after a FastLED.show(), it’s about 10% likely to hard lock up.I would guess that FastLED has IRQ’s disabled, and Particle.process() is doing something that is going to make that a problem.