I received a new RadioLink Mini-Pix, and it booted nicely after unboxing. Then I decided to flash a newer ArduCopter build into it. With a Linux host, I however noticed that the bootloader thought the device was a ‘PX4Flow’.
So to get things lean, I booted the device into STM32 DFU mode and flashed in a stable AC 3.6.11 with bootloader (mini-pix build) using BetaFlight flasher, ticking ‘erase whole chip’ checkbox.
Now the Mini Pix does not boot past the bootloader, while rapidly flashing red light. I can, however, reflash with QGroundControl or Mission Planner a different firmware - I tried 4.0rc1 Copter, different Plane builds (to erase any settings) but the thing just won’t boot further. I also DFU-flashed recent ChibiOS bootloaders, even one that I built out of latest git. No success.
When I flash AC 4.0rc1, the device goes slightly past the bootloader (Linux dmesg indicates the device first as a mini-pix-BL, then as a mini-pix, disconnecting USB in between). However it hangs there immediately, with only power led on.
I also added an sdcard to get diagnostics. While booting, it does create the directory ‘APM’ for logging, but the directory remains empty.
I’ve handled the device carefully what comes to static electricity etc, but have I now actually bricked it? Could it be that due to that PXFlow strangeness, the STM32 is somehow retaining incorrect boot registers? How could I truly reset it?
Getting even stranger - I can flash a BetaFlight STM32F405 image into the Mini Pix and it runs and connects normally. Flashing back to ArduPilot still hangs.
After some dfu-util wrangling I got both mini-pix bootloader and latest mini-pix binary uploaded. With latest and beta, the board boots further (red blinking stops after a few seconds) and the console outputs a single line:
Successfully mounted SDCard (slowdown=0)
(without SDCard installed, it just outputs a linefeed)
Furthermore, when the hardware safety button w/led is connected, the safety led lits up after a few seconds and can be toggled into triple-flashing and back to solid mode with the button.
So the image clearly boots to some extent, but there’s no mavlink on any ports and the main board led stays off. Linux detects /dev/ttyACM0 normally.
Would anyone have a working, even RadioLink binary backed up? I thought about this only after trying to update for the first time…
OK I figured it out. My Mini Pix is built as recently as 9/9/19, which means that it does not have the Ramtron FRAM chip installed, as the HWDEF file assumes. Building the bootloader and Ardupilot with Vierfuffzig allows it to boot:
ok, thanks a lot! seems we need to add a V1.0 II hwdef for that board revision if we want to keep up support…
good thing is they didn‘t fix the telemetry ports‘ inversed case imprint, so no need to change the documentation too
My minipix is also version1.0II.
I replaced the source of ArduCopter3.6.12 with AP_HAL_ChibiOS / hwdef / mini-pix / hwdef.dat and AP_HAL_ChibiOS / hwdef / mini-pix / hwdef-bl.dat of vieruffuffzig, and writing was successful.
However, after the first flashing red, the LED turns on and stops there.
ArduCopter does not start.
Hi, could I load the firmware you modified to download it and install it on my mini pix? I have exactly the same problem, and my mini pix has been completely disabled, thanks.
Hi, could I load the firmware you modified to download it and install it on my mini pix? I have exactly the same problem, and my mini pix has been completely disabled, thanks.
I have the same problem. Mini Pix 1.0II without Ramtron FRAM chip. I have complied source provided by Pasi and load it with BetaFlight, but it does not boot properly. Initially, light goes pinkish for a very short moment, afterwards red light starts flashing and a few seconds later it stops.
If I boot Pix with QGC open, red light does not stop flashing and I can re-flash the board.
I would like to troubleshoot this problem, but I am not sure how to get boot logs ?
Just solved the problem. If someone else has the same problem, first build and upload new bootloader. And in the second setup upload ardupilot. Make sure to use linux tools (dfu-util and waf).
First, I built boot loader by waf with Pasi’s source code.
Then I wrote it by dfu-util after rebooting mini-pix providing 3.3V.
Finally, I used waf to upload arducopter.
But it is not working at the moment.
Have you used the binary of arducopter that you have built or some other version ? I guess other version might also work, as the main patch is applied to the bootloader ? I have used exact same version that Pasi has on github(MiniPix branch).
I followed exact same procedure that you did. I could not use latest version of arducopter as flash is too small. So I have used MiniPix branch that is slightly older version, but still fine for me.
