Experiencing apparently solved problems with SD deck

Discussions and questions about the Crazyflie Nano Quadcopter
dominik.natter
Beginner
Posts: 17
Joined: Tue Jun 01, 2021 6:38 am

Re: Experiencing apparently solved problems with SD deck

Post by dominik.natter »

Hei,

I fixed the greyed-out-button-problem by updating the cfclient, nevermind. I can now see that about 30% of the CPU are labeled as IDLE. Still, the assert fails. So as you said it's probably that things do not happen quickly enough, not that we have used up all the CPU already. Is there a possibility to increase the time an assert waits before failing? Or maybe you have another idea. Even if it does not happen in every case, this is still a bug that slows down development a bit.

Here's an excerpt of an exemplary console output (the "adding Nstate ..." lines are from our code in case u wonder):

Code: Select all

...
SYSLOAD: Task dump
SYSLOAD: Load	Stack left	Name
SYSLOAD: 3.62 	174 	Tmr Svc
SYSLOAD: 3.03 	91 	LEDSEQCMD
SYSLOAD: 32.88 	128 	IDLE
SYSLOAD: 1.13 	108 	CRTP-SRV
SYSLOAD: 0.05 	133 	USDLOG
SYSLOAD: 0.06 	49 	P2P-SWARM
SYSLOAD: 0.0 	76 	PWRMGNT
SYSLOAD: 0.56 	73 	MR
SYSLOAD: 1.77 	213 	CRTP-RX
SYSLOAD: 29.94 	261 	LPS
SYSLOAD: 0.05 	161 	app
SYSLOAD: 0.0 	317 	USDWRITE
SYSLOAD: 0.0 	108 	PLATFORM-
SYSLOAD: 0.0 	252 	LOG
SYSLOAD: 0.0 	257 	PARAM
SYSLOAD: 0.0 	223 	MEM
SYSLOAD: 0.12 	156 	SYSTEM
SYSLOAD: 0.10 	61 	CRTP-TX
SYSLOAD: 5.10 	367 	STABILIZE
SYSLOAD: 6.93 	143 	SENSORS
SYSLOAD: 2.53 	175 	SYSLINK
SYSLOAD: 12.05 	326 	KALMAN
SYSLOAD: 0.0 	113 	USBLINK
SYSLOAD: 0.0 	255 	CMDHL
adding Nstate 164 (f: 0, uwb: 1)
adding Nstate 164 (f: 0, uwb: 1)
adding Nstate 164 (f: 0, uwb: 1)
adding Nstate 164 (f: 0, uwb: 1)
adding Nstate 164 (f: 0, uwb: 1)
adding Nstate 164 (f: 0, uwb: 1)
uSD: Logging to: sd_log59
adding Nstate 164 (f: 0, uwb: 1)
SYS: ----------------------------
SYS: Crazyflie 2.1 is up and running!
SYS: Build 24:c2790c0d9ed6 (2022.01 +24) MODIFIED
ash!
CFGBLK: v1, verification [OK]
DECK_CORE: 3 deck(s) found
DECK_CORE: Calling INIT on driver bcUSD for deck 0
uSD: mount SD-Card [OK].
DECK_CORE: Calling INIT on driver bcMultiranger for deck 1
uSD: wait for sensors
DECK_CORE: Calling INIT on driver bcDWM1000 for deck 2
IMU: BMI088: Using I2C interface.
IMU: BMI088 Gyro connection [OK].
IMU: BMI088 Accel connection [OK]
IMU: BMP388 I2C connection [OK]
ESTIMATOR: Using Kalman (2) estimator
CONTROLLER: Using PID (1) controller
MTR-DRV: Using brushed motor driver
SYS: About to run tests in system.c.
EEPROM: I2C connection [OK].
STORAGE: Storage check [OK].
IMU: BMI088 gyro self-test [OK]
DECK_CORE: Deck 0 test [OK].
MR: Init front sensor [OK]
MR: Init back sensor [OK]
MR: Init up sensor [OK]
MR: Init left sensor [OK]
MR: Init right sensor [OK]
DECK_CORE: Deck 1 test [OK].
DECK_CORE: Deck 2 test [OK].
SYS: The system resumed after a failed assert [WARNING]
SYS: Assert failed at crazyflie-firmware/src/deck/drivers/src/usddeck.c:795
SYS: cfAssertNormalStart [FAIL]
SYSLOAD: Task dump
SYSLOAD: Load	Stack left	Name
SYSLOAD: 2.28 	231 	Tmr Svc
SYSLOAD: 89.82 	128 	IDLE
SYSLOAD: 1.12 	156 	SYSTEM
SYSLOAD: 1.44 	213 	CRTP-RX
SYSLOAD: 0.0 	76 	PWRMGNT
SYSLOAD: 0.0 	267 	app
SYSLOAD: 0.0 	262 	LOG
SYSLOAD: 0.0 	118 	PLATFORM-
SYSLOAD: 0.0 	255 	CMDHL
SYSLOAD: 0.0 	354 	KALMAN
SYSLOAD: 0.0 	199 	USDLOG
SYSLOAD: 0.0 	227 	MR
SYSLOAD: 0.0 	417 	LPS
SYSLOAD: 0.0 	187 	SENSORS
SYSLOAD: 0.0 	369 	STABILIZE
SYSLOAD: 0.0 	266 	MEM
SYSLOAD: 0.01 	71 	CRTP-TX
SYSLOAD: 0.0 	261 	PARAM
SYSLOAD: 2.02 	175 	SYSLINK
SYSLOAD: 2.25 	91 	LEDSEQCMD
SYSLOAD: 1.0 	108 	CRTP-SRV
SYSLOAD: 0.0 	113 	USBLINK

tobias
Bitcraze
Posts: 2339
Joined: Mon Jan 28, 2013 7:17 pm
Location: Sweden

Re: Experiencing apparently solved problems with SD deck

Post by tobias »

Are you getting different asserts or mainly the one in the usddeck.c @795:

Code: Select all

static void usdWriteData(const void *data, size_t size)
{
  UINT bytesWritten;
  FRESULT status = f_write(&logFile, data, size, &bytesWritten);
  ASSERT(status == FR_OK);
  crc32Update(&crcContext, data, size);
  STATS_CNT_RATE_MULTI_EVENT(&fatWriteRate, bytesWritten);
}
This is due to that the f_write fails for some unknown reason. By printing the status we can probably find out why. You could try e.g.

Code: Select all

static void usdWriteData(const void *data, size_t size)
{
  UINT bytesWritten;
  FRESULT status = f_write(&logFile, data, size, &bytesWritten);
  if (status != FR_OK)
  {
    DEBUG_PRINT("Write failed err:%d\n", status);
  }
  crc32Update(&crcContext, data, size);
  STATS_CNT_RATE_MULTI_EVENT(&fatWriteRate, bytesWritten);
}
The task dump is measured over the past second, if I recall correctly, so you should do a dump when you are logging to sd-card to get more accurate figures.
dominik.natter
Beginner
Posts: 17
Joined: Tue Jun 01, 2021 6:38 am

Re: Experiencing apparently solved problems with SD deck

Post by dominik.natter »

Hei,

thanks for the tip. I think usddeck is the main place where asserts happen, but I've seen other ones popping up too from time to time. I'll use such print commands to provide you (us) with some information about the asserts. Hopefully, I will do more tests next week.

Best,
Dominik
dominik.natter
Beginner
Posts: 17
Joined: Tue Jun 01, 2021 6:38 am

Re: Experiencing apparently solved problems with SD deck

Post by dominik.natter »

just to keep you informed: I had a month-long break regarding testing, but in March it worked rather smoothly. So I'll keep your suggestions in mind, but can't provide useful information for the community as of now.
Post Reply