Upload & Monitor Task selects wrong environment

[TD-er]

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)

[valeros]

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?

[TD-er]

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?

[valeros]

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?

[TD-er]

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: letscontrolit/ESPEasy#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.

[TD-er]

I do have the feeling (I know, lots of 'feeling', not yet hard facts) that it may somehow be related to this issue:
esp8266/Arduino#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.

[TD-er]

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.

[TD-er]

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

[TD-er]

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.

[valeros]

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?

[TD-er]

Yep, I guess so.