I have a Pixhawk clone board bought 3-4 years ago, the first Pixhawk generation. There are 2 fw in the firmware server :–
One for Pixhawk1 and the other for Pixhawk1-1M.
What is the difference ? How should I choose ?
Thank you.
Pixhawk 1M is 1MB flash limit, both are FMUv2.
With the new revision like mro x2.1 or mro pixhawk they are both FMUv3.
As you have the early version of the pixhawk you can flash the regular version.
Is the flash limit referring to capacity of the SD card ?
It seems not. So what does it refer to ?
Flash memory on the CPU. If you want to read all about it:
Both Pixhawk1 and Pixhawk1M are fmuv3. Pixhawk1M includes:
FLASH_SIZE_KB 1024
define HAL_MINIMIZE_FEATURES 1
undef STORAGE_FLASH_PAGE
If you Flash a board with 1Mb with the non 1M version you will see errors in the messages screen of Mission planner on boot and USB will randomly disconnect.
Hi Dave, My Pixhawk is earlier version , dated back to 2014-15.
Few days ago,I flashed Copter 4.0.3 in the "Install Firmware"page of MP. I suppose that FW is Pixhawk1, NOT Pixhawk1-1M build. Pls confirm.
So now I cannot get logging, and after connecting to MP via USB, without turning on the transmitter, the receiver constantly brinks,
suppose no light at all if transmitter is off. So strange behavior.
Should I flash the Pixhawk1 build in the firmware server ? Should I choose arducopter or arducopter with bl ?
Really appreciate yr help
Go ahead and Flash the 1M firmware then. Download it (.apj file) from the repository and use the “load custom firmware” option in Mission Planner to flash it.
Most receivers will flash if the Transmitter is not connected and then a solid light when they are…
Hi Dave,
I just flashed the .apj file of Pixhawk1 from the firmware server, using “Load custom firmware” option in MP. As soon as I plug in the USB, the COM port (67) is STMicroelectronic Virtual COM.
After flashing, I still cannot arm the motors with logging. Have to disable logging in ARMING_CHECK before able to arm. So flashing with Pixhawk1 does not help.
Sometimes when I plug in USB, the COM port goes to another one (say COM 5), and I tried this port, but was denied.
My trouble is, I am willing to revert back to any previous fw including Copter 3.6.x, so I can have logging available, but flashing was denied because board was not detected.
Any clue ?
Thanks
Assuming you have LOG_BACKEND_TYPE back to 1, no further ideas. Reformat the Sd card or replace it with a faster one maybe.
1 Like
The COM port issue is known - with later versions of AC on windows you tend to end up with a different COM port for bootloader mode vs regular connection, and one will not work with the other. I think the change in windows driver coming will make this better, but I find I often have to “force bootloader” in MP then find out where the new COM port is and then upload to that. Later (beta) versions of MP seem to have got this logic correct so you probably want to try that.
Yes, I set LOG_BACKEND_TYPE to 1, Also reformat the SD card to FAT, and the card is class 10. All these did not help.
For the time being, I just disable logging so I can arm. Hope sometime later, hope will come so I can enable logging.
Anyway thank you for yr help.
It’s worth noting that some pixhawks can be updated. I just updated two of mine yesterday that have the working 2mb flash, wherea as before they only took the 1m version. I used Qgroundcontrol to update the bootloader (mission planner can supposedly do it but it kept failing for me). After that I updated back to Arducopter (I had to use force bootloader option for it to work), and it’s now detected as a FMUv3 instead of FMUv2. Might not work with really old ones but mine was a clone I bought in mid 2017 and the other was one I just bought second hand and both updated ok but maybe I was lucky.
https://docs.px4.io/v1.9.0/en/advanced_config/bootloader_update.html
From what I’ve seen though there’s not many features you miss out on and that was on nuttx, I’m not sure what’s missing on chibios.
05/03/2020 22:31:54 : fmuv3 00XXXXXX XXXXXXXX XXXXXXXX
05/03/2020 22:31:54 : ChibiOS: d4fce84e
05/03/2020 22:31:54 : ArduCopter V4.0.3 (ffd08628)
How do you do “force bootloader” in MP ?
I followed the procedure outlined in the link you provided, but stuck when failing to enable SYS_BL_UPDATE by changing the default value from 0 to 1. Error msg says failed to write param. Firmware update did not automatically continue, even after reboot. See attached screen shots.
Probably only bootloader update is completed.
When I connect to MP, the COM port is Legacy FMU COM5, versus the original STMicroelectronic COM67, and I can’t connect to MP. Flashing with previous and current fw are denied.
All the steps happened are very confusing, not following exactly the steps in the link, and I can’t describe precisely what happened.
Any suggestions ?
Thank you.
If you didn’t change that parameter then it won’t have updated the bootloader.
Sorry I didn’t realise that page didn’t say it, you need to flash Developer Build (master) with qgroundcontrol. You should be able to then change the update bl flag, then you just save it and then reset the board (disconnect/reconnect the power) and it should take slightly longer to start up. At this point it says to then update again with qground control but that wasn’t working for me as it wouldn’t go into bootloader mode for more than a few seconds (same in mission planner). Instead in mission planner at the bottom there is a force bootloader mode, click that and it’ll reboot into the bootloader and then you can use mission planner to update it to the latest build and the board should be listed as an FMUv3 then.
https://docs.px4.io/v1.8.2/en/advanced_config/bootloader_update.html
Good day, if you want update your pixhawk bootloader, just use MP… connect it press ctrl+f and you will find the option for update it, after this you can flash the new 4.0.3 firmware.
The page did say flash (Developer Build) master, and OI chose that option. I followed the steps to the words in the link you provided.
After changing the SYS_BL_UPDATE to 1 from 0 (no error msg appeared this time) and rebooting, I got an error msg saying
cannot find file in COM5 (see attached). I messed up the bootloader earlier and now when I connect the board to USB, it is Legacy FMU COM5, instead of the STMicroelectronic COM67. This is the problem.
I also attach a screen shot showing the default PX4Pro flight stack which I chose, also Developer Build. I am now stuck, and the board is useless with a bad bootloader.
Appreciate yr continued support
I have lost track of what you are trying to accomplish but the PX4Pro Flight Stack is not Arducopter. If you want to try the PX4 Flight Stack you are in the wrong forum. That can be found here:
Let’s assume you want to load Pixhawk1M on that board. If you do not know if it has 1Mb or 2Mb that would be the best choice. From the Mission Planner Install Firmware screen click “All Options” and then these choices in the menu. Follow the on-screen instructions to update.
And after all the fiddling around you have done it would be wise to “Reset to Default” and start over with the configuration. That button is on The Full Parameter List screen.
What I want to accomplish is : when I updated my Pixhawk (first generation) from Copter 3.6.5 to 4.0.3,
things started to get weird. Eventually I think I messed up with the bootloader after trying different things.
Right now, in the COM port, it shows Legacy FMU COM5. I am not allowed to flash any current or previous
Copter fw, but am allowed to flash previous Arduplane fw, such as AP3.9.x.
Just now, I followed yr instruction, but did not get “All options” in both “INSTALL FIRMWARE” and “INSTALL FIRMWARE MANIFEST” screen. See attached screen shots. My MP is up to date. Do you have an earlier version of MP which has “All options” ?
Again, thanks you for yr patience.
You’ve probably updated the bootloader if you changed the parameter, all you need to do is connect it, click the force bootloader button in your screenshot, then click the version of firmware you want, you don’t need to load custom or pick the version with all options, it should just detect it properly if the bootlaoder is updated it then once update it’ll be recognised properly again. You could also try the update bootloader option in your screenshot.