Bitcraze Forums

Hi all,

SYS: Crazyflie 2.0 is up and running!
SYS: Build 225:ff06aab1d367 (2016.09-225) MODIFIED
SYS: I am 0x353534303335510236005B and I have 1024KB of flash!
CFGBLK: v1, verification [OK]
MPU9250 I2C connection [OK].
AK8963 I2C connection [OK].
LPS25H I2C connection [OK].
DECK_DRIVERS: Found 9 drivers
DECK_INFO: Found 0 deck memory.
DECK_CORE: 0 deck enumerated
EEPROM: I2C connection [OK].
AK8963: Self test [OK].
SYS: The system resumed after watchdog timeout [WARNING]
SYS: Assert failed at src/lib/FreeRTOS/portable/GCC/ARM_CM4F/port.c:263

I experience this issue after I have implemented some design and I couldn't figure it out why.
The design that I have done and implemented is as follows,

I am trying to feed position values from a webcam (opencv) to the client via zmq and make use of the api to send it to the firmware.
From the opencv site, it will always send position to the client for every 5 milliseconds.
I have enabled the Kalman filter.
However, I try to send my own flight commands to the firmware by using the available parameter framework.After doing so, the crazyflie restarts and shows the above errors.

it seems like the problem comes from the Kalman filter along with the webcam but I couldn't figure it out which part causes the problem. I have tried the following scenarios,
Receiving position data from webcam disabled, Kalman filter used => crazyflie works well
Receiving position data from webcam enabled, Complementary filter used => crazyflie works well
Receiving position data from webcam enabled, Kalman filter used => crazyflie shows error
Frequency of sending position values reduced, Kalman filter used => This error occurs less frequently, but I am not sure whether it is by luck

Could anyone help me on this issue? Thank you very much.

Something is most likely taking to much time. By building the debug build (DEBUG=1) the watchdog will be disabled and you can test if it works then as a first step.

tobias wrote:Something is most likely taking to much time. By building the debug build (DEBUG=1) the watchdog will be disabled and you can test if it works then as a first step.

I have followed your method and found out it is triggered by the cfassert(). So I started to check which functions have utilised it and I try to do debugging (by commenting the cfassert function used in the calling functions one by one). My current progress is that the multiplication of matrix in Kalman filter causes the watchdog timer timeout. So I am still looking into this part. Do you have any suggestions?

Thank you

Then this is not your code taking too much time but rather your code causing an assert. The file and line that asserted is printed on the next Crazyflie startup.

The assert from your copied log is there: This is the first time I see this one. Have you created any tasks or made any tasks exit?

arnaud wrote:Then this is not your code taking too much time but rather your code causing an assert. The file and line that asserted is printed on the next Crazyflie startup.

The assert from your copied log is there:

Code: Select all

static void prvTaskExitError( void )
{
	/* A function that implements a task must not exit or attempt to return to
	its caller as there is nothing to return to.  If a task wants to exit it
	should instead call vTaskDelete( NULL ).

	Artificially force an assert() to be triggered if configASSERT() is
	defined, then stop here so application writers can catch the error. */
	configASSERT( uxCriticalNesting == ~0UL );
	portDISABLE_INTERRUPTS();
	for( ;; );
}

This is the first time I see this one. Have you created any tasks or made any tasks exit?

Actually I have created multiple tasks for the design of autonomous system. Each task handles a single movement.After they successfully make changes to the set point, they will delete themselves.
Is that caused by my own created tasks? I didn't check this part actually as it is only happened when I uses Kalman filter. Maybe it is just an co-incidence..
Do you have any suggestions?

Thanks a lot

My design is like, whenever I send a command by using the parameter framework, a corresponding task will be created and set point will be given to the controller and the task will be deleted by itself.

Is any of the tasks returns without being deleted? It would cause this error.

One way to protect the tasks is to add a "while(1);" at the end of there functions to make sure the function cannot return and to delete them using vTaskDelete.

I am not sure what you are trying to achieve but design-wise we usually avoid creating and deleting tasks in runtime in an embedded system, but that is a side-issue .

arnaud wrote:Is any of the tasks returns without being deleted? It would cause this error.

One way to protect the tasks is to add a "while(1);" at the end of there functions to make sure the function cannot return and to delete them using vTaskDelete.

I am not sure what you are trying to achieve but design-wise we usually avoid creating and deleting tasks in runtime in an embedded system, but that is a side-issue .

I finally found that the tasks I have created has actually caused the watchdog timeout. Now I just simply create function for all those pre-defined setpoints. Thanks for your advice.

Thanks you very much