platformio-vscode-ide
platformio-vscode-ide copied to clipboard
platformio
Upload & Monitor Task selects wrong environment
Steps to reproduce:
- Open arduino-blink example from esp8266 platform
- Run "Upload & Monitor" Task in Project Tasks for board "A"
- Run "Upload & Monitor" Task in Project Tasks for board "B" (BUG!! task for board "A" will be restarted)
Hi @TD-er ! The MMU configuration is handled by this code. PIO_FRAMEWORK_ARDUINO_MMU_CACHE16_IRAM48_SECHEAP_SHARED macro adds the following defines to the compile command:
-D MMU_IRAM_SIZE=0xC000
-D MMU_ICACHE_SIZE=0x4000
-D MMU_IRAM_HEAP
It's a pretty straightforward configuration, so TBH I'm not sure why it might be unreliable. Are there any changes between two consecutive compilations?
I got the idea the building process on its self might be flaky.
It doesn't matter if I use the PIO define or the ones you mention (with the -DPIO_FRAMEWORK_ARDUINO_MMU_CUSTOM or else you get lots of complaints about redefines)
Just some observations:
- Make a build -> OK, 2nd heap is present
- Do some tests, decide things don't work out, thus revert to previous state of code
- Make a build -> sometimes OK, sometimes 2nd heap is not present.
N.B. I don't build other PIO envs inbetween and don't touch the PIO ini files.
What does happen every now and then -now that I think of it- is that my PIO project tasks tree gets folded with an infinite waiting state (like what you have when unfolding it for the first time, showing "Loading...") unless you close the item and open it again.
I mean like pressing here:
This does seem to happen more often when you toggle between tasks like "build", "clean" and "Upload and Monitor". Could this also affect the build process?
Could this also affect the build process?
Highly unlikely. That task tree simply runs the pio project data command on your project to retrieve the build information. So if you manually run pio project data --json-output command in the IDE terminal you will see all the build flags and targets available (including PIO_FRAMEWORK_ARDUINO_MMU_CACHE16_IRAM48_SECHEAP_SHARED).
In any case, your freshly edited files will trigger linker to reassemble the final elf image and there might something wrong with autogenerated linker scripts.
Anyway, could you please prepare a minimal example so I can reproduce it on my machine?
Well a "minimal" example is quite hard as I don't have a clue here what triggers it. N.B. working on the code for this PR: https://github.com/letscontrolit/ESPEasy/pull/3680
By the way, the IDE just suddenly "folded" the project tasks as I described, which happens every now and then.
So as you said, not likely to be causing this problem, but more to indicate what happens as I mentioned it.
Edit2: Just pushed the latest changes to this PR. I now changed the 'beta' builds (Arduino staging code) to using the 2.2.2 SDK as 3.0.0 SDK does cause lots of WDT reboots not leaving any clue where the ESP may hang. It does not seem to be related to changing heap/cache ratios as it also causes WDT crashes when using the default ratios.
I do have the feeling (I know, lots of 'feeling', not yet hard facts) that it may somehow be related to this issue: https://github.com/esp8266/Arduino/issues/8169
The reason I got the feeling it may be related is that I'm having a number of issues when running the current staging code of esp8266/Arduino, regardless if it is using SDK3 or SDK222 and also with or without experimenting with the 2nd heap.
What I'm seeing (so leave out the idea of the MMU defines) is that the ESP may crash on seemingly unrelated code. Code that was not changed in a long time. It does look like code called with flash strings does appear more often on the decoded stack trace, but not always. Also the WDT resets do occur quite often.
So this does seem like there is something fishy in the way how code is being linked. The order in which it is linked may lead to working or crashing build. For example I now had it crash with the stack trace in the linked issue. Did a complete clean of the .pio directory, the packages, cache and some other folder in the .platformio directory and did a clean rebuild. Now it is running fine. With the crashing build it was a rebuild with only a minor change in 1 file and the build before was based on a clean build just like the one running on my node.
I hope this is enough defense to give my 'gut feeling' some credits ;)
Edit: N.B. I was just thinking... if it is indeed related to how things are being linked, then I am not sure it is even possible to make a 'minimal' example to reproduce it.
I have another idea of what may be happening here...
In VS code, you have on the right the various PIO tasks once done so you can switch between them.
What I now noticed was that I was building a build before that did not have the 2nd heap stuff defined for the PIO env. So I cleared all build files etc. and selected from another PIO env. to "upload and monitor". (an env which should have it defined) It starts building, uploading and again no 2nd heap in that build. Then I noticed it built the wrong environment even though I am 100% sure I clicked the right one.
Clicked this one:
But since a previous task with "Upload and Monitor" from another env was still present in this list in the lower right corner of VS code, it built that one instead.
So it looks like the re-use of tasks is picking the wrong environment.
Ah proof!
What is pressed:
What is executed:
And what has been flashed:
| Build Time:⋄ | Jun 25 2021 17:26:28 |
|---|---|
| Binary Filename:⋄ | ESP_Easy_mega_20210625_test_B_beta_ESP8266_4M1M |
And it is very well reproducible. At least when I "go up" in the project tasks.
Had "custom_beta_ESP8266_4M1M" via Upload and Monitor and then selected "custom_ESP8266_4M1M" Upload and monitor, but it selected the previous one, as long as the task was still present in the lower right corner of VS code.
After closing those tasks there, the actual clicked task was executed.
So it seems the issue has nothing to do with the PIO_FRAMEWORK_ARDUINO_MMU options as it's rather a PlatformIO for VSCode plugin bug. Does it make sense to move this issue to the https://github.com/platformio/platformio-vscode-ide repository?
I'm hitting a similar issue, though I've managed to get some more details - in my case, the environment passed when running the "Upload" or "Upload and Monitor" task is not updated if a monitor started by "Upload and Monitor" is still running.
Say I have two environments set up in my platformio.ini file, and am happily using the task list in VSCode to build and upload both of them. As soon as I have a monitor running (for instance, by running the "Upload and Monitor" task) for one of them, the environment gets frozen for any future "upload" or "upload and monitor" tasks". Running either task will run it for the environment the monitor was running for.
Stopping the monitor allows things to function correctly.
Further investigation has revealed this is due to the "autoCloseSerialMonitor" feature. When the monitor is resumed, this is done by restoring the task that opened the monitor. If that task was itself an "Upload and Monitor" task, then restoring it will clobber the task you just tried to run - you can actually see this in list of task terminals (if you tried to do an "Upload" it will have failed, and the old Upload and Monitor will have restarted - whether it's the right environment or not).
Worse, here the new "Upload and Monitor" task is completely ignored in favour of restoring the old one - even if args like the environment are different.
Fundamentally, I'm not sure it's ever really okay to be trying to restore an "Upload and Monitor" task - as it'll try and re-upload via that, rather than the "Upload" or "Upload and Monitor" task you've just selected...
For now, the main workaround is to just close any active monitor before uploading if you are using multiple environments. The risk here is that people will get stung expecting to have uploaded one environment, when it's actually re-uploaded the old one.
As far as fixing this, I'm also not really sure what the desired behavior here would actually be. Unless there is a way of breaking out the "monitor" task such that it is always independent of which combination task called it? Then it would be able to be restored without the side effects of re-running the entire task that first needed the monitor (like Upload and Monitor).
For now, the main workaround is to just close any active monitor before uploading if you are using multiple environments. The risk here is that people will get stung expecting to have uploaded one environment, when it's actually re-uploaded the old one.
That I can confirm from experience as it happens to me all the time.
This is happening to me all the time as well. I clicked 3 times in a row on the Upload and Monitor in one task. the first two builds were done on the taks I built before that, and the third on the selected task. Didn't close terminal or monitor between the 3 clicks.
But it happens almost each time I switch from one task to another.
@TD-er, could you reproduce this issue with the latest PlatformIO IDE 3.0?
Ehhh where do I check the IDE version?
If you mention this version, then yes, I can reproduce it as I got bitten by it a few times again the last few days.
Edit: Saw the last version was less than a week ago, not sure if the latest version was active when this happened, so I am testing now to see if I can reproduce it with the IDE 3.0.0
Yep, latest version is installed as far as I can see, it still builds the wrong one if there's still an "Upload and Monitor" session is open.
First built a "collection A" env, then selected one from my "custom" envs and it started building the "collection A" again.
Edit: Will test again... not 100% sure the update was active as there was a "reload required" button....
We run in this issue with Tasmota now too, after the custom menu bar option is used https://github.com/arendst/Tasmota/discussions/17997 (deactivated as quick fix). Imho this issue should be treated as bug
@ivankravets Chiming in with me encountering this as well, to add that it is quite annoying; one of the main points for PlatformIO is running the same stuff on different boards and platforms in the same integrated environment, so I would agree with @Jason2866 that it is a bug.
@Jason2866, @nicklasb , could you try PlatformIO IDE 3.0.1-beta.1 for VSCode build?
- Download the VSIX file above
- Follow to "Extensions" activity bar,
..., Install from VSIX...
Restart VSCode. Use the next snippet for custom toolbar:
"platformio-ide.toolbar": [
{
"text": "$(debug-alt)",
"tooltip": "PlatformIO: Upload & Monitor",
"commands": "platformio-ide.uploadAndMonitor"
}
]
Does it work?
@Jason2866, @nicklasb , could you try PlatformIO IDE 3.0.1-beta.1 for VSCode build?
- Download the VSIX file above
- Follow to "Extensions" activity bar,
..., Install from VSIX...Restart VSCode. Use the next snippet for custom toolbar:
"platformio-ide.toolbar": [ { "text": "$(debug-alt)", "tooltip": "PlatformIO: Upload & Monitor", "commands": "platformio-ide.uploadAndMonitor" } ]Does it work?
Hi, I installed, however I don't know PlatformIO internals, so I don't know where to put the snippet? (just installing didn't help)
Kind regards, Nicklas
@ivankravets "Upload and Monitor" does work now. But the issue with not using the env which is choosen from the bottom menu is still there.
But the issue with not using the env which is choosen from the bottom menu is still there.
Could you provide more details on how to reproduce it? Or, maybe, simple project?
@ivankravets Define a few [env] in platformio.ini. Set one as default. Override this selection by selecting a different one in bottom menu bar (in the screenshot above it is "tasmota32-lvgl") and the default [env] will be used.
This way is working fine when removing the custom toolbar!
Here the Task is run with platformio run --target upload --environment tasmota32-lvgl
The problem is the Task is run just with platformio run when using a custom toolbar
(with Upload & Monitor the Task is run with platformio run --target upload --target monitor --environment tasmota32-lvgl )
Example: used settings.json
{
"platformio-ide.toolbar": [
{
"text": "$(home)",
"tooltip": "PlatformIO: Home",
"commands": [
{
"id": "platformio-ide.runPIOCoreCommand",
"args": "pio home"
}
]
},
{
"text": "$(trash)",
"tooltip": "PlatformIO: Clean All",
"commands": [
{
"id": "workbench.action.tasks.runTask",
"args": "PlatformIO: Clean All"
}
]
},
{
"text": "$(check)",
"tooltip": "PlatformIO: Build",
"commands": [
{
"id": "workbench.action.tasks.runTask",
"args": "PlatformIO: Build"
}
]
},
{
"text": "$(zap)",
"tooltip": "PlatformIO: Build and Upload",
"commands": [
{
"id": "workbench.action.tasks.runTask",
"args": "PlatformIO: Upload"
}
]
},
{
"text": "$(debug-alt)",
"tooltip": "PlatformIO: Upload & Monitor",
"commands": "platformio-ide.uploadAndMonitor"
},
{
"text": "$(flame)",
"tooltip": "PlatformIO: Build, Erase and Upload",
"commands": [
{
"id": "platformio-ide.runPIOCoreCommand",
"args": "pio run -t erase_upload"
}
]
},
{
"text": "$(device-desktop)",
"tooltip": "PlatformIO: Serial Monitor",
"commands": [
{
"id": "workbench.action.tasks.runTask",
"args": "PlatformIO: Monitor"
}
]
},
{
"text": "$(refresh)",
"tooltip": "PlatformIO: Rebuild IntelliSense Index",
"commands": [
{
"id": "workbench.action.tasks.runTask",
"args": "PlatformIO: Rebuild IntelliSense Index"
}
]
}
]
}
with Project Tasmota
Isn't that the same as the original report?
- upload & monitor envA
- Do not close this console
- upload & monitor envB => envA is being built and uploaded
Yay! Like.... I've been bitten by this bug several times a day. Quite frustrating to be confronted with your own stupidness for such a long time, so would be great to see this fixed :)
Please re-test the latest build:
- Download PlatformIO IDE 3.0.1-beta.2.vsix
- Follow to VSCode "Extensions" activity bar,
..., Install from VSIX... - Restart VSCode.
Does it work now?