search

platformio / platform-atmelsam

Atmel SAM: development platform for PlatformIO
https://registry.platformio.org/platforms/platformio/atmelsam
Apache License 2.0
79 stars 106 forks source link

PIO ignores upload_port = setting #58

Open alexwhittemore opened 5 years ago

alexwhittemore commented 5 years ago

What kind of issue is this?

Configuration

Operating system: macOS 10.14.4

PlatformIO Version (platformio --version):3.6.6

Description of problem

The Upload command apparently ignores upload_port = XXXX in platformio.ini, though output suggests it's being respected. In my case, I'm trying to build hardware UART bootloader support for a SAMD21 using the UF2 bootloader. Upload via an FT232 fails with native USB unplugged, but succeeds with USB plugged in, despite setting upload_port = <FTDI device>. I'm certain PIO is using the native USB UART because unplugging the FTDI physically results in a successful upload, even though debug output is correct.

Steps to Reproduce

  1. Get a Trinket M0 and install a UF2 bootloader modified such that both hardware UART and native USB Serial are enabled. ALTERNATELY Presumably it would work to reproduce the issue that you simply have an FT232 adapter plugged in, with some way to monitor the TX/RX lines, while also having plugged in a stock USB serial arduino such as any Adafruit SAMD board. Serial upload won't work over the FT232, of course, but you'll be able to see which device PIO uses.
  2. Put together a quick arduino sketch in PIO, configured for your board. Verify it uploads normally with only the native USB port in play.
  3. Configure platformio.ini to use a hard-coded serial port. For instance, on my machine, /dev/cu.usbmodem143201 is the trinket M0 USB serial, and /dev/cu.usbserial-A4016VJ0 is my FT232 adapter. So I set upload_port = /dev/cu.usbserial-A4016VJ0
  4. Upload code to the device.

Actual Results

Software will upload. Please see in-line note below.

Processing my-env (framework: arduino; platform: atmelsam; board: my-board)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelsam/my-board.html
PLATFORM: Atmel SAM > Adafruit Trinket M0
HARDWARE: SAMD21E18A 48MHz 32KB RAM (256KB Flash)
DEBUG: CURRENT(jlink) EXTERNAL(atmel-ice, blackmagic, jlink)
Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF MODES: FINDER(chain) COMPATIBILITY(soft)
Collected 13 compatible libraries
Scanning dependencies...
No dependencies
Checking size .pioenvs/my-env/firmware.elf
Memory Usage -> http://bit.ly/pio-memory-usage
DATA:    [=         ]   6.8% (used 2216 bytes from 32768 bytes)
PROGRAM: [          ]   3.8% (used 10088 bytes from 262144 bytes)
Configuring upload protocol...
AVAILABLE: atmel-ice, blackmagic, jlink, sam-ba
CURRENT: upload_protocol = sam-ba
Looking for upload port...
Use manually specified: /dev/cu.usbserial-A4016VJ0
Forcing reset using 1200bps open/close on port /dev/cu.usbserial-A4016VJ0

NOTE: At this point, I have to manually reset my board by double-tapping a reset button. My board doesn't have a high-pass between FT232 DTR and RST, so this is necessary for UART upload. I'm not sure why it's necessary for native USB UART upload, but it appears to be, still.

Waiting for the new upload port...
Uploading .pioenvs/my-env/firmware.bin
Erase flash

Done in 0.819 seconds
Write 10088 bytes to flash (158 pages)
[==============================] 100% (158/158 pages)
Done in 0.068 seconds
Verify 10088 bytes of flash
[==============================] 100% (158/158 pages)
Verify successful
Done in 0.668 seconds
========================================================================= [SUCCESS] Took 7.68 seconds =========================================================================

Terminal will be reused by tasks, press any key to close it.

Expected Results

Failure, because the specified port is an FT232 connected to nothing (or a logic analyzer or such). Note in the log above that my disconnected FT232 is apparently being used, yet upload succeeds when it shouldn't be possible, if that's actually the case.

If problems with PlatformIO Build System:

The content of platformio.ini:

[env:my-env]
platform = atmelsam
board = my-board
framework = arduino

debug_init_break = tbreak setup

;debug_tool = atmel-ice
;upload_protocol = atmel-ice

debug_tool = jlink
;upload_protocol = jlink
upload_protocol = sam-ba
upload_port = /dev/cu.usbserial-A4016VJ0

Source file to reproduce issue:

Any example you like, e.g. Blinky.

Additional info

ivankravets commented 5 years ago

Could you try to add the next lines to platformio.ini?

[env:my-env]
...
board_upload.wait_for_upload_port =
board_upload.use_1200bps_touch =

The empty values are OK which means FALSE. However, I've just fixed it in https://github.com/platformio/platform-atmelsam/commit/d5d6411492fdc58b3a83c683e8b2a31055c986b4 and you will be able to use board_upload.wait_for_upload_port = false or board_upload.wait_for_upload_port = 0 later.

alexwhittemore commented 5 years ago 
board_upload.wait_for_upload_port =

This seems to be the key to force the port in question. BUT it still doesn't seem to be quite right. If I understand it correctly, the port should open, pulling DTR low and resetting the device (which, mine won't). Then the port gets opened at 115200 and the host sends a '#' to the bootloader to indicate FW upload?

I'm monitoring my FTDI UART lines with a logic analyzer to make sure I see what activity is going on at what speed. With the following platformio.ini, I get the following behavior:

upload_protocol = sam-ba
upload_port = /dev/cu.usbserial-A4016VJ0
board_upload.wait_for_upload_port =
; Commented this out but it doesn't seem to have bearing either way - I just wanted a clue as to where to manually reset, although there's no longer enough time for me to get it accurately by hand anyway.
;board_upload.use_1200bps_touch = 
CURRENT: upload_protocol = sam-ba
Looking for upload port...
Use manually specified: /dev/cu.usbserial-A4016VJ0
Forcing reset using 1200bps open/close on port /dev/cu.usbserial-A4016VJ0
Uploading .pioenvs/my-env/firmware.bin
No device found on cu.usbserial-A4016VJ0
*** [upload] Error 1

Looking at the logic analyzer, the host never sends anything, at any speed, via the FTDI. - it just instantly fails ("uploading..." to "[upload] error" is basically instant).

For fun, I just removed ALL upload configuration besides the 'sam-ba' directive. That still fails without ever sending '#', but with a substantial delay at

Forcing reset using 1200bps open/close on port /dev/cu.usbserial-A4016VJ0
Waiting for the new upload port...
alexwhittemore commented 5 years ago

Oh - this was part of my problem: the serial device happened to be open with a serial monitor I wasn't aware of, and PlatformIO apparently silently fails on "unable to open port" - it just shows No device found on cu.usbserial-A4016VJ0 same as if the port works fine, but there's no bootloader behind it.

Now that I've got that sorted out, I'm still getting apparently garbage out. From PlatformIO, the FT232 sends:

0x8E (framing error)
0x63 (framing error)
0xD6 (framing error)
0x43 (framing error)
0x00 (framing error)
...

(I believe the first byte should be # - 0x32, no?)

Trying the same thing with Arduino, 

0x8E (framing error)
0x63 (framing error)
0xF7 (framing error)
0x30 (framing error)
0x70 (framing error)
0x70 (framing error)
0x30 (framing error)
0x70 (framing error)
0x30 (framing error)
0x70 (framing error)
0x70 (framing error)
0x2C (framing error)
0x74 (framing error)
0x23 (framing error)
0x00 (framing error)
...

Not quite sure what to make of those.

alexwhittemore commented 5 years ago

The post above doesn't seem to be relevant. Now that I've sorted out all the other variables in my system, it seems that BOSSA et all just send some stuff before the # that I don't understand, but that seems to be standard operating procedure. The long and short of it is that with 

upload_port = /dev/myport
board_upload.wait_for_upload_port =

PIO works as expected. so then the only question is, why is the second part necessary? Is this expected behavior or is there actually a bug here? If there is, I can try to go looking for it.

ivankravets commented 5 years ago

Have you resolved this issue?

alexwhittemore commented 5 years ago

I’m not having any trouble now that I know about the workaround (wait for upload port), but I’m still not clear on what the workaround does, why it’s necessary, or whether it indicates a bug. Seems like deviant behavior to arbitrarily settle on a different port when one is already explicitly defined.

LabtronicsDesign commented 4 years ago

Having the same issue. I have 3 teensys connected to my PC and this is the platformio.ini code I have in each project folder:

[env:teensy31]
platform = teensy
board = teensy31
framework = arduino
upload_port = COM17
board_upload.wait_for_upload_port =

...obviously changing the port for each folder COM15,16 & 17

Thing is, only COM17 can get written to when I click upload(on its own code). The other projects dont upload to their respective port but hold up the teensy on COM17 (teensy on COM17 just gets stuck and freezes). Seems the bug hasn't been fixed yet.

Output message:

> Executing task in folder projectx: C:\Users\xxxxx\.platformio\penv\Scripts\platformio.exe run --target upload <

Processing teensy31 (platform: teensy; board: teensy31; framework: arduino)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/teensy/teensy31.html
PLATFORM: Teensy 4.6.0 > Teensy 3.1 / 3.2
HARDWARE: MK20DX256 72MHz, 64KB RAM, 256KB Flash
DEBUG: Current (jlink) External (jlink)
PACKAGES: toolchain-gccarmnoneeabi 1.50401.190816 (5.4.1), framework-arduinoteensy 1.148.0 (1.48), tool-teensy 1.148.0 (1.48)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 92 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <Adafruit DotStar> 1.1.3
|   |-- <SPI> 1.0
|-- <Adafruit DotStarMatrix> 1.0.4
|   |-- <Adafruit DotStar> 1.1.3
|   |   |-- <SPI> 1.0
|   |-- <Adafruit GFX Library> 1.5.6
|   |   |-- <SPI> 1.0
|-- <Adafruit GFX Library> 1.5.6
|   |-- <SPI> 1.0
|-- <SPI> 1.0
Building in release mode
Linking .pio\build\teensy31\firmware.elf
Building .pio\build\teensy31\firmware.hex
Checking size .pio\build\teensy31\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
DATA:    [=         ]   8.0% (used 5232 bytes from 65536 bytes)
PROGRAM: [=         ]   9.6% (used 25148 bytes from 262144 bytes)
Configuring upload protocol...
AVAILABLE: jlink, teensy-cli, teensy-gui
CURRENT: upload_protocol = teensy-gui
Uploading .pio\build\teensy31\firmware.hex
Found 3 Teensy boards, but using auto-search to find board for upload.
Please use Tools > Ports(Teensy) to select the specific board.
========================================== [SUCCESS] Took 3.67 seconds ==============================================

Terminal will be reused by tasks, press any key to close it.