CLion error (HardwareSerial0)


I have an issue I can’t deal with it. As a preamble, I did check on Google, but I did not find any solution (all the first page).

I made an integration with CLion, I did a brand new project (because It’s not my real project but I want to start simply first) and I want to debug a simple program. I wrote this in my main.c:

#include <Arduino.h>
#include <avr8-stub.h>

static int a = 3;

    void setup() {
        pinMode(LED_BUILTIN, OUTPUT);

    void loop() {

All the includes are recognized and there’s no error for this, but I try to launch the debug, with my Mega 2560 connected on COM3, I have the following error:

HardwareSerial0.cpp.o (symbol from plugin): In function `Serial':
(.text+0x0): multiple definition of `__vector_25'
avr8-stub.c.o (symbol from plugin):(.text+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\megaatmega2560\firmware.elf] Error 1

I don’t understand what and where it is defined. Also, my platformio.ini:

    platform = atmelavr
    board = megaatmega2560
    framework = arduino
    debug_tool = avr-stub
    debug_port = COM3
    lib_deps = 
    	jdolinay/avr-debugger@ ~1.4

If someone could help me, I would be glad, I really need the debugger for my uni project.

PS: I would like to add that this error also happens in VSCode

As stated in the official documentation on avr-stub limitations, you cannot use the Serial in your own program since that is exactly what avr-stub is using to transport the GDB messages – the serial. Rewrite your program to use a different one of the available ATMega2560’s serials, as per docs, Serial1, Serial2, Serial3. You will need to connect an additional USB-UART converter to those serial pins then to see the output.

1 Like

Crap. I was not given this hardware. Guess I’ll use tries to debug my program. Thank you for your kind reply!

If your firmware does not rely on serial input to execute its logic, you might also think about removing all calls to Serial. After all, Serial usually prints debug information or variable contents, which you can also see in the debugger, so it’s redundant.

Hm, true but I think I need it because I’m using Serial1 for a GPS. I could remove Serial but definitely not Serial1.

Serial1 cause a conflict with Serial – only the vectors (interrupt handlers) for Serial(0) and a generic GPIO interrupt vector is the problem.

1 Like