Moving Code from Deck-Driver to App-Layer

[giggi]

Hi everyone,

I've moved all my code, which was implemented on the Deck-Driver to the app-Layer for better version control and future updated.
It basically consists of 2 FreeRTOS-Tasks which use the Loco-Deck to measure distances to other drones in the swarm.
Those tasks have the highest priority, which worked on the deck. As soon as I connect to the client over the radio, the radiolink.c throws an error:

SYS: The system resumed after a failed assert [WARNING]
SYS: Assert failed at ../crazyflie-firmware/src/hal/src/radiolink.c:164
SYS: cfAssertNormalStart [FAIL]

Everything works like a charm, as long as I do not connect to the client, or connect with the python-lib.
Lowering the priority of the tasks solves the issue, so my code is probably taking too much computation-power. But it is the same code I used on the deck-driver.

Can you may tell me, how differently the firmware handles deck-drivers compared to code on the app-layer?
Is there a different way of allocating memory an CPU-time?

Sometimes (between 10 to 30min after start) I get the following error, even without connecting to the client:

SYS: The system resumed after watchdog timeout [WARNING]
SYS: watchdogNormalStart [FAIL]

As far as I now the watchdog kicks in if the IDLE-task does not get executed after a certain time, right?

I am not sure if this is related, but may helps in solving the issue.

Thanks a lot in advance,
Michael

[kimberly]

Hi!

Not exactly sure what is going on so let's figure it out! So I'm assuming that you used the deck driver version also on a latest version of the firmware right?

Could you perhaps share the build information (after 'make all' at the very end) of both the app layer and the deckdriver. It should be right behind 'Crazyflie build!'

And in the cfclient, when connecting with USB, could you also do a Task Dump of both cases and share them here as well?

[giggi]

Hi Kimberly

Thanks for the fast reply!
Here is the output from make:

Flash | 257312/1032192 (25%), 774880 free | text: 251304, data: 6008, ccmdata: 0
RAM | 92292/131072 (70%), 38780 free | bss: 86284, data: 6008
CCM | 58540/65536 (89%), 6996 free | ccmbss: 58540, ccmdata: 0

And this is the task-dump:

SYSLOAD: Task dump
SYSLOAD: Load Stack left Name
SYSLOAD: 0.30 230 Tmr Svc
SYSLOAD: 72.83 127 IDLE
SYSLOAD: 0.05 247 CRTP-RX
SYSLOAD: 6.13 341 Anchor
SYSLOAD: 0.0 78 fly_task
SYSLOAD: 0.0 53 PWRMGNT
SYSLOAD: 5.22 151 SENSORS
SYSLOAD: 1.59 75 ZRANGER2
SYSLOAD: 0.01 4882 app
SYSLOAD: 0.0 421 UWB
SYSLOAD: 1.98 191 FLOW
SYSLOAD: 0.0 313 LPS
SYSLOAD: 0.0 117 CRTP-SRV
SYSLOAD: 0.0 115 PLATFORM-
SYSLOAD: 0.0 255 LOG
SYSLOAD: 0.0 223 MEM
SYSLOAD: 0.02 104 USBLINK
SYSLOAD: 0.06 91 PARAM
SYSLOAD: 0.88 157 SYSTEM
SYSLOAD: 0.08 61 CRTP-TX
SYSLOAD: 0.14 93 LEDSEQCMD
SYSLOAD: 0.20 206 SYSLINK
SYSLOAD: 3.91 367 STABILIZE
SYSLOAD: 6.46 309 KALMAN
SYSLOAD: 0.0 255 CMDHL

The "Anchor" and "UWB" are the tasks created by me.
"fly_task" is only polling every 300ms for a specific Param, so this task does not have big computation.

Hi!

Not exactly sure what is going on so let's figure it out! So I'm assuming that you used the deck driver version also on a latest version of the firmware right?

Could you perhaps share the build information (after 'make all' at the very end) of both the app layer and the deckdriver. It should be right behind 'Crazyflie build!'

And in the cfclient, when connecting with USB, could you also do a Task Dump of both cases and share them here as well?

[kimberly]

Thanks!

Hmmm.. it seems that the task app is using a lot of stack... What did you fill in for the APP_STACKSIZE define makefile of the app layer?

[giggi]

Tried multiple from 1000 to 10000.
But did not make a difference...

Thanks!

Hmmm.. it seems that the task app is using a lot of stack... What did you fill in for the APP_STACKSIZE define makefile of the app layer?

[kimberly]

A 1000 might already be too much. Have you tried to do 300 ? That is the default of the examples that we are using.

[giggi]

Using 300 works as well, without connecting to the client.
But when I connect, it fails again.
But with a different Error:

SYS: The system resumed after a failed assert [WARNING]
SYS: Assert failed at ../crazyflie-firmware/src/drivers/src/uart_syslink.c:383
SYS: cfAssertNormalStart [FAIL]

A 1000 might already be too much. Have you tried to do 300 ? That is the default of the examples that we are using.

[kimberly]

Hmmm... The asserts are probably random at this point... so they are indicating that something is overflowing but it will be impossible to pinpoint the exact location, as the assert don't make sense.

I've tried to look the app layer and the hello-world example only takes up, and there are no crashes.

Code: Select all

SYSLOAD: 0.0 	204 	app

Which is a lot less of what your task dump was saying so far. Perhaps it's an idea to start from that same example with the same makefile, and just slowly add your code to it until it seems to fail. It would be good to have a minimal viable example of what you are seeing.

[giggi]

Thanks a lot for checking on that!
Actually, that's the way I build up the app.
I've started from the example and added the code from my deck-driver.
If I disable the code which is using the locodeck, then everything works. But that is actually my contribution, to use the locodeck to measure the distance to other drones
There has to be some difference when moving from the deck-driver to the app-layer...

What do you mean by that:
"It would be good to have a minimal viable example of what you are seeing." ?

Do you want to see the code or the output, ?

Hmmm... The asserts are probably random at this point... so they are indicating that something is overflowing but it will be impossible to pinpoint the exact location, as the assert don't make sense.

I've tried to look the app layer and the hello-world example only takes up, and there are no crashes.

Code: Select all

SYSLOAD: 0.0 	204 	app

Which is a lot less of what your task dump was saying so far. Perhaps it's an idea to start from that same example with the same makefile, and just slowly add your code to it until it seems to fail. It would be good to have a minimal viable example of what you are seeing.

[marcus]

Hi!

Kimberly is off on vacation so I just wanted to check how things are going with this. Did you manage to get it working?