Crazyflie doesn't resume task after function call systemWaitStart()

[TU_KL_Robotics]

Hi,
i'm a beginner in programming c code for the crazyflie. The last weeks I started to modify the crazyflie for using an external SBus Receiver.
I already managed to get my modified firmware working and I'm able to control the quadrocopter with my Taranis RC Transmitter.
The big problem is, that it only works sometimes. I have no idea what is wrong, so the bitcraze community is my last hope to debug the code.

First problem seems to be the systemWaitStart() function in extrx.c . When this function is uncommented, my SBus routines are (sometimes) working. For debugging I'm using ST-Link v2 with the preconfigured debug configuration.
I thougt maybe the missing systemWaitStart() function is causing my problems, so I activated it again. Now the Motors are initialising, but then the board jumps in some kinde of fault routine, where the M1 LED repeatedly blinks about 7 times.

I would be glad if somebody could give me a hint, how I should porceed with debugging this matter.

Best regards,

Philipp

[TU_KL_Robotics]

I think I just found one of the problems. In the function systemTask(), configblockTest() fails, so the pass variable won't become true and therefore systemStart() function won't be executed.
If I set the pass variable manually I can watch extRxTask beeing resumed after the function systemWaitStart().

Can somebody tell me how important it is to get configblockTest() passing correctly? I see that this function is some kind of eeprom test which seems to fail, but don't know why.

[tobias]

For some reason there seems to be a problem talking to the eeprom. As the eeprom is connected to the same I2C bus as the deck port (expansion port) could there maybe be a short of any of the I2C pins?

[TU_KL_Robotics]

Thanks for your reply!
We made some further tests and discovered, that the EEPROM test only fails if we connect the bigquad deck. Without andy decks, the EEPROM test passes. This is very strange, because there is currently nothing connected to the bigquaddeck. We also measured the I2C communications on the SDA and SCL line but the signal seems to be the same with and without the deck connected.

Is there a schematic for the bigquaddeck?

[tobias]

That is strange indeed! Could be a software related issue which is triggered by the big quad deck code. Could you share your setup and firmware used so I can try to duplicate?

Schematics available here.

[TU_KL_Robotics]

Today we managed to fix the problem. Just used USART2 instead of USART1 for SBus receiving, now eeprom test allways passes
With this adaption we are able to fly the crazyflie directly with an Frsky X4R SBus receiver over Taranis RC transmitter, the copter is extremly responsive, a hughe diffecence to the control with gamepad out of the virtual machine!

But we still don't have an explanation for the strange behavior described before. It must have something to do with the bigquaddeck hardware

Thanks for your help!

[tobias]

Great that you found a solution but it is still a bit worrying. I guess you are not flying with the bigquad attached then as UART2 then is used for PWM output? The uarts we call UART1 and UART2 is really UART3 and UART2 in STM32 peripheral terminology (UART1->UART3, UART2->UART2). Could that be part of the problem. I'm guessing the there might be a peripheral conflict of some sort.

I'll see if I'm able to replicate your problem. Do you have a fork of the code I can try with? Could you share your setup?

[TU_KL_Robotics]

We already noticed, that in the firmware, UART2 is not the same thing as hardware USART2 of the STM32. For our SBus functionality we added a uart3.c in drivers folder, which configures hardware USART1 of STM32 processor. So RX Pin was mapped to PIN59, which is E_SDA, also used by EEPROM. This seemed to be the reason why EEPROM test failed.
But we don't have an explanation why EEPROM test passes with the same firmware when bigquaddeck isn't installed .