The IMU-f’s comm ready pin will go high when it’s ready to talk again. Give the IMU-f at least 100 µs before trying to read the pin. I just setup a simple delay with an arbitrary number (100) of attempts with a 100 µs delay in each attempt at reading the comm ready pin for butterflight. The only two commands that take any major length of time are the “BL_ERASE_ALL” command, “BL_WRITE_FIRMWARE”, and “BL_WRITE_FIRMWARES” commands. I haven’t included any information about the IMU-f BL yet. I figured making it work in flight before touching the BL was the best route to go.
thanks. Can you point me at a butterflight or betaflight firmware that you know should work as well? To see if the hw is working I’ve tried various versions of butterflight but none seem to work. What I see in the logic analyser is the F4 sending command 121 (COMMAND_REPORT_INFO) and the F3 replying with 32 (BL_LISTENING). It never seems to get past that. I suspect the fw on the F3 is corrupt and the bootloader isn’t starting the main F3 code.
Is there a version of butterflight I can load which will load a new F3 fw? Also, where do I get an image of the F3 fw in case I want to try loading a new F3 fw? I’m thinking of putting it in ROMFS in ArduPIlot.
It sounds like the EXTI pin / COMM Ready pin (PB0) is put high or has the internal pullup enabled after the F4 starts up. That’s what puts the IMU-f into BL mode. If the IMU-f is in BL mode you can fix that by making sure the EXTI pin is low and the F3 gets reset. I’ll add that to the documentation.
BL mode is entered like so:
and a reset is handled like so, but the reset doesn’t happen until after the EXTI is set to a GPIO input with the pulldown enabled:
The Pegasus UI can flash the IMU-f through Butterflight.
Version 3.6.1 of butterflight is here: https://github.com/heliorc/imuf-release/blob/master/butterflight_3.6.1_HELIOSPRING.zip
The IMU-f firmware downloads from here: https://github.com/heliorc/imuf-release-dev
You have an early version of IMU-f 1.1.0 on the F3 right now. I don’t know how well that version will handle fixed wing craft as it’s tuned for quads so it may be best to put version 1.0.8 onto it for now, but I’ve been planing on tuning version 1.1.0 to work well with fixed wing craft as well. Both version 1.0.8 and 1.1.0 use the same parameters, so the documentation you have is valid for both.
I really need to get the bootloader documentation done now.
It’s getting there! Still needs some tuning and the driver isn’t quite finished yet.
A really interesting architecture.
Are you using an external baro?
Have you considered switching out the gyro for an icm20789 or adding baro in future versions?
One of the interesting things about the 20601 the heliospring uses it is has a accel range of +/- 32g, and can sample at 32kHz. That gives it the potential to give good results over a very wide range of vehicles. The 20789 is +/- 16g.
I’ve been really enjoying working with @rs2krs2k on the driver for this board. You’re right that it needs an external baro (and mag) in its current form, but I could imagine future versions that have that builtin.