Pixhawk4 fails to connect to the bootloader

[raptorrex6]

When I try to upload my own code, or even a simple example to the pixhawk 4, It goes into and endless loop when trying to locate the bootloader.

Steps to the loop:

1. I build the code make px4fmu-v5_default
2. The console builds it succesfuly
3. I try to upload it make px4fmu-v5_default upload
4. It sarts to upload and gets stuck in a loop :
   "Attempting reboot on (port name) with baudrate=57600..."
   "If the board does not respond, check the connection to the Flight Controller"
5. It runs all over connected comports, including that of the pixhawk4

What I expect to get is that it will reach the port of the pixhawk and upload the code.

I tried cahnging a cable.
I tried pressing in the usb connectiong
I tried switching a port

• As said running on pixhawk 4
• Windows7
  -cygwin toolchain

Did anyone else had this problem? Knows how to fix it?
The uploading script is under Firmware/Tools/px_uploader.py
Tahkns in advance

[guy-at-ttt]

Any update to this issue.?
I have the same issue on auav-x21_default.
Using an mRo X2.1 v2. Running on (Windows 10) cygwin toolchain.
I tried the "PX4 Bootloader Issue" fix, without any success.

[raptorrex6]

For now I am using an older version of the px_uploader.py script and it works fine.
I use this

https://github.com/PX4/Firmware/blob/11d4c32cd42ab47394e039d9acc05960da6c1332/Tools/px_uploader.py

piece of code specificaly, just copied it into Firmware/Tools/px_uploader.py.
I assume there should be a real fix with the updated version.

[MaEtUgR]

I can confirm, the uploader seems broken on master 😞

For now I am using an older version of the px_uploader.py script and it works fine.

That's a good workaround but it needs to be fixed. If someone finds the problem I appreciate any help. I'll look into it as soon as possible...

[MaEtUgR]

JFYI There was already a maybe hard to find issue by me because I had the same problem: #10375
The windows toolchain project is here: https://github.com/orgs/PX4/projects/6

[MaEtUgR]

So 57c7e1a attempted to prevent the use of some windowed upload mode intended for FTDI UART connections when uploading over USB. On Cygwin it caused exactly the opposite and window mode afterwards gets used over USB which results in 4+ times the upload time (Pixhawk 4 with current master 39s -> 167s). The problem is detection of USB because it simply assumes that if the port name contains "/dev/ttyS" it's UART (57c7e1a#diff-25f54baafa76ba3cdb603067311ad2c0R222) but on Cygwin every Windows COM port gets mapped to /dev/ttyS[COM number - 1].

f12acd7 (which I identified earlier as the commit that breaks correct bootloader recognition) tries to fix the windowed mode problem by trying different baudrates (f12acd7#diff-25f54baafa76ba3cdb603067311ad2c0R334) and from that information detect UART vs USB.

Now I know the context but still have to debug to find the root cause why it currently fails.

TLDR To make it work again (with fast speed) you just need to comment out this line: https://github.com/PX4/Firmware/blob/master/Tools/px_uploader.py#L553
I'm looking for a mergable solution.

[MaEtUgR]

https://github.com/PX4/Firmware/blob/master/Tools/px_uploader.py#L339 sets some odd baudrate and I don't know why but on Cygwin that line does something strange:

• Execution stops at the line, the next one is not executed anymore
• try: except: does not catch it
• Execution still continues, there's no error on the terminal
  I did not yet find out where exactly it jumps but the outer loop testing different ports continues (endlessly).

@davids5 Any ideas that might help? 😇

[davids5]

@MaEtUgR - Wow! Could you try 110 baud as the test rate, and then retest on linux as well?

[MaEtUgR]

@davids5 Thanks for your response! If I hardcode self.port.baudrate = 110 it all runs through like expected (no windowed mode on USB) but I don't have a way to test if flashing over UART is detected correctly. I assume that's what you meant with "retest on linux". I can test on linux tomorrow but how do I evaluate UART being detected correctly?

---

try: except: does not catch it

I have to take that back, I couldn't believe it myself and of course just found an error in my except block that lead to the strange runtime behaviour. The actual exception of the line is non-standard baudrates are not supported on this platform.

Is the "magic trick" that on USB you could theoretically set an arbitrary baudrate and the UART drivers will only allow the standard rates supported by the clock deviders? So we're looking for a baudrate that is arbitrary enough such that UART modules do not have a clock devider for it but not too arbitrary such that python on Cygwin still allows it? Like maybe 110? I tried 50, 75, 134, 150 and they give exception (22, 'Invalid argument'). 110, 300, 600, ... all work.

[davids5]

@MaEtUgR -

Is the "magic trick" that on USB you could theoretically set an arbitrary baudrate and the UART drivers will only allow the standard rates supported by the clock deviders?

Yes to some degree. The magic is that on a USB the CDC ACM driver the buadrate does not have any effect. This is because the data is never converted to NRZ data again. It would be on a USB to serial cable, but not on a CDCACM device. The change baudrate command just tells the target there is the new rate. But none of that affects the speed. On real serial port the target is typically set to 115000 bps. (or some high rate like 1-2 mbps) If we send a SYNC and EOT at 2.33 times the assumed baud rate the SYNC and EOT can not be received and there will be no response. But on USB it works.

So we're looking for a baudrate that is arbitrary enough such that UART modules do not have a clock devider for it but not too arbitrary such that python on Cygwin still allows it? Like maybe 110? I tried 50, 75, 134, 150 and they give exception (22, 'Invalid argument'). 110, 300, 600, ... all work.

It is not the clock divider per say, it is the bps setting that is in effect on the target. In this case the target is at 115200 and, the host is at 110 bps (90 Ms per bit) or 300 bps (33 ms per bit). On a real serial port the 90Ms start bit will look like a break to a target at 115200 bps (8.68 uS perbit) so the SYNC EOT can not be received and there will be no response.

I chose to go 2.33 times to avoid having issues with the "Enter bootloader mode Via break" feature here:

https://github.com/PX4/Bootloader/blob/master/main_f4.c#L275-L334

Because there is a possibility of the break detection being active in a bootloader, a higher rate like 57,600
or 38,400 might be the best choice. It is 17.36-26 uS per bit and not an odd unsupported rate. At 1152,000 the start bit will look like 2 - 3 bits.

We will still have a potential problem with target using 1-2 Mbps. 57,600's start bit will still look like a break. Could restrict that feature to only be enabled on targets with baud rates < 1 Mbps?

[davids5]

how do I evaluate UART being detected correctly?

You build the V5 bootloader with 1 mbps and connect a FTDI cable to the telem 1. Then windowed mode should be used, switch to USB and non windowed mode should be used.

[MaEtUgR]

@davids5 Sorry I don't have the hardware to test and make sure the FTDI check still works with 110 or other lower baudrate. I came up with a woraround just catching the exception which fixes the most common and therefore urgent Windows use case. If you're still willing to change the change the odd baudrate check to a normal but too low baudrate and I should test something on Windows please let me know.

[davids5]

@MaEtUgR if the problem is solved and it is working, for all user by correctly choosing the correct window mode, that is really all we need.

[Tanop74]

I am not a computer specialist and just trying to upload with (Windows 10) cygwin to Pixhawk 3 Pro.
The current version on the server does not work for me (3 messages about baudrates (see below)+ endless loop).
I would be happy if someone could help me.
Thanks

[MaEtUgR]

@Tanop74 It looks almost ok. Don't worry about the "non-standard ... USB connection" warning, I should rewrite it to make clear it's just a warning.

Could you try:

• starting the upload and as soon as you'r in Loaded firmware ... plugging your pixhawk board without having your vehicle powered by any battery.
• opening your device manager in Windows and disabling all other COM ports that are not your pixhawk board to make sure it doesn't connect to these.

Also look at the device manager while you plug your pixhawk board, it should pop up as COMX and if you don't flash anything as COMY with Y one number higher than X shortly after. When you are flashing you need to start the uploader and plug it such that the bootloader (COMX, the first just after plugging) gets recognized.

I hope this helps, maybe sometime I'll do a video for most comprehensive docs...

[MaEtUgR]

@davids5 Sure, I don't know how many users would use the FTDI cable to flash normally from the desktop under Windows. That's probably what's not supported right now.

[Tanop74]

Hello Matthias, I have finally chosen to reinstall everything in Ubuntu and it now works well. Thanks for your feedback Arnaud