flight data recorder error - whats about??

[xrider]

hello pilots

yesterday i was flying when i saw a main controller data error during landing on screen.. it wasnt so stable as the previous flight was.. i clicked on it and it was saying "flight data recorder error" .. i thought it was overheating so i ve turned it off and today ive calibrated imu (just in case) and it wasnt so stable in flight.. message showed up again.. it can fly.. restarted.. it dissapeared.. i downloaded flight data to check what was goin on and.. i think i need some help here..

FLY548.log.txt

drive.google.com

FLY549.log.txt

drive.google.com

what are all these about???

 

[quaddamage]

I can't see any issue in these logs.
The errors at end are due to power cutoff, that's normal.


Shouldn't you look at DAT log instead of this short text?

In old version of Go app, there was a function to format the data log sd-card. I think it was removed from the app only - if you send proper packet to your FC, it will format the card and this will most likely fix the issue.

Btw, the card we're talking about is here:

P3 Flight Controller aka MC

Tools for handling firmwares of DJI products, with focus on quadcopters. - o-gs/dji-firmware-tools

github.com

If there's issue with that card, it either has HW issue or SW format issue.
It's best to try formatting it. If that won't work, you'll have to replace it.
Not as easy as it sounds, as the holder is fragile and everything is glued together.

 

[xrider]

I can't see any issue in these logs.

in the beggining?? what are all these about??

Shouldn't you look at DAT log instead of this short text?

want me to upload the .dat files?? okay.. it will take a moment.. i cannot understand if there was some kind of overheating or.. wrong temp on imu calibration

In old version of Go app, there was a function to format the data log sd-card.

there is no way through the app to format the internal sd.. can i do this by connecting to pc or it could make some kind of damage to the drone??

 

[xrider]

okay.. here they are

Meet Google Drive – One place for all your files

Google Drive is a free way to keep your files backed up and easy to reach from any phone, tablet, or computer. Start with 15GB of Google storage – free.

drive.google.com

FLY549.DAT

drive.google.com

i cannot understand what its tryin to tell me.. if it was the heat to blame or something wrong that i did.. ?

 

[quaddamage]

in the beggining?? what are all these about??

I don't think compass fails just after power on are a cause to concern.
You should be more verbose in you questions.

 

[xrider]

I don't think compass fails just after power on are a cause to concern.
You should be more verbose in you questions.

sorry.. this wasnt fail.. it was sitting that moment in a not very good place for a compass.. there was a tiny wire that i couldnt see.. but compass did..

it says somewhere something about escs thats stall and imu that is stuck.. and i can see somekind of flagging and hardfaults.. i really cant understand what are all these.. but these showed up during the data recorder error..

 

[quaddamage]

it says somewhere something about escs thats stall and imu that is stuck.. and i can see somekind of flagging and hardfaults.. i really cant understand what are all these.. but these showed up during the data recorder error..

Heh.. ok, let's go through it.

Note: You are looking at RTOS booting on a micro-controller.

1.795 :       0 IST8303[2:0x18]:Init...
1.800 :       0 IST8303[2:0x18]:set mode failed
1.800 :       0 ist83xx:0 ret:-14
1.800 :       0 IST8303[2:0x1e]:Init...
1.805 :       0 IST8303[2:0x1e]:set mode failed
1.805 :       0 ist83xx:1 ret:-14
2.012 :       0 ms5607:0 ret:0 spi_id:0 init ok
2.420 :       0 [BAT]read barcode data success num:1
2.420 :       0 [BAT]read begin:12211232 end:12345678
2.420 :       0 [BAT]barcode[0]:6171152308289
2.465 :       0 eeprom load  0    0   22   32

Ok, so the uC got power. Now, it doesn't have the OS yet.. it's just a loader. But the loader does initial reboot and initialization of connected HW. Ans what we have connected:
- IST8303 - compass, which is slow to react and can't answer yet
- ms5607 - barometer - which basically says it exists and nothing more, yet
- [BAT] - battery, which presents itself with a serial number, for some reason called "barcode".
And that's it. Now it's time to load the OS. It is stored in Electronically Erasable Programable ROM, and now there's a bunch of messages about reading it. No errors, so nothing interesting.
Next:

4.212 :       0 eeprom load 36 1312   96  104
4.390 :       0 mis cali 55 55 220f fff0 cnt:0
4.390 :       0 imu status:20
4.390 :       0 [hardfault]:******************check fault info and trace ************
4.390 :       0 [hardfault]:-----fault is null: addr(0x40024000),flag(0x9b9bed05)-----
4.390 :       0 [hardfault]:-----fault is null: addr(0x400241a0),flag(0x115105aa)-----
4.390 :       0 [hardfault]:-----task info  is null: addr(0x40024340),flag(0x773c29ee)-----
4.390 :       0 [hardfault]:-----trace info  is null: addr(0x400244d0),flag(0xbade97de)-----
4.390 :       0 [hardfault]:******************check last trace ******************
4.390 :       0 [hardfault]:-----trace info  is null: addr(0x40024790),flag(0xc1b3e860)-----
4.390 :       0 [hardfault]:-----wdg_time_info is null: addr(0x40024a50),flag(0x117fa180)-----
4.390 :       0 startup:4.287657||
4.390 :       0 Board:"wm320v2"

so we got two messages about talking to IMU, some calibration data for it - we can't understand the values anyway, so meh.
Then the RTOS does its initial checking - [hardfault] is not really any real fault, this is how RTOS checks whether its fault mechanisms are working. And then the OS is aware enough to figure out what it is - it proudly claims it's wm320v2 - "I'm a phantom!" it screams.

Next:

4.395 :       0 imu err status 20
4.410 :       1 airport limit inited[1]
4.410 :       1 compass calibration init!
4.410 :       1 [LED] changed: test led when startup
4.410 :       1 app connect changed:last(255) != current(0)
4.410 :       1 assistant connect changed:last(255) != current(0)
4.410 :       1 [FDI MAGN[1]] event:turn on
4.410 :       1 [FDI GYRO[1]] event:turn on
4.410 :       1 [FDI ACC[1]] event:turn on
4.410 :       1 [FDI BARO[1]] event:turn on
4.412 :       1 [FDI AHRS[1]]:turn on
4.412 :       1 [FDI CTRL] event: turn on
4.412 :       1 temp cali (0.000000,0.000000) 0 fw:4 4||
4.413 :       1 temp cali 0 bw:0.000000 0.000000 0.000000 ba:0.000000 0.000000 0.000000||
4.413 :       1 app temp cali (35.000000,65.002945) aa fw:6 6||
4.413 :       1 app temp cali aa bw:-0.000485 -0.000430 0.000706 ba:-0.000182 0.000181 -0.000402||
4.413 :       1 read gps date:20200630

The software initialization continues. IMU seem to still have some error flags set (not sure if 20 is dec or hex, so not sure if 1 or 2 error bits), but compass is now answering. We also turn on LEDs into startup blinking and check temperature calibration data. We enable software events for monitoring various sensors. Even GPS now sends first report.
One thing worth mentioning is that our RAM was filled with '1's at start. Lot of them. ie. eight '1's make the value of 255. So we see report about changing some values from 255 to 0 - which really means that value was just set for the first time.
Next:

4.470 :       4 [esc_is_stall] status changed: last(0xffffffff) != current(0x00000000)
4.472 :       4 [esc_is_empty] status changed: last(0xffffffff) != current(0x00000000)
4.510 :       6 app connect changed:last(0) != current(1)
4.590 :      10 [FDI GPS[1]] event:turn on
4.730 :      17 sub_cmd:10,data_len:15
4.730 :      17 set app type:1
4.730 :      17 sub_cmd:10,data_len:15
4.730 :      17 set app type:1
4.790 :      20 sub_cmd:9,data_len:14
4.790 :      20 MONITOR_CHECK_UUID_SET status:0
4.830 :      22 sub_cmd:9,data_len:14
4.830 :      22 MONITOR_CHECK_UUID_SET status:0
4.910 :      26 sub_cmd:7,data_len:40
4.910 :      26 [set uuid]:937035302917046272
4.910 :      26 sub_cmd:7,data_len:40
4.910 :      26 [set uuid]:937035302917046272
4.912 :      26 uid ex flash index:0
4.912 :      26 iwdg_set_max_timeout befor set swdg_timeout(0x00000120)!
4.912 :      26 iwdg_set_time_out time_out(0x00000ffa)!
4.912 :      26 iwdg_set_swdg_time_out time_out(4090) set g_swdg_timeout_max(0x000007ab) ||

We have even more values which were filled with '1's before - 32 of them make up 0xffffffff.
Some Universally Unique IDentifiers are set, I have no idea what they identify. Doesn't matter.
Then we enable watchdog - iwdg_* lines - it's a mechanism for hang detection, which can reboot the uC if it crashes or hangs, so your drone have a chance of surviving that.
Next:

6.713 :      28 ESC0 link up||
6.725 :      28 ESC1 link up||
6.737 :      29 ESC2 link up||
6.748 :      29 ESC3 link up||
6.748 :      29 esc alive info = 0xf||
6.750 :      30 Battery barcode:6171193104605
6.768 :      30 ESC0 version: Protocol = [V1.0] Hardware = "WM320_ESC_V9"
6.768 :      30 Loader   = [V01.00.02.02]
6.768 :      30 Firmware = [V01.12.00.00] ||
6.777 :      31 ESC1 version: Protocol = [V1.0] Hardware = "WM320_ESC_V9"
6.777 :      31 Loader   = [V01.00.02.02]
6.777 :      31 Firmware = [V01.12.00.00] ||
6.785 :      31 ESC2 version: Protocol = [V1.0] Hardware = "WM320_ESC_V9"
6.785 :      31 Loader   = [V01.00.02.02]
6.785 :      31 Firmware = [V01.12.00.00] ||
6.793 :      32 ESC3 version: Protocol = [V1.0] Hardware = "WM320_ESC_V9"
6.793 :      32 Loader   = [V01.00.02.02]
6.793 :      32 Firmware = [V01.12.00.00] ||

Now we start contacting Electronic Speed Controllers, one by one. Each of them says which firmware it has.
Next:

6.810 :      33 Battery barcode:6171193104605
7.010 :      43 Battery name    :ATL  NVT  DJ005.||
7.010 :      43 manufacture Date:2019/7/27||
7.010 :      43 Serial number   :46||
7.450 :      64 IMU data error 1835 11 0 1 11 11 11 1 12
8.175 :     101 [FDI AHRS[1]]:ahrs_init begin
8.190 :     102 [FDI AHRS[1]]:bias fdi turn on
8.190 :     102 [FDI AHRS[1]]:init fdi turn on
8.190 :     102 [FDI AHRS[1]]:wait for sensor check
8.370 :     111 [LED] changed: imu error

Ok, here's maybe a cause for concern. First the FC talks to battery, sets up some structures required for orientation sensors. But then - it changes the LED blinking scheme to IMU error.

You didn't told your LEDs are blinking indicating an error?
There seem to be IMU issue in your drone.

 

[xrider]

quaddamage woa.. ?

wonderful world of drones.. ??
now that im learning how they interact with each of their systems and the external world.. instantly as i can see..

i have two questions;

how many failsafes do they have?? the watchdog is some kind of that as i can understand.. so.. what exactly it does?? survive the whole system from a crash??

and the second one.. what kind of imu error is it reporting?? was for wrong calibrating temp so i have to calibrate it again??

thanks.. i cant fully understand the fc language and.. you know.. when it wants somenthing from me i feel like "okay.. tell me how can i help in simple words"
?

 

[quaddamage]

how many failsafes do they have?? the watchdog is some kind of that as i can understand.. so.. what exactly it does?? survive the whole system from a crash??

Not the whole system. Each module has a life on its own, and has its own reboot mechanisms.

Watchdog is present in many uCs, it's a standard feature. Almost all embedded devices utilize it, as it's very useful; in some devices, it even allows to hide bad programming which causes constant crashes - the device reboots so fast that the user won't even notice.

What exactly it does - it's a counter which is counting down. When it reaches 0, the device will reboot. So in order for it to not reboot, the counter mus be periodically set back to large value. That's all.

The reboot it causes is so-called "hot boot", because there was no power outage. Boot where power is first supplied to the device is called "cold boot". Hot boot is typically way faster than cold boot, so there is a chance the drone will survive FC crash while in the air.

nd the second one.. what kind of imu error is it reporting?? was for wrong calibrating temp so i have to calibrate it again??

Sorry, no idea what each bit means in the error.. maybe there will be more info in DAT file - but I'm not that good at looking into telemetry, so will let someone else take a look.

 

[Lenj]

Heh.. ok, let's go through it.

Note: You are looking at RTOS booting on a micro-controller.

1.795 :       0 IST8303[2:0x18]:Init...
1.800 :       0 IST8303[2:0x18]:set mode failed
1.800 :       0 ist83xx:0 ret:-14
1.800 :       0 IST8303[2:0x1e]:Init...
1.805 :       0 IST8303[2:0x1e]:set mode failed
1.805 :       0 ist83xx:1 ret:-14
2.012 :       0 ms5607:0 ret:0 spi_id:0 init ok
2.420 :       0 [BAT]read barcode data success num:1
2.420 :       0 [BAT]read begin:12211232 end:12345678
2.420 :       0 [BAT]barcode[0]:6171152308289
2.465 :       0 eeprom load  0    0   22   32

Ok, so the uC got power. Now, it doesn't have the OS yet.. it's just a loader. But the loader does initial reboot and initialization of connected HW. Ans what we have connected:
- IST8303 - compass, which is slow to react and can't answer yet
- ms5607 - IMU - which basically says it exists and nothing more, yet
- [BAT] - battery, which presents itself with a serial number, for some reason called "barcode".
And that's it. Now it's time to load the OS. It is stored in Electronically Erasable Programable ROM, and now there's a bunch of messages about reading it. No errors, so nothing interesting.
Next:

4.212 :       0 eeprom load 36 1312   96  104
4.390 :       0 mis cali 55 55 220f fff0 cnt:0
4.390 :       0 imu status:20
4.390 :       0 [hardfault]:******************check fault info and trace ************
4.390 :       0 [hardfault]:-----fault is null: addr(0x40024000),flag(0x9b9bed05)-----
4.390 :       0 [hardfault]:-----fault is null: addr(0x400241a0),flag(0x115105aa)-----
4.390 :       0 [hardfault]:-----task info  is null: addr(0x40024340),flag(0x773c29ee)-----
4.390 :       0 [hardfault]:-----trace info  is null: addr(0x400244d0),flag(0xbade97de)-----
4.390 :       0 [hardfault]:******************check last trace ******************
4.390 :       0 [hardfault]:-----trace info  is null: addr(0x40024790),flag(0xc1b3e860)-----
4.390 :       0 [hardfault]:-----wdg_time_info is null: addr(0x40024a50),flag(0x117fa180)-----
4.390 :       0 startup:4.287657||
4.390 :       0 Board:"wm320v2"

so we got two messages about talking to IMU, some calibration data for it - we can't understand the values anyway, so meh.
Then the RTOS does its initial checking - [hardfault] is not really any real fault, this is how RTOS checks whether its fault mechanisms are working. And then the OS is aware enough to figure out what it is - it proudly claims it's wm320v2 - "I'm a phantom!" it screams.

Next:

4.395 :       0 imu err status 20
4.410 :       1 airport limit inited[1]
4.410 :       1 compass calibration init!
4.410 :       1 [LED] changed: test led when startup
4.410 :       1 app connect changed:last(255) != current(0)
4.410 :       1 assistant connect changed:last(255) != current(0)
4.410 :       1 [FDI MAGN[1]] event:turn on
4.410 :       1 [FDI GYRO[1]] event:turn on
4.410 :       1 [FDI ACC[1]] event:turn on
4.410 :       1 [FDI BARO[1]] event:turn on
4.412 :       1 [FDI AHRS[1]]:turn on
4.412 :       1 [FDI CTRL] event: turn on
4.412 :       1 temp cali (0.000000,0.000000) 0 fw:4 4||
4.413 :       1 temp cali 0 bw:0.000000 0.000000 0.000000 ba:0.000000 0.000000 0.000000||
4.413 :       1 app temp cali (35.000000,65.002945) aa fw:6 6||
4.413 :       1 app temp cali aa bw:-0.000485 -0.000430 0.000706 ba:-0.000182 0.000181 -0.000402||
4.413 :       1 read gps date:20200630

The software initialization continues. IMU seem to still have some error flags set (not sure if 20 is dec or hex, so not sure if 1 or 2 error bits), but compass is now answering. We also turn on LEDs into startup blinking and check temperature calibration data. We enable software events for monitoring various sensors. Even GPS now sends first report.
One thing worth mentioning is that our RAM was filled with '1's at start. Lot of them. ie. eight '1's make the value of 255. So we see report about changing some values from 255 to 0 - which really means that value was just set for the first time.
Next:

4.470 :       4 [esc_is_stall] status changed: last(0xffffffff) != current(0x00000000)
4.472 :       4 [esc_is_empty] status changed: last(0xffffffff) != current(0x00000000)
4.510 :       6 app connect changed:last(0) != current(1)
4.590 :      10 [FDI GPS[1]] event:turn on
4.730 :      17 sub_cmd:10,data_len:15
4.730 :      17 set app type:1
4.730 :      17 sub_cmd:10,data_len:15
4.730 :      17 set app type:1
4.790 :      20 sub_cmd:9,data_len:14
4.790 :      20 MONITOR_CHECK_UUID_SET status:0
4.830 :      22 sub_cmd:9,data_len:14
4.830 :      22 MONITOR_CHECK_UUID_SET status:0
4.910 :      26 sub_cmd:7,data_len:40
4.910 :      26 [set uuid]:937035302917046272
4.910 :      26 sub_cmd:7,data_len:40
4.910 :      26 [set uuid]:937035302917046272
4.912 :      26 uid ex flash index:0
4.912 :      26 iwdg_set_max_timeout befor set swdg_timeout(0x00000120)!
4.912 :      26 iwdg_set_time_out time_out(0x00000ffa)!
4.912 :      26 iwdg_set_swdg_time_out time_out(4090) set g_swdg_timeout_max(0x000007ab) ||

We have even more values which were filled with '1's before - 32 of them make up 0xffffffff.
Some Universally Unique IDentifiers are set, I have no idea what they identify. Doesn't matter.
Then we enable watchdog - iwdg_* lines - it's a mechanism for hang detection, which can reboot the uC if it crashes or hangs, so your drone have a chance of surviving that.
Next:

6.713 :      28 ESC0 link up||
6.725 :      28 ESC1 link up||
6.737 :      29 ESC2 link up||
6.748 :      29 ESC3 link up||
6.748 :      29 esc alive info = 0xf||
6.750 :      30 Battery barcode:6171193104605
6.768 :      30 ESC0 version: Protocol = [V1.0] Hardware = "WM320_ESC_V9"
6.768 :      30 Loader   = [V01.00.02.02]
6.768 :      30 Firmware = [V01.12.00.00] ||
6.777 :      31 ESC1 version: Protocol = [V1.0] Hardware = "WM320_ESC_V9"
6.777 :      31 Loader   = [V01.00.02.02]
6.777 :      31 Firmware = [V01.12.00.00] ||
6.785 :      31 ESC2 version: Protocol = [V1.0] Hardware = "WM320_ESC_V9"
6.785 :      31 Loader   = [V01.00.02.02]
6.785 :      31 Firmware = [V01.12.00.00] ||
6.793 :      32 ESC3 version: Protocol = [V1.0] Hardware = "WM320_ESC_V9"
6.793 :      32 Loader   = [V01.00.02.02]
6.793 :      32 Firmware = [V01.12.00.00] ||

Now we start contacting Electronic Speed Controllers, one by one. Each of them says which firmware it has.
Next:

6.810 :      33 Battery barcode:6171193104605
7.010 :      43 Battery name    :ATL  NVT  DJ005.||
7.010 :      43 manufacture Date:2019/7/27||
7.010 :      43 Serial number   :46||
7.450 :      64 IMU data error 1835 11 0 1 11 11 11 1 12
8.175 :     101 [FDI AHRS[1]]:ahrs_init begin
8.190 :     102 [FDI AHRS[1]]:bias fdi turn on
8.190 :     102 [FDI AHRS[1]]:init fdi turn on
8.190 :     102 [FDI AHRS[1]]:wait for sensor check
8.370 :     111 [LED] changed: imu error

Ok, here's maybe a cause for concern. First the FC talks to battery, sets up some structures required for orientation sensors. But then - it changes the LED blinking scheme to IMU error.

You didn't told your LEDs are blinking indicating an error?
There seem to be IMU issue in your drone.

What a great detailed report..

Stay safe Len