Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

px4fmu-v2 vs px4fmu-v3 confusion #8809

Closed
julianoes opened this issue Feb 3, 2018 · 23 comments
Closed

px4fmu-v2 vs px4fmu-v3 confusion #8809

julianoes opened this issue Feb 3, 2018 · 23 comments

Comments

@julianoes
Copy link
Contributor

I am trying to flash one of the early 3DR Pixhawks and I'm confused whether to build and flash px4fmu-v2 or px4fmu-v3 because I see conflicting information.

When I boot the Pixhawk I am informed that I should be using 1MB flash only, therefore px4fmu-v2

MCU: STM32F42x, rev. Y

WARNING   WARNING   WARNING!
Revision Y has a silicon errata:
This device can only utilize a maximum of 1MB flash safely!
https://pixhawk.org/help/errata

However, when I try to flash px4fmu-v2, the uploader does not agree:

[100%] Built target nuttx_px4fmu-v2_default.elf
[100%] uploading px4
Loaded firmware for 9,0, size: 985021 bytes, waiting for the bootloader...
Trying /dev/serial/by-id/usb-3D_Robotics_PX4_BL_FMU_v2.x_0-if00
Found board 9,0 bootloader rev 4 on /dev/serial/by-id/usb-3D_Robotics_PX4_BL_FMU_v2.x_0-if00

ERROR: Board can accept larger flash images (2080768 bytes) than board config (1032192 bytes). Please use the correct board configuration to avoid lacking critical functionality.
[100%] Built target upload

I'm assuming the uploader is wrong, right?

@davids5 could you comment?

@julianoes
Copy link
Contributor Author

Why does the bot flag this as a bug?

@PX4BuildBot
Copy link
Collaborator

GitMate.io thinks a possibly related issue is #7675: Some questions about “mc_att_control” hope to get help.

@julianoes
Copy link
Contributor Author

GitMate couldn't be more wrong.

@LorenzMeier
Copy link
Member

The uploader is wrong, yes. This could be the result of a weird combination of Bootloader and silicon errata.

@julianoes
Copy link
Contributor Author

julianoes commented Feb 3, 2018

@LorenzMeier ok, so you think I have "a wrong bootloader revision" ? That's possible since I might have updated these at some point.

@julianoes
Copy link
Contributor Author

So, I can reproduce exactly the same behavior with 3 different Pixhawks, so this batch is consistent and it's probably not some bootloader that I flashed myself.

@julianoes
Copy link
Contributor Author

The silicon check was added to the bootloader with revision 5: https://github.com/PX4/Bootloader/pull/47/files.

My pixhawks have bootloader revision 4 and therefore should be defaulted to 1MB.

@LorenzMeier
Copy link
Member

#8811

@LorenzMeier
Copy link
Member

My PR tries to do something more complex, it might be easier as you suggested to just default any v4 board that reports larger than 1M to 1M.

@julianoes
Copy link
Contributor Author

Ok thanks, this let's me flash px4fmu-v2 again.

The other question is if we should prevent flashing v3 for older bootloaders where we don't know if it is safe?

@LorenzMeier
Copy link
Member

I think we should prevent flashing > 1M images on old boot loaders, yes.

@julianoes
Copy link
Contributor Author

Ok, do you want to add it to your PR, or should I?

@LorenzMeier
Copy link
Member

Makes more sense if you go ahead as you have the test setup.

@julianoes
Copy link
Contributor Author

Ok, will do.

@julianoes
Copy link
Contributor Author

julianoes commented Feb 3, 2018

as you have the test setup.

You could call it that 😄 #moreismore

dsc_0203

@julianoes
Copy link
Contributor Author

@LorenzMeier done, commits added to #8811.

@dagar
Copy link
Member

dagar commented Feb 3, 2018

I did a quick pass and many of the newer fmu-v2/v3 boards still have bootloader version 4.

  • pixhawk mini
  • mRo pixhawk
  • pixhack v3
  • holybro pixhawk (brand new)

@julianoes
Copy link
Contributor Author

@dagar do you agree with the change though? Or do you think we should only display a warning?
Or should we support a script that updates bootloaders?

@dagar
Copy link
Member

dagar commented Feb 4, 2018

The safest thing to do is stick with px4fmu-v2_default if the the bootloader is older than revision 5, but there are obviously plenty of cases where that's annoying.

@julianoes
Copy link
Contributor Author

@dagar Ok, the change went in. Do we need to do the same for QGC?

@julianoes
Copy link
Contributor Author

I was told on the dev call that this is correct for QGC and it looks indeed correct:
https://github.com/mavlink/qgroundcontrol/blob/af45d4ad275968332afb43d18145ccd244b200fb/src/VehicleSetup/Bootloader.cc#L586-L591

Closing.

@cdlwhm1217096231
Copy link

@LorenzMeier
I am new to this and I just followed from fresh install ubuntu 16.04 from devpx4 site and I got problem when running make px4fmu-v2_default, here is the error that I got

[100%] Linking CXX executable ../../nuttx_px4fmu-v2_default.elf
Error running link command: No such file or directory
platforms/nuttx/CMakeFiles/nuttx_px4fmu-v2_default.elf.dir/build.make:186: recipe for target 'nuttx_px4fmu-v2_default.elf' failed
make[3]: *** [nuttx_px4fmu-v2_default.elf] Error 2
CMakeFiles/Makefile2:5100: recipe for target 'platforms/nuttx/CMakeFiles/nuttx_px4fmu-v2_default.elf.dir/all' failed
make[2]: *** [platforms/nuttx/CMakeFiles/nuttx_px4fmu-v2_default.elf.dir/all] Error 2
Makefile:105: recipe for target 'all' failed
make[1]: *** [all] Error 2
Makefile:153: recipe for target 'px4fmu-v2_default' failed
make: *** [px4fmu-v2_default] Error 2

@julianoes
Copy link
Contributor Author

@cdlwhm1217096231 this looks like a separate issue, please create a new issue for this and share all the build output, and make sure to do a make clean as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants