Bitcraze Forums

Hi,

I've spent a couple of days trying to track down a crazyflie problem with no luck in sight of solving it. The gtgps.c deck driver was rewritten to interface with the ublox max m8c gps receiver. After flashing a new binary (cf2.bin using firmware baseline 2016.05.28 or 2016.05.12), the crazyflie starts, but then after a few seconds resets without further communication with the client. On the client console tab it shows: "SYS:The system resumed after watchdog timeout [WARNING]", “SYS:No assert information found”. I believe this involves stm32f4xx_rcc.c, the independent watchdog timer and watchdog.c, but don't understand where the problem originates from. The gtgps (Titan-2) didn't exhibit this type of problem. The binary messages output by the Titan-2 ends with checksum bytes followed by a CRLF. The binary messages from the ublox end with checksum bytes only. Both receivers are outputting at a baudrate of 115200. Tried running at 9600 on the ublox crazyflie, but got the same problem result. Flashing the ublox driver into a crazyflie without a ublox expansion board nor running an equivalent driver configuration in a crazyflie with a ublox using an ealier version of firmware (2016.02.17) doesn't show or result in this watchdog timeout/reset.

This information may not give enough details to diagnose the likely culprit, identify the problem area or to postulate a fix, but any insight or thoughts that point to how to get around this problem would be greatly appreciated.

Best regards,
Jack

Sounds like a lockup somewhere but pretty hard to tell where. You could build and run a debug build which will disable the watchdog. That might give some more insight on the lockup.

Hi,

Thanks for the suggestion Tobias.

I increased the size of the uart1 queue buffer size “uart1queue = xQueueCreate(64, sizeof(uint8_t));” in uart1.c from 64 bytes to 128 bytes. This solved the problem in using baseline crazyflie_firmware 2016.05.28. My ublox max m8c gps driver had worked in crazyflie_firmware 2016.04.23 and earlier versions. These were all setup for running at 9600 baud. In the latest driver, I wanted to switch to 115200 baud thinking I could improve on the crazyflie processing load caused by the gps driver task using some floating point math. When I encountered the watchdog reset I tried going back to 9600 baud but still got the reset condition. As it turned out, there was a coding error that delayed the gps driver response to incoming gps receiver data and this coupled with trying the higher baudrate was clouding the reset symptoms making the problem more difficult to understand. Anyway, increasing the queue size was necessary in order to run at the higher baud rate.

Best regards,
Jack