Self Test Fail after flashing firmware

[carlos.luis306]

I'm part of a research team that's using the Crazyflie for control systems purposes. We've been experiencing weird problems while flashing our Crazyflie's 2.0, we currently have two of them and can flash correctly just one, the other one after the flashing is done (no errors shown in Eclipse console) stays in the self test fail state in which the red LED in M1 flashes 5 times rapidly.

In that state we can't do anything with the fly, and we're literally flashing the same exact code from the same computer, it's even the same .elf file, difference is that one flashes correctly and the other doesn't.

The firmware we're using is the latest posted in the bitcraze github, with some minor changes in the distribution power code and in some signs of the controller in order to invert the otherwise inverted pitch angle.

We're running out of ideas here, a colleague of mine can flash it's own firmware in both Crazyflie's without problems, so I'm starting to think it might be a problem with my toolchain or something of the sort, but if that would be the case I shouldn't be able to correctly flash the other fly right?

We both flash the STM32 from the Eclipse IDE if that helps. Hope you guys may have a solution, thanks in advance

[tobias]

Have you checked the output from the console. It might give some clues of what the problem is. Might be a hardware problem with the one with a failing self test.

[carlos.luis306]

Umm, I don't actually use the Bitcraze client, but I don't think it is a hardware problem because as I said a colleague of mine can flash that drone without any troubles, that's exactly what seems to me kind of strange. Thanks for the help though, I might give it a try with the client to see if I can find the source of the problem.

If not, do you have any other idea of what might cause the problem? Imagine it's a problem with flashing the stock firmware from the github as the changes I made shouldn't mess anything up as I already tested them and I'm able to even follow trajectories (with Vicon) with the other Crazyflie I'm using. Which other way would you suggest to flash custom firmware into the Crazyflie (I'm currently using Eclipse)?

[tobias]

Your problem sounds really strange and as you point out the only thing I can think of would be the tool chain. The flashing method shouldn't make a difference as long as you haven't configure it to flash into some different area or similar.

If you flash the latest official from you computer using the cfclient is it working then?

[carlos.luis306]

I'll try that early next week and report back with the results. As of now, a nearly original firmware flashed through Eclipse didn't work, nonetheless I'll try the cfclient and hope for the best.

Thanks for the support.

[chad]

I'll try that early next week and report back with the results. As of now, a nearly original firmware flashed through Eclipse didn't work, nonetheless I'll try the cfclient and hope for the best.

Thanks for the support.

Are you sure you're using "gcc-arm-none-eabi-4_9-2014q4" dev stack? I've had strange problems with other versions but this is the "official" one for CF2, afaik.

[carlos.luis306]

Hey Chad,

I just tried to flash it using the dev stack you proposed (I was using gcc-arm-none-eabi-4_9-2015q3) but stil no luck.

Tried it also in the other flie and works just fine as always. I truly don't know what I'm missing here, I will try the cfclient and see what's the status is there to know what's failling.

[chad]

I'm sorry I wasn't clear... Did you compile the firmware with that ARM stack? The ARM dev environment doesn't have any bearing on flashing the firmware but firmware compiled with a different stack might not run after getting flashed to the CF.

[carlos.luis306]

Yeah Sorry, I wasn't cleared either, yes, I compiled it with said stack and then I flashed

This is what I'm getting from the console with the Crazyflie I'm having problems with

CFGBLK: v1, verification [OK]
IMU: MPU9250 I2C connection [OK].
IMU: AK8963 I2C connection [OK].
IMU: LPS25H I2C connection [FAIL].
DECK_DRIVERS: Found 6 drivers
DECK_DRIVERS: VID:PID BC:1 (bcLedRing)
DECK_DRIVERS: VID:PID BC:4 (bcBuzzer)
DECK_DRIVERS: VID:PID BC:7 (bcGTGPS)
DECK_DRIVERS: VID:PID BC:6 (bcDWM1000)
DECK_DRIVERS: VID:PID 0:0 (bcCPPM)
DECK_DRIVERS: VID:PID BC:FF (bcExpTest)
DECK_INFO: Found 0 deck memory.
DECK_CORE: 0 deck enumerated
EEPROM: I2C connection [OK].
AK8963: Self test [OK].

[carlos.luis306]

Problem solved (partially)!

I did some research of the problem and apparently it's a soldering problem with the pressure sensor, for now I just disabled it in the firmware and now the Crazyflie works just fine. I'll see later if I have the guts to resolder it, but I'm not currently using that sensor so for now it's fine.

Thanks for the support guys, now I can continue with the research