Ohh… This is too much to be a coincidental set of events?
Shows that the initialisation part of the main processor isn’t waiting long enough for the fmu to be ready to operate.
In my case even the no “I/O thread heart beat” message indicates that the main micro is wrongly assuming a fault of the I/O. In fact not waiting long enough!
With ChiBios you don’t need a board safety switch but an external reset switch LOL LOL
Joke apart, I hope the dev in charge of these will see this as a possible improvement to be done.
Henri.
if this is truly repeatable then I’d like to try to work out which part of the initialization is the issue. It is particularly surprising as the bootloader already provides quite a long delay.
Have you tried to install the new ArduPilot bootloader to see if it helps? On MissionPlanner there is a flash bootloader option under the control-F menu.
Cheers, Tridge
Using the above flight controllers, arducopter 3.5.7, 3.6.0 and 3.6.1 -rc1 works fine on Nutx.
They all fail on ChiBios with two errors:
“Bad Logging”
" No I/O thread heart beat"
However resetting the fmu (V2) by pressing the reset switch after the power was applied make the flight controller fully operational including logging (without error).
Someone indicated that a class 10 sd card was a possible solution, but I am very doubtful.
@henrik04 changing the generic 4GB uSD with a 32GB Samsung Class 10 U1 uSD rids me of all the I/O / Logging errors. Tested both on an unknown-source DF13-equipped clone and a banggood 2.4.8 white-case clone. Both work without issues with Nuttx, on 3.6.0 and 3.6.1-rc1. Both exhibit bad logging with their respective cards on ChibiOS unless I plug the “deluxe” Samsung in.
Yes indeed, Once power is apply first pressing the reset button makes the “faulty SD card” As good as gold: No more Bad Logging or No IO Thread heart beat.
You’re using a Pixhawk board of some type? None of my Pixhawk boards have an exposed reset button so I’m slightly confused what button is being pressed…
You’re using a Pixhawk board of some type? None of my Pixhawk boards have an exposed reset button so I’m slightly confused what button is being pressed…
Small changes , but in 3.6.0.rc12 i have the batt voltage multiplier, disappeared in 3.6.1, so how to setup the failsafe?fortunately i found the parameter in QGControl.
We definitely didn’t add or remove any parameters between 3.6.0-rc12 (which is the same as the release 3.6.0) and 3.6.1 so I suspect the issue is either that the mission planner was updated or changed somehow or the BATT_MONITOR parameter was changed.
We will update the battery failsafe wiki page in the coming days but in general it should be possible to setup from the MP’s Mandatory Hardware >> Failsafe page but failing that the BATT_LOW_VOLT is the parameter that stores the voltage at which the failsafe triggers.
Bad logging is coming from frsky passthru, and will be created until something writes to the log like after arming. I asked if we can just remove it as an error would already be generated on a log failure. It’s very misleading. I’m looking at the IO Thread heartbeat, but I can say it is only used by dataflash and is not a general io failure. It also does not get generated if USB is connected because the checks are bypassed because if the sd card is mounted via usb. I think it too may be a timing issue but I’ll know more tonight.
