PlatformIO download stops working after 1st download from platformIO #803
Comments
|
The USB is driven by software on the Pico, so if your sketch crashes or uses TinyUSB and doesn't manually create a serial object then automatic upload can't work. Does the simple blink sketch work for you? And are you running a RPI Pico or another board? Other boards with different flash chips need different boards to be selected or the bootloader will not work. |
|
Thanks for the quick reply. The test sketch is just this:- platformio.ini is as shown above. The device is a genuine raspberry pi pico board from element14 - although it is a quite early version. I've also tried the brand new pico-w which has the same behavior. I've reverted to something this simple just to check that it wasn't something I was doing. The blink sketch works i.e. the lamp blinks at 1.25Hz. I added the Serial output (commented out in the code above) which also works via the USB serial monitor. The serial device is reported as present in windows right up until the next upload attempt. It vanishes when the reset is performed. In the mean time I've been using the framework on the Ardunio 2.0 IDE (nightly build). It works fine and will upload multiple times although I don't think it uses the same mechanism. When I use a pico that has been uploaded using the Arduino IDE it too dies when pico tool does its reset. The reset operation seems to be the thing that crashes in the firmware on the new framework. This isn't desperately urgent for me because I can use the fancy framework with the Arduino IDE but since you've put so much amazing effort into getting the platformIO stuff working I thought I'd let you know that there could be an issue. Plus platformIO is still a nice environment than the RC Arduino 2.0 IDE. I'm very happy to help out in any way I can with more tests if there is anything you need to me try. |
|
I'm not a P.IO user so can't help much more, but the serial port is supposed to disappear when uploading. Basically the uploader (either my Arduino UF2 based one or the Picotool based one in P.IO) sends a special serial port sequence (1200bps connection) which causes the Pico to reboot into a ROM bootloader. That bootloader has a UF2 emulated memory stick interface, and a special |
Can you uncomment in the If you can't upload the sketch, put the Pico in bootloader mode and copy the |
|
Hi Max, thanks for your interest in my problem. I've already tried with and without the Serial.begin and when with, also with and without and the Serial.println. In all three cases, the sketch worked but upload still failed. Rebooting the device in bootloader mode and copying the firmware manually always works. I've been messing around with the Arduino IDE and platformIO and it would appear that there is something with the picotool download that is struggling with firmware generated by the new Arduino-pico framework.
Other than the ability to upload new firmware using platformIO everything about the new framework seems to work perfectly. Both stable and new platform IO versions use the same version of rp2040load (1.0.1) which seems to just run picotool a number of times and picotool doesn't seem to work with the new firmware - (on my system at least). I noticed that with the new firmware that the com port number of the device increased by 1. You can see in the upload output above that it changed from COM28 to COM29. Presumably this is indicative of the new bootloader firmware. I can see the following differences between the two versions of the port in device manager
The only change is the firmware downloaded. COM 28 is the stable framework generated firmware, COM 29 is the new. I'm not sure what the 'required further installation' thing is about since it says it is working properly. I assume that this is just a problem I am seeing and that no one else has encountered it? Is it worth trying a more recent version of the updated rp2040load and/or picotool? Is it possible to change the upload protocol since there seem to be other options? Do any of them work over a standard USB connection? |
|
No changes to the serial port code have happened in quite some time, and the UF2 generation hasn't been touched either. The COM port can often change between runs with uploads between them at the whim of the OS, so you do always need to make sure you're using the right one to do the 1200bps tickle to reboot it. Under Linux, if I have a |
|
Since the Arduino IDE download mechanism works perfectly I can only assume it is something going wrong with reset, rp2040load or picotool. rp2040load has been updated on the git site and from the help options reported it looks like the picotool is 1.0.1 which also has an update 1.1.0 version available which has a lot of changes. I'll see if the newer versions of rp2040load and picotool can fix my problem but I'm not a windows developer and always struggle to get stuff to compile. I'm not even going to attempt to compile the golang stuff on principle :) I'll let you know if I make any progress. |
|
Since a couple of days I see the same behaviour. I am not 100% sure, but it seems that after updating the framework (first time since a couple of weeks) the upload process aborts as described above. I can see that the COM port is opened with 1200 baud to enter the bootloader, and I can also see that the COM port disappears in Windows, but the new COM port for the bootloader does not show up. But the Pico is in bootloader mode as the Pico drive shows up and the UF2 file can be copied successfull. I will check this also on my PC (now working on my laptop) if it behaves the same. /edit: It seems that I updated the framework on my PC beginning of August, and it shows the same behaviour. BUT I tried it with a second Pico and multiple uploads are working.... |
|
Can you try the alternative upload bootloader reset + copy UF2 to bootdrive method by setting upload_protocol = mbedin your |
|
@maxgerhardt This way it is working. In the meantime I have updated the framework on my PC, and now the second Pico can also not be updated with picotool anymore. For me there must have been something changed between the actual release and some (less?) weeks ago. Not sure but with the release from end of July or beginning August it was working. |
|
Using mbed as an upload protocol did the trick and mean's I can use it going forward which is awesome! Thanks Max! In the meantime I'm now convinced it is the picotool that is broken with the new firmware that we're flashing. When I run it on a device built with the stable framework I get this... It looks like it's happy. If I try it with the same device with the newly build firmware using the new framework I get: I notice that picotool is in packages/rp2040tools so is common to both old and new frameworks. There is no command line option to get a version for it but looking at github 1.0.1 has an assert on line 809 and version 1.1.0. It appears that there have been significant changes to the tool. Maybe we need to get an updated version of it which might fix the problem. In the meantime I have a working platformIO and I'm as happy as a happy thing. |
|
The picotool version used (1.0.2) is currently outdated (newest 1.1.0). Since https://github.com/raspberrypi/picotool/releases doesn't provide binary releases for all the OSes, I'll have to come up with a way to use the Gitlab CI to compile and package everything. Maybe updating this will fix these issues with newer firmware versions, I'm on it. |
|
I have a suspicion about this. There is a structure in flash that's supposed to list the resources used by the binary (I'm not really sure why you'd ever want to do this, but I'm sure it made sense to someone). I have a feeling that the OTA binary, which is now part of all applications, is confusing picotool and it's just completely pooping its pants instead of just uploading the bytes in the .BIN. OTA effectively needs to have not one but two separate applications in flash. The ROM jumps to the OTA app which checks for updates and then jumps to the user app. Might have 2 copies of this magic "I'm using XXX" struct. Let me dig into this, now that I have a clue... |
Because OTA has changed the flash map from standard, picotool ends up crashing or hanging while trying to operate on the current built files. Remove the binary_info calls and structures completely to avoid any issue. Fixes #803
|
@fatherseye can you try pr #831? W/o the change I see |
earlephilhower
added
bug
Because OTA has changed the flash map from standard, picotool ends up crashing or hanging while trying to operate on the current built files. Remove the binary_info calls and structures completely to avoid any issue. Fixes #803
Hi,
Great work on the framework. I have been using the 'stable' platform IO environment with a Rpi pico for a while and it works great. However, all the work you have done on the pico-w and additional feature support is just too cool not to use.
When I try a project with platformio.ini set to:
It clones the framework, compiles it all, generates the firmware and uploads it and it runs fine. However, when I try to upload again the pico responds to reset from picotool and isn't seen again. To recover the device you need to power up in bootsel mode and copy a different firmware made using an alternative environment to the pico which then starts to behave properly again until you try another download. I've tried it with a standard pico and pico-w and they both behave the same.
Am I doing something stupid?
The output below is from a flash sketch setup and build fresh. You can see the 1st download work. The sketch runs but on the second download the pico vanishes from the USB devices in device manager after the forced reset operation.
The text was updated successfully, but these errors were encountered: