Bitcraze Forums

As title says. With the locodeck attached and the firmware in debug mode (DEBUG=1 in the config.mk file) the CF2 won't start (it crashes with red leds).
Most I get out of the console in the cfclient is this:

SYS: ----------------------------
SYS: Crazyflie 2.0 is up and running!
SYS: Build 40:0583fa65062c (2019.02 +40) CLEAN
SYS: I am 0x313139313535511400400030 and I have 1024KB of flash!
CFGBLK: v1, verification [OK]
DECK_DRIVERS: Found 15 drivers
DECK_DRIVERS: VID:PID 00:00 (bcRZR)
DECK_DRIVERS: VID:PID BC:01 (bcLedRing)
DECK_DRIVERS: VID:PID BC:04 (bcBuzzer)
DECK_DRIVERS: VID:PID BC:07 (b

but then it just stops. If I remove the deck, it does not crash. If I add another deck (SD deck for instance) it does work.
I do not have an idea where to start looking for the problem in the code.

I noticed that this does not happen (so it starts normally) when I lower the Locodeck priority from 5 to 3. Not sure if this is helpful in any way.

This might be related to this issue. However I have not seen your problem before that you can't run the DEBUG firmware. As per the linked issue we think it is related to the state machine in the DWM1000 module and for some reason the state machine hangs. If the locodeck priority is the highest this doesn't happen in normal cases but if e.g. the SPI bus is loader by something else, like the flow deck, then it starts to happen. If the locodeck task locks up, it kind of hangs the system as it has the highest priority, so that is what I guess is happening here.

Hmm it seems like that problem was different from that issue, since with a priority of 5 it didn't work even without any other deck.
With a priority of 3, it does start nomally with the sd deck attached, but now the SD deck seems to hang after the "wait for sensors" line. It seems like the sensorsCalibrated() function after that line never resolves because if I add a DEBUG_PRINT inside that while loop, it does not show up in the console, not even once.

As I said in my previous post, the sensorsCalibrated() function that is called by usddeck.c never resolves and the usddeck code hangs there.
For some reason the stabilizer.c calls the same function sensorsCalibrated() but this one does resolve (actually a lot of times until, of course, it returns true). I think this might be a priority thing? But as the usddeck never continues past this point, no log files are ever created... I'm kinda stuck here.