Hope you can give me some guidance, as I am currently trying to setup debugging. But first things first …
I have a Arduino Due compatible board with JTAG connector and I want to debug my code.
That’s why I bought the Atmel-ICE external debugger. I connected it with my board and currently I am using the PlatformIO default settings for debug.
Somehow it’s working, but it feels bit clumsy.
I do have init sequence of external sensors (accelerometer, distance measuring, display via SPI) in the setup function.
In addition, I setup the watchdog timer during init.
I uploaded my program via Atmel-ice (debug symbols enabled).
My first problem is the watchdog timer. It will reset the mcu after 8s not invoking the reset function.
As loading memory, symbols etc takes quite long the mcu resets nearly immediately after setup has been finished. Is there any chance to recognize, that the debugger is attached or the debug build is loaded in order to deactivate watchdog timer entirely?
I tried using the debug_build_flags = -D DISABLE_WATCHDOG, but it seems not be allowed to pass defines.
I used to have init problems after the first start after flashing (even without all the debug stuff).
That’s why I would like to attach the debugger without uploading. From what I understand, the second target, that skips the pre-debug task is meant for that. Unfortunately, the display is always blank (white). Could the debugger disturb the display, as both are running on the same bus?
Is it necessary to reset the mcu, when the debugger is attaching?
Are there any options to improve the debug experience? Unfortunately, I cannot change the controller. Using STM32 would be probably easier for debugging, as debugger is built-in, right?
Thanks for your reply.
Sorry, it seems that my initial post was not describing my environment precisely enough.
Yes, I am enabling the watchdog timer myself. It should be enabled in a release build. The problem is, that the timeout is exceeded when attaching the debugger (as this takes several seconds).
Not sure, if there is a better solution, but my idea was to disable the watchdog timer for a debug build. Therefore I tried to introduce another define variable, that prevents compiling the appropriate code snippet.
You’re right, it seems that setting a define variable with debug_build_flags is not supported.
Based on the similar name to the build_flags, I thought I could pass some defines for a debug build. But obviously this assumption was wrong.
I started this project on AVR based Arduino, that’s why I’ve to distinguish between Atmel (Arduino Due) and AVR (Arduino Mega2560).
This is the error I get:
.pio/build/Project/libFrameworkArduino.a(UARTClass.cpp.o): In function `HardwareSerial::HardwareSerial()':
UARTClass.cpp:(.text._ZN14HardwareSerialC2Ev[_ZN14HardwareSerialC5Ev]+0x20): undefined reference to `vtable for HardwareSerial'
collect2: error: ld returned 1 exit status
*** [.pio/build/Project/firmware.elf] Error 1
I do not understand what’s happening. It seems to be a linking error?!
The problem only occurs, when the define variable is set and only for debug_build_flags. Setting the same variable as build_flags it’s working fine.
Also removing the #ifndef results in an error as long as the debug_build_flags are set.
I am initializing 2 serial interfaces (Serial and Serial1). The first is obviously for the communication to the pc, and the second one is used to communicate with the distance sensor.
That said, both are working fine when not using debug_build_flags.
Thanks, adding the default values actually solves the problem for me, too.
I uploaded the firmware including the debug symbols and now I would like to attach the debugger.
When the debugger attaches, the device will be rested. Is the reset necessary?
After reset cycle, the debugger pause at a random breakpoint - at least it seems so be random.
As you saw in my platformio.ini I’ve removed the debug_init_break, but it still stops at the somewhere at the very beginning.
In addition, after the reset the display is always blank. The display is connected via 4wire SPI. From what I understand the JTAG is also using SPI, right?
Is it possible, that the debugger disturbs the display communication?
Is there any way to recognize if a device runs a debug build of the firmware?
Hm, might have to do with the default debug_init_cmds where the target is (maybe) flashed, halted, breakpoints are added, and then restarted again, but without a debug_init_break it would behave differently.
Since I’ve not worked with the chip on the Arduino Due before I can’t tell that. Are the JTAG / SWD pins overlapping with the SPI pins? That would be weird because then you couldn’t debug the target and use the display. Usually those are different pins / pads.
Maybe it’s also an effect that PlatformIO resets the board and the display initialization routine is run that triggers a display clear / reset? In my view it would be very unlikely that, even if JTAG signals were given on the SPI bus, that those would be valid or triggering just the right SPI writes / commands to trigger a reset. But if one of the JTAG lines is also connected to a display reset line, it might caue it ofc.
Thanks for your comments.
Sorry, I was mixing things up: The JTAG does not have any connection to the SPI bus (nor to the display).
It’s not clear to me why the display resets. I’ll try to set a breakpoint before initialization and see if I can find some hints …
I played around and did not find any regularity.
When I place a breakpoint at the first line of the setup method of my code, neither the display (SPI with DMA) nor the distance sensor (Serial1) will properly initialize.
I do not have much experience, but it could be related to some timings. That said, I don’t know why. The initialization of the distance sensor is the very first thing in the main function. Basically, that just enabling power for it and sending an init command via Serial1 - that’s it.
I found out, when placing the breakpoint at the very end of the main function, the distance sensor will initialize. Not sure why this makes a difference. The init sequence is also run, when stepping through it, but the distance sensor does not response.
Btw, this also happens, directly after flashing a firmware without debugging (via sam-ba). It seems, that the distance sensor is quite sensible …
The weird thing is, that the display does not work once the debugger is attached.
The backlight is turned on from my code, and the background is always blank/white. That said, it’s weird as I am not sure, if the background is white by default. I am drawing the background white - not sure if this triggers the white background or any reset.
When starting the Arduino without debugger, display is working fine. Maybe it’s a problem of the DMA?
All over all, the debugger is now working much better as the watchdog is now disabled when uploading the debug firmware.
Appreciate your help
The problem I am having, and why I found this, is that it overrides the base debug_build_flags so I need to explicitly specify the no optimization and include debug info flags. Is it not possible to extend a built in variable in certain env sections eg