IO thread died usually means it didn’t get enough CPU, so I suspect something else is hogging the CPU.
I see. So just to give You all the information - this is build I used:
arducopter_with_bl.zip (896.2 KB)
Some more interesting messages onstartup for investigation.
13.04.2025 09:51:25 : u-blox 1 HW: 000A0000 SW: ROM SPG 5.10 (7b202e)
13.04.2025 09:51:24 : No ap_message for mavlink id (271)
13.04.2025 09:51:10 : GPS 1: detected u-blox
13.04.2025 09:51:10 : GPS 1: probing for u-blox at 230400 baud
13.04.2025 09:51:10 : PreArm: Param storage failed
13.04.2025 09:51:10 : PreArm: Rangefinder 1: No Data
13.04.2025 09:51:10 : PreArm: Logging failed
13.04.2025 09:51:10 : PreArm: Battery 1 below minimum arming voltage
13.04.2025 09:51:10 : PreArm: AHRS: waiting for home
13.04.2025 09:51:10 : PreArm: RC not found
13.04.2025 09:51:08 : AP_Logger: IO thread died
13.04.2025 09:51:06 : EKF3 IMU0 MAG0 initial yaw alignment complete
13.04.2025 09:51:06 : EKF3 IMU0 tilt alignment complete
13.04.2025 09:51:05 : AHRS: EKF3 active
13.04.2025 09:51:05 : EKF3 IMU0 initialised
13.04.2025 09:51:03 : Log recovery complete
13.04.2025 09:51:03 : RCOut: DS600:1-4 PWM:5
13.04.2025 09:51:03 : AHRS: DCM active
13.04.2025 09:51:03 : ArduPilot Ready
13.04.2025 09:51:02 : Frame: QUAD/X_REV
13.04.2025 09:51:02 : IMU0: fast sampling 4.0kHz/4.0kHz
13.04.2025 09:51:02 : RCOut: Initialising
13.04.2025 09:51:02 : SpeedyBeeF405AIO 00540041 564D5007 20373736
13.04.2025 09:51:02 : ChibiOS: 88b84600
13.04.2025 09:51:02 : ArduCopter V4.6.0-beta5 (b136aa2b)
BTW, the “No ap_message for mavlink id (271)” message is unrelated. 271 is the CAMERA_FOV_STATUS mavlink message and I think we need to hide this message so users don’t see it. I’ve added this to the 4.6 issues list
1 Like
Lots of your parameters are not supported on 4.6beta5 - please can you post the parameter set from beta5 that is not working. This needs to be tested on a released build, not a custom build.
Does it work on beta5?
Lots of your parameters are not supported on 4.6beta5
Not sure what do You have in mind. I opened mission planner, connected to FC, and on full params list used “write to file”, so not sure how unsupported params would be in this file. This one is not manually changed or something.
This needs to be tested on a released build, not a custom build.
Issue with param storage failed I had also on “release” beta5 build. Not to mention custom build is beta5 build, but with removed some things I do not use (like most of lidars support, landing gear, air speed sensor, frsky telemetry, parachute, etc), and added optical flow, which is not used at this stage.
I belive this
ArduCopter V4.6.0-beta5 (b136aa2b)
indicates that build is clearly on beta5 release commit:
Exactly this one, which is basically last of beta5 releases commits in repo.
For example your parameter list contains parameters from AP_OSD_EXTENDED_LNK_STATS which is off by default. So this is not a vanilla build. Its not just the commit its how it was built. Please post your parameters from a vanilla build that you downloaded from the firmware site.
I do not see such parameter in the file I attached, in MP connected to F405AIO, and on the other FC with beta5 official build connected to MP.
Parameter for example is this one: OSD_W_LQ
Aparently it is supported when You select related build option. Lack of support I would understand as no build option to enable it, or basically there is no source code to build it - which seems not to be the case.
This option is not available in beta5 default build, same as optical flow for this f405AIO, if You do not enable it. But that does not make optical flow unsupported I guess.
Anyway… I will try with official build, shich should not make a difference, as I already had this issue with it, only not trying to fly it then.
I would expect if param is not there is simply ignored and for sure not prevent other params to be apllied and used.
Ok to be clear - you were running a custom build and now you are going to try an official build and post the parameters?
Yes
So.. flashed using MP to beta5 official release. Setup configuration.
Just armed and disarmed, so there is some LOG - about 30kB.
Then set logging when disarmed, as previously, and after pressing write param on messages I have this:
15.04.2025 14:42:15 : PreArm: Param storage failed
15.04.2025 14:42:15 : PreArm: Rangefinder 1: No Data
15.04.2025 14:42:15 : PreArm: Logging failed
15.04.2025 14:42:15 : PreArm: Battery 1 below minimum arming voltage
15.04.2025 14:42:15 : PreArm: GPS 1: Bad fix
15.04.2025 14:42:15 : PreArm: RC not found
15.04.2025 14:42:12 : AP_Logger: IO thread died
15.04.2025 14:42:10 : No ap_message for mavlink id (271)
15.04.2025 14:41:45 : PreArm: Rangefinder 1: No Data
Please post your parameters
Next, disabled logging when disarmed, rebooted and actually tried to arm it. Result is below:
15.04.2025 14:49:05 : Radio Failsafe - Disarming
15.04.2025 14:49:01 : Arm: Param storage failed
15.04.2025 14:49:01 : Arm: Rangefinder 1: No Data
15.04.2025 14:49:01 : Arm: Logging failed
15.04.2025 14:49:01 : Arm: GPS 1: Bad fix
15.04.2025 14:49:01 : Arm: Compass not healthy
15.04.2025 14:49:01 : Arm: Baro: not healthy
15.04.2025 14:48:59 : Radio Failsafe Cleared
15.04.2025 14:48:59 : Radio Failsafe - Disarming
15.04.2025 14:48:58 : PreArm: Param storage failed
15.04.2025 14:48:58 : PreArm: Logging failed
15.04.2025 14:48:58 : PreArm: Baro: not healthy
15.04.2025 14:48:58 : AP_Logger: IO thread died
15.04.2025 14:48:35 : u-blox 1 HW: 000A0000 SW: ROM SPG 5.10 (7b202e)
15.04.2025 14:48:32 : Frame: QUAD/X_REV
15.04.2025 14:48:32 : IMU0: fast sampling 4.0kHz/4.0kHz
15.04.2025 14:48:32 : RCOut: DS600:1-4 PWM:5
15.04.2025 14:48:32 : SpeedyBeeF405AIO 00540041 564D5007 20373736
15.04.2025 14:48:32 : ChibiOS: 88b84600
15.04.2025 14:48:32 : ArduCopter V4.6.0-beta5 (b136aa2b)
15.04.2025 14:48:32 : Frame: QUAD/X_REV
15.04.2025 14:48:32 : IMU0: fast sampling 4.0kHz/4.0kHz
15.04.2025 14:48:32 : RCOut: DS600:1-4 PWM:5
15.04.2025 14:48:32 : SpeedyBeeF405AIO 00540041 564D5007 20373736
15.04.2025 14:48:32 : ChibiOS: 88b84600
15.04.2025 14:48:32 : ArduCopter V4.6.0-beta5 (b136aa2b)
15.04.2025 14:48:32 : Frame: QUAD/X_REV
15.04.2025 14:48:32 : IMU0: fast sampling 4.0kHz/4.0kHz
15.04.2025 14:48:32 : RCOut: DS600:1-4 PWM:5
15.04.2025 14:48:32 : SpeedyBeeF405AIO 00540041 564D5007 20373736
15.04.2025 14:48:32 : ChibiOS: 88b84600
15.04.2025 14:48:32 : ArduCopter V4.6.0-beta5 (b136aa2b)
After that I am not able to connect with MP anymore without rebooting by powercycle.
Params:
Bee35_F405AIO.param (19.4 KB)
Please set INS_GYRO_RATE back to the default - you are never going to get 4Khz on an F4
you might get 2Khz but not 4Khz
2 Likes
I just tried set it to 2kHz (INS_GYRO_RATE =1), reboot, set LOG_DISARMED=1 and same result.
But… despite INS_GYRO_RATE =1, on startujp there is still this line:
15.04.2025 15:54:03 : IMU0: fast sampling 4.0kHz/4.0kHz
Is that somehow downsampled to 2kHz, or param is not working ?
EDIT: It required powercycle to actually start at 2kHz.
Seems setting 2kHz solves the problem. I do not recall setting it to 4kHz, I wonder if that was default or not.
At least it arms properly without throwing any errors related to storage and iothread. Thanks.
PS. Custom build beta5 also works fine with 2kHz gyro 
3 Likes
Sorry, a bit late to report. Flashed beta5 last week on SpeedyBee F405 AIO withSTM32CubeProgrammer using the with_bl.hex compiled using custom firmware builder (I left all features to default). Flashing with betaflight or mission planner in DFU mode did not work.
Mounted the board upside down on a sub250 2.5" cinewhoop, powered with 4s LiHV.
Tested flying in stabilize and alt-hold, I have not done proper compass calibration or magfit, but ublox got some sats (I use Flywoo M10 nano with compass). Logging seems to be fine, did 2 minutes flight to get batch sample, but downloading was painfully slow (about 2 hours).
Prior to this, I tried to compile beta4 using my own hwdef, tune the PID and flew it about 300m in the mountain in loiter mode. I fully erased the board when flashing beta5 and reuse the tuning value on this quad.
I use INS_GYRO_RATE=0 and DSHOT300. Will try to change this later and see if I have the same error with Adam. Here’s my current messages:
16/04/2025 8:18:25 PM : EKF3 IMU0 MAG0 initial yaw alignment complete
16/04/2025 8:18:24 PM : EKF3 IMU0 tilt alignment complete
16/04/2025 8:18:23 PM : AHRS: EKF3 active
16/04/2025 8:18:23 PM : EKF3 IMU0 initialised
16/04/2025 8:18:22 PM : u-blox 1 HW: 000A0000 SW: ROM SPG 5.10 (7b202e)
16/04/2025 8:18:15 PM : EKF3 waiting for GPS config data
16/04/2025 8:18:07 PM : GPS 1: detected u-blox
16/04/2025 8:18:07 PM : GPS 1: probing for u-blox at 230400 baud
16/04/2025 8:18:05 PM : EKF3 waiting for GPS config data
16/04/2025 8:18:04 PM : Frame: QUAD/X
16/04/2025 8:18:04 PM : IMU0: normal sampling 1.0kHz/1.0kHz
16/04/2025 8:18:04 PM : RCOut: DS300:1-4 PWM:5
16/04/2025 8:18:04 PM : SpeedyBeeF405AIO 00290035 564D5007 20373736
16/04/2025 8:18:04 PM : ChibiOS: 88b84600
16/04/2025 8:18:04 PM : ArduCopter V4.6.0-beta5 (b136aa2b)
16/04/2025 8:18:04 PM : Frame: QUAD/X
16/04/2025 8:18:04 PM : IMU0: normal sampling 1.0kHz/1.0kHz
16/04/2025 8:18:04 PM : RCOut: DS300:1-4 PWM:5
16/04/2025 8:18:04 PM : SpeedyBeeF405AIO 00290035 564D5007 20373736
16/04/2025 8:18:04 PM : ChibiOS: 88b84600
16/04/2025 8:18:04 PM : ArduCopter V4.6.0-beta5 (b136aa2b)
16/04/2025 8:18:03 PM : Frame: QUAD/X
16/04/2025 8:18:03 PM : IMU0: normal sampling 1.0kHz/1.0kHz
16/04/2025 8:18:03 PM : RCOut: DS300:1-4 PWM:5
16/04/2025 8:18:03 PM : SpeedyBeeF405AIO 00290035 564D5007 20373736
16/04/2025 8:18:03 PM : ChibiOS: 88b84600
16/04/2025 8:18:03 PM : ArduCopter V4.6.0-beta5 (b136aa2b)
Hopefully I have time to test loiter this weekend. Will report back when I do. Cheers
3 Likes
Reporting back my flight. I managed to do compass calibration and adjustment with magfit. I had to take off and land in alt-hold before switching to pos-hold because of how bad the gps signal near ground (as expected from this tiny antenna).
Hover in pos-hold for about 30s and seems to be doing ok, horizontal position swayed about 15cm back & forward (also left - right), vertical position vary about ± 10cm. Could be the gps signal quality.
Imediately switching to autotune while in pos-hold, once finished, then I landed the copter, switching to alt-hold when about 60cm above ground. I remembered yaapu reporting gps glitch and I couldn’t land on my designated pad (it kept moving around too much).
I was stupid to immediately flew again after I landed, I though I wanna check how the tune went, but that action imediately replaced my logs. Then the weather turned bad (heavy rainfall with thunder) so I couldn’t do further test.
Downloading log from the flash is still fussy. Sometimes when I download a log, it was very slow. Then I cancel the download, power off and on, redownload the same log then it download fast like normal. I find this happens randomly.
Oh, also I tested with gyro rate 2khz and 4khz on the bench and could not replicate what Adam had, very strange.
2 Likes
Do You have notch filters configured somehow? I bet that is some significant load on MCU.