Tiny 2040 reset before upload.

[hreintke]

Jantje,
I have a new board Tiny2040 and using the https://github.com/earlephilhower/arduino-pico Arduino Core for that.

During upload I see a reset for the device, both by Sloeber and also by the upload program uf2conv.py

The reset makes the device go into bootmode, which is the device showing up as a removable device in windows.
The actual upload is "just a copy" to the device.

What happens now is :

• Sloeber resets
• Sloeber starts uf2conv including --serial (which is correct as it is defined in platform.txt)
• uf2conv tries to reset -> fails a the device is already in "removable device mode"
• uf2conv ignores the error
• uf2conv searches for "removable devices", finds it and uploads the file.
• The sketch is available at the tiny2040.

I am trying to get a complete understanding as this will fail as soon as there is a proper error checking in uf2conf.py.

Starting upload
Uploading project "RP2040" with "uf2conv"
Starting reset using DTR toggle process
Continuing to use "COM8"
Ending reset


Launching: C:\Userdata\RP2040\arduino-pico/system/python3/python3 C:\Userdata\RP2040\arduino-pico/tools/uf2conv.py --serial COM8 --family RP2040 --deploy C:\Userdata\ESP8266\Projects\RP2040\Release/RP2040.uf2 
Output:
Resetting COM8
serial exception
Converting to uf2, output size: 126976, start address: 0x2000
Flashing D: (RPI-RP2)
Wrote 126976 bytes to D:/NEW.UF2
The execution of command "arduino-pico/system/python3/python3" is done.

The "serial exception line" comes from my patch to uf2conv.py for debugging.

Long story, but my basic question is :
When/How is the "Starting reset using DTR toggle process" initiated by sloeber and can the behavior of that be configured.
Cannot find that in the platform.txt or programmers.txt

Just to make this clear too : I am not saying that this is a sloeber issue.

[jantje]

I do think you found a bug in Sloeber
Looking at the code I see that sloeber defaults upload.force_reset_before_upload to true. That may have been good in the old day but nowadays that should be false
As a workaround you can set upload.force_reset_before_upload to false in your boards.txt file

[hreintke]

First : With the workaround, the upload process works OK.

However some further remarks from my investigation.

• Could not find a complete specification of all boards.txt options.
• Only this one https://arduino.github.io/arduino-cli/latest/platform-specification/#boardstxt
• In none of the boards.txt files on my system the upload.force_reset_before_upload was set.
• I have, esp8266, esp32, stm32, stm32new format, atttiny, tiny2040, arduino.
• So a change in default value may have a lot of impact.

I leave this issue open, for you to close

Edit : Checked with installing this board in Arduino IDE -> works OK without the workaround.

[jantje]

Could not find a complete specification of all boards.txt options.

It is Arduino who specifies the arduino framework and indeed the specification is not perfect.
Also contributors can add keys.

In none of the boards.txt files on my system the upload.force_reset_before_upload was set.

After some investigation I found this is something I added to fix problems
#444
These problems are fixed now so I should remove it.

I have, esp8266, esp32, stm32, stm32new format, atttiny, tiny2040, arduino.
So a change in default value may have a lot of impact.

Indeed: looking at https://arduino.github.io/arduino-cli/latest/platform-specification/#1200-bps-bootloader-reset I see your board states redundantly
xxx.upload.wait_for_upload_port=true
I would assume if you specify wait_for_upload_port=true you also want a reset but Arduino does not do so. These are differences in style.

So in conclusion I will remove the force_reset_before_upload and only reset when use_1200bps_touch is true

To show my confidence on this issue I'll qoute from the arduino framework description
Note that the IDE implementation of this 1200 bps touch has some peculiarities, and the newer arduino-cli implementation also seems different (does not wait for the port after the reset, which is probably only needed in the IDE to prevent opening the wrong port on the serial monitor, and does not have a shorter timeout when the port never disappears).

[jantje]

I think this is now fixed in the nightly