porlock
September 20, 2020, 7:59pm
1
Hi i successfully used Simavr and it works fine, till time it stops without any specific reason.
Failed to Lanych GDB: .pioinit:10: Error in sourced command file: Remote connection closed (from interpreter-exec console “source. pioinit”)
My launch.json looks like this:
{
and platformio.ini like this:
[env:nanoatmega328]
i use following version
Updating platformio/contrib-piohome 3.3.0 @ ~3.3.0 [Up-to-date]
Platform Manager
Platform atmelavr
Library Manager
Library Storage: C:\Users\porlock.platformio\lib
Platform Manager
Platform atmelavr
Updating platformio/atmelavr 2.2.0 [Up-to-date]
I am now experiencing the same. Projects that have worked without issue are now getting .pioinit 10. I have done a clean on the project and reset the board with no change. I have confirmed I am running the latest PlatformIO updates. I tried a second board (same model) the most basic sketch and no change.
PlatformIO Unified Debugger → Redirecting...
I cannot reproduce this behavior.
I use the platformio.ini above with src\main.cpp code
#include <Arduino.h>
void setup() {
Serial.begin(9600);
}
void loop() {
delay(1000);
}
, then I make sure that the correct project and environment is selected (also in the PIO unified debugger) and press play.
VSCode then looks like
so, the debugger is started. If I then place a breakpoint in my user code and press “Play”…
It is hit poroperly.
The issue seems with your Atmel AVR platform version… the latest one is 3.2.0 , not 2.2.0 , and for me during build the output also says PLATFORM: Atmel AVR (3.2.0) > Arduino Nano ATmega328.
Can you open a CLI and type pio platform update atmelavr and retry?
My sketch is the same as yours with the same breakpoint, I did the update as requested and tried again; no change - same error message. Just before it fails I see this in the debug console;
PlatformIO Unified Debugger → Redirecting...
platformio.ini is the default created;
[env:leonardo]
When you scroll up in the output, does it say
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelavr/nanoatmega328.html
PLATFORM: Atmel AVR (3.2.0) > Arduino Nano ATmega328
HARDWARE: ATMEGA328P 16MHz, 2KB RAM, 30KB Flash
DEBUG: Current (simavr) On-board (avr-stub, simavr)
?
Does setting platform = atmelavr@3.2.0 in the platformio.ini help? (Remove the old platform = .. line before that)
Thanks for the quick response, appreciated.
I made the change in the platformio.ini file and still get the same error.
[env:leonardo]
Here is the output in the debug console;
Verbose mode can be enabled via -v, --verbose optionRedirecting...
Can you again open the CLI per above and execute
pio upgrade --dev
to get the latest core version? Does it work then?
PlatformIO has been successfully upgraded to 5.1.1a3
same error.
Is there an antivirus active that could prevent or delay the start of simavr.exe?
If you open a Windows terminal (Windows + R -> cmd.exe) and execute
cd C:\Users\<user>\.platformio\packages\tool-simavr\bin
simavr -m atmega328p -g 1234 <path to elf file>
(with e.g. path C:\Users\Max\Documents\PlatformIO\Projects\esp8266_airfilter\.pio\build\nanoatmega328\firmware.elf in my case), does it output
C:\Users\Max\.platformio\packages\tool-simavr\bin>simavr -m atmega328p -g 1234 C:\Users\Max\Documents\PlatformIO\Projects\esp8266_airfilter\.pio\build\nanoatmega328\firmware.elf
Loaded 4306 .text at address 0x0
Loaded 38 .data
avr_gdb_init listening on port 1234
or does it output an error?
You are not going to believe this. I think I figured it out, I closed all other applications and the problem went away. I narrowed it down to Fusion 360 causing the issue. I just received an update for March 2021 and it aligns with timing for the issue starting with the debugger.
I close Fusion and the problem goes away, I reopen Fusion and it’s back.
Went back to the original project and it is working fine again.
Thanks for the quick support. I didn’t even think something like Fusion would cause this type of issue.
2 Likes
Either it delays the start of the executable, sandboxes it or it doesn’t like it that simavr.exe is opening a listening network port on (I think) port 1234. Maybe you can try and add the simavr executable to some exception list?
1 Like
I will submit a question to Fusion 360 about the latest update and associated impact. I will let you know if I get anything back that helps.
Ah my bad, Fusion 360 is no antivirus program, it’s a 3D CAD program. So no sandboxing or delaying execution start should be going on.
So the more logical explanation would be that there is a port conflict – Fusion 360 seems to occupy the same listening port that simavr tries to open.
Per
"port": ":1234",
"server": {
"package": "tool-simavr",
"arguments": [
"-g",
"-m", debug["simavr_target"],
"-f", build.get("f_cpu", "")
],
"executable": "bin/simavr"
that should be 1234 but when execute netstat -abn in a cmd.exe shell started as administrator and I can see
[simavr.exe]
TCP 0.0.0.0:5040 0.0.0.0:0 ABHTREN
CDPSvc
[simavr.exe]
TCP 127.0.0.1:8010 0.0.0.0:0 ABHTREN
it’s… 8010? Weird.
You cana also start Fusion360 and use the above command to check what ports the executable is binding to.
Anyways yeah that seems to be the problem. I’ll see to it that an issue is opened in the core that checks if the port an application will try to bind is free or not to inform the user of that.
1 Like
Only port that comes close is 8181, the rest are either external or in the 50K range.
Lol i also use fusion very often but not connected this two facts
1 Like
thanks …