It does matter. If you have a Pixhawk with 1Mb flash it requires a reduced feature set. There are many boards with 1Mb flash. On those boards you will find this in the Hwdef (hardware definition) file:
define HAL_MINIMIZE_FEATURES 1
Dave, I understand it does— matter. I just want to know how to verify this information what FMU is inside PixHawk.
Where do i find this file HAL_MINIMIZE_FEATURES 1?
1 Like
It DOES matter. Locate your board here and review the hwdef.dat file. That statement is usually near the end.
So this file is stored on the SD card inside Pixhawk?
The only sure method is if you open your PIxhawk and check the revision of the main processor. If it is RevA, RevY and Rev1 then you have an 1M board, other (most likely Rev3) is 2M.
4 Likes
No, not stored on the card, used during the compile process to produce the correct firmware for the hardware present.
Until you update the bootloader both my FMUv3’s were detected as FMUv2. Once they bootloader was updated and I flashed them they were detected properly. The nsh command didn’t seem to work on chibiOS.
Thanks. I surprised that there is no soft command that can retrieve FMU type…oh well
ok. This kind of sucks. Has anyone ever looked into any type of command that can pull FMU type inside the PixHawk…Maybe we need to add this feature once in for all if supported by the FMU’s.
The 1Mb issue has been around for 5yrs or so and it really hasn’t presented a problem. Even before 3DR gave up the ghost making Pixhawk Flight Controllers they had transitioned to the Ver3 chip and all the cheap clones that followed did also. There are some exceptions and I have one. The HobbyKing HKPilot32 board had 1Mb. At least the one I have does. I install the Pixhawk1-1M and lack Lua scripting, Soar functions and Beacon and maybe something else I’m forgetting. Not a big deal. And with the F4/F7 bare type boards you know what you are getting.
1 Like
Why to do that, it only impacts a first couple of batches of and ancient, end of production flight controller.
The new bootloader can detect revision and will update the right firmware.
Regarding to 2.4.8 there is no such version of the pixhawk hw, cheap crappy chinese copies calling themselves 2.4.8 because they left out half of the components that supposed to be in a 2.4.6 hw. If you cut cost and buy a 2.4.8, then don’t be furious if you have to update the bootloader manually.
1 Like
There are three reasons we should have such a feature:
- Identify old purchases.
- Verify new purchases.
- keep my sanity checked when run into problems.
This should be standard feature inside PixHawk just like all other processor based devices.
I don’t think so. The PR list for Ardupilot is pretty long with much higher priority topics I would say.
- Old purchases are few and far between and <5yrs old now. No one is really talking about this anymore.
- New purchases are a known quantity.
- OK
It is a standard feature of the bootloader, just like any other processor based devices.
case 1 : If your board is new and purchased from a reliable source, has a correct bootloader, then it will be identified correctly and an appropriate firmware will be loaded.
case 2: If you purchased an old used board, then before do anything, update the bootloader, then goto case 1.
case 3 : if your newly purchased board is a crappy copy with some ancient bootloader then update the bootloader and go to case 1.
I am facing same issue
What issue would that be?
Determining PixHawk FMU version
Sorry to share it here
Today again my hexacopter crashed that too from height
Flight Controller: PIXHAWK PX4 2.4.7
Firmware version Copter 4.0.5
Transmitter: “FrSky Taranis Q X7 ACCESS 2.4GHz 24CH Mode2 Transmitter with R9M 2019”
ESC: Hobbywing XRotor 40A-OPTO ESC
Motors: Tarot 4108 High Power Brushless Motor (380kv)
Battery:6S.
Frame:Tarot 680Pro
Log:
Can anybody have look at log and help me what was wrong.