Bitcraze Forums

Well, I've really gone and done it this time

Was practicing some high-ish altitude rolls and flips flying FPV in acro mode and took a pretty swift tumble into the grass. Afterwards, it seems like the STM or something in the path of the STM has broken, but I don't see anything obvious with the naked eye.

Symptoms:
-When I power up, led M2 lights up solid blue. No other LEDs come on.
-When I power up and hold the button to go into flashing mode, led M2 starts to blink, but led M3 does not.
-The NRF appears to be working as I can detect the flie via bluetooth and with the crazyradio, but connecting never succeeds.
-"make cload" doesn't work after booting to flashing mode
-The crazyflie doesn't enumerate on USB anymore
-The STM32 chip feels a little bit warm to the touch after 15-30 seconds of power
-Can't communicate with the STM via SWD. I haven't done the full factory_reset path, but "make flash" fails and I can't otherwise connect via SWD
-The reset button on the debug adapter doesn't appear to reset the chip (well, I guess I wouldn't know since M3 doesn't light up, would I)

Got any ideas on where to start with probing & checking out components?

Thanks
Sean

Did some probing with more data points:

VBAT (across the battery poles) is 4.0v.
All the VDD pins on the STM32 are sitting at 2.999V
Reset on the STM is high (3v)

I forgot about BOOT0 -- that line is low. That seems wrong..right? Perhaps the NRF firmware has gotten into a bad state somehow. I'll solder up the nrf debug adapter and run the 'make factory_reset' command tomorrow.

If you could measure the battery current that would give an indication if there is a short somewhere. When the CF2 is running it normally consumes about 115mA.

I wouldn't bet on that the nRF firmware got damaged during the crash but maybe some soldering on the nRF BOOT0 track did like R3?

Sure, I'll check on that. Are there any good probe points on the board, or any other clever ways to measure total current draw instead of needing to disconnect one of the battery leads?

Totally agree that the firmware ought not to be affected by a physical crash...only reason I'm going down that path is because its easy, and because I saw this behavior once before (not related to a crash though) and a full reflash fixed it.

Edit: I misread the datasheet. BOOT0 is for enabling the uart bootloader, so being low in this case is correct.

Measuring with a multimeter I think it is easiest to remove the positive pin. It is pretty easy on the battery connector and the battery is protected with a circuit if you accidentally short anything.

Have you checked that the reset pin isn't in constant reset (pulled low)?

If the power is good (VCC), no short and the reset pin isn't jammed low it might be a bit tricky to find.

It won't hurt re-flashing the nRF51.

I'm out of town for the next week or so -- I intend to dig in a bit more when I get back.

Didn't get a chance to measure current yet - will do. As far as I can tell all the pins I've probed look correct - reset is high, VDD is high on all the pins, BOOT0 is low for a normal boot, etc. Reflashing the NRF didn't help, unfortunately, but at least the NRF is running. I plan on writing some quick debug code to see if I can communicate with the STM over uart at all.

I'm measuring a current draw of ~199mA.

hmmm, then something is probably shorted. Could be tricky to find. Anything gets warm? If you happen to have access to a thermal cam you could probably spot it (comparing to a normal board as some things get hot normally).

Don't have a thermal cam

The stm32 itself actually does get quite a bit warm (and rather quickly) as compared to a normal board.