If we dont explicitly check for pyserial, we can have the case where the
import works but the Serial object creation fails. However, we don't see
this because we have this huge try/catch block which swallows
everything.
to fix Cygwin upload. It failed silently but when catching it prints
"non-standard baudrates are not supported on this platform".
Discussion about platform independet FTDI detection is in issue #10429.
Using the port name is platform dependent. It may give not
provide the correct feedback. The port can be ttyS, or ftdi
or CDC/ACM. While it is true that buadrate does not matter on
CDC/ACM. It is better to give more information about what the
code is doing before filtering by the port name.
The correct determination of Windowed mode is critical to
maximise the speed on a USB based upload.
This commit bases the detection of a Serial (FTDI) on the
fact a CDC ACM port (USB) does not really have a baud rate.
We bump the baud rate to 233% of the requested baud rate to
see if the SYNC is acked. If it is Acked it must be a USB
port and Windowed mode is turned off. This removes unnessary
baud rate based delays from the proframing logic. If it is a
real Serial port getSync will not get the ACK and Windowed
mode is turned on.
The __getSync was costing about 16Ms per call.
The commit uses a window based approch allowing
the SYNC,<results> to be read all at one time.
and delaying for programing based on transport
time + 1 Ms;
THe improvment at 2Mbps is >4 minutes to ~37
seconds
This fixes a problem where the pyserial write call gets stuck.
It happens on a specific Fedora 28 system with internal USB ports as
well as USB hubs.
It is not clear why the problem is resolved but it is clearly
reproducible that with a timeout of 0, the write can get stuck and with
a timeout > 0 it works every time.
The exception added as part of this commit makes sense but has never
been triggered in my testing.
If the PX4FMUv2 board does not have the v5 uploader, it's not possible
to check the silicon revision to make sure it's safe to upload the
firmware which is more than 1 MB. However, if the user is sure the
silicon revision is not affected by this errata, he can upload the
firmware using px4_uploader.py with --force argument. This commit adds
`force-upload` make target to do it more convenient way.
Signed-off-by: Andrei Korigodski <akorigod@gmail.com>
In the Cygwin environment the native Windows serial COM# ports get mapped
to /dev/ttyS# for POSIX compatibility. While # is one number lower inside
the environment than the COM port number because it's 0 indexed instead
of 1.
I added the necessary handling to all the dependent parts I found which
allows uploading to /dev/ttyS# when the cygwin platform is detected.
Now the usual "make px4fmu-v4 upload" and
"./Tools/upload.sh build/px4fmu-v4_default/px4fmu-v4_default.px4" work.
- Move check to proper location, out of the try catch block for OTP.
- Add Pixhawk specific check to notify users that want to flash
px4fmu-v3_default on Pixhawks with older v4 bootloaders that do not
support the silicon errata check.
This fixes the error below when using Python3:
File "Tools/px_uploader.py", line 128, in
__init__
self.image.append('\xff')
TypeError: an integer is required
The goal is to force developers to use the correct target with the correct flash size. This prevents criticial functionality missing and is in particular important for FMUv2/FMUv3 boards. It is unmaintainable otherwise for the Pixhawk series.
In order to use px_uploader as a module from another Python script, all
the action needs to be moved into a main() function which is only called
if the file is run directly.
Sometimes right after reboot, we got a `raise SerialException(
msg.errno, "could not open port {}: {}".format(self._port, msg))`.
If this happens now, we will just try again later.
We may need to change the baud rate from one version to the other.
Allowing the script to try multiple baud rates makes the transition a
little bit less painful.
This also fixes a bug in which it would go the next port before trying
to identify the board after asking it to reboot.
By default the baudrate in flight stack (Mavlink or NSH) 57600 and the default
baudrate of bootloader is 115200. So we may need to set different
baudrates.
The Mavlink reboot messages was only requesting the board to reboot.
If the flashed bootloader has a small or no timeout user will
never be able to update firmware.
Julian Oes
Daniel Agar
Pietro De Nicolao
Matthias Grob
David Sidrane
Lorenz Meier
Hamish Willee
korigod
Beat Küng
ritul jasuja
Julien Lecoeur
Lucas De Marchi
José Roberto de Souza
Lorenz Meier
Andrew Tridgell