Spark Logic

Debugging Arduino sketch with STM32 Nucleo in Eclipse .. works !

michael_l Sat Aug 29, 2015 7:17 pm

I have followed this site http://gnuarmeclipse.livius.net/blog/install/ to install GNU arm toolchain, build tools, etc. Compiling works okay, binary is created. I’m using toolchain: gcc-arm-none-eabi-4_9-2015q2-20150609-win32
Debugging does not work. I am quite new to STM32, OpenOCD etc so I might do something wrong.

Based on this log I’m asking what could be wrong ? LD1 flashes red/green and nothing happens after this. It seems to be sort of stuck.

GNU ARM Eclipse 32-bits Open On-Chip Debugger 0.9.0-00073-gdd34716-dirty (2015-05-19-09:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Started by GNU ARM Eclipse
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.243243
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x20036410
Warn : STM32 flash size failed, probe inaccurate - assuming 128k flash
Info : flash size = 128kbytes
undefined debug reason 7 - target needs reset
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
semihosting is enabled
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc, semihosting
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0xfffffffc, semihosting
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 00000000 pc: 0x20000000 msp: 0x08000028, semihosting
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 00000000 pc: 0x20000000 msp: 0x08000028, semihosting
===== arm v7m registers
(0) r0 (/32): 0x00000020
(1) r1 (/32): 0x00000000
(2) r2 (/32): 0x2000003C
(3) r3 (/32): 0x2000083C
(4) r4 (/32): 0x08000028
(5) r5 (/32): 0x2000006C
(6) r6 (/32): 0x00000020
(7) r7 (/32): 0x00000014
(8) r8 (/32): 0x00000000
(9) r9 (/32): 0x00000000
(10) r10 (/32): 0x00000000
(11) r11 (/32): 0x00000000
(12) r12 (/32): 0x00000000
(13) sp (/32): 0x08000028
(14) lr (/32): 0xFFFFFFFF
(15) pc (/32): 0x20000000
(16) xPSR (/32): 0x00000000
(17) msp (/32): 0x08000028
(18) psp (/32): 0x00000000
(19) primask (/1): 0x00
(20) basepri (/8): 0x00
(21) faultmask (/1): 0x00
(22) control (/2): 0x00
===== Cortex-M DWT registers
(23) dwt_ctrl (/32)
(24) dwt_cyccnt (/32)
(25) dwt_0_comp (/32)
(26) dwt_0_mask (/4)
(27) dwt_0_function (/32)
(28) dwt_1_comp (/32)
(29) dwt_1_mask (/4)
(30) dwt_1_function (/32)
(31) dwt_2_comp (/32)
(32) dwt_2_mask (/4)
(33) dwt_2_function (/32)
(34) dwt_3_comp (/32)
(35) dwt_3_mask (/4)
(36) dwt_3_function (/32)

Replies

michael_l Mon Aug 31, 2015 7:09 am

Actually if the bug is in the IDE itself then I guess that manually starting GDB session and inserting breakpoints from commandline should work ?

michael_l Mon Aug 31, 2015 9:57 am

Loaded a another .elf compiled in Arduino. “info sources” in GDB shows this:

…
D:\Users\me\Documents\Arduino\libraries\U8glib\utility\u8g_com_api_16gr.c, D:\Users\me\Documents\Arduino\libraries\U8glib\utility\u8g_com_api.c,
D:\Users\me\Documents\Arduino\libraries\U8glib\utility\u8g_clip.c, D:\Users\me\Documents\Arduino\libraries\U8glib\utility\u8g_circle.c,
D:\Users\me\Documents\Arduino\libraries\U8glib\utility\u8g_bitmap.c, D:\Users\me\Documents\Arduino\libraries\U8glib\utility\chessengine.c,
D:\Users\me\Documents\Arduino\libraries\U8glib\U8glib.h, D:\Users\me\Documents\Arduino\libraries\U8glib\U8glib.cpp,
C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\HardwareSerial.h, C:\Program Files (x86)\Arduino/Blink3.ino,
D:\Users\me\AppData\Local\Temp\build321087032653580089.tmp\Blink3.cpp
…

I don’t know if this is an error because the path – at least to me – is wrong in elf. I have a hard time to believe this would be a bug in GDB? No wonder Eclipse gets upset.

I still wonder where does “C:\Program Files (x86)\Arduino” come from.

If I command:
(gdb) break loop()
Breakpoint 1 at 0x5ee: file Blink3.ino, line 247.

RogerClark Mon Aug 31, 2015 10:34 am

Looks line some rubbish the Arduino IDE generates :-(

michael_l Mon Aug 31, 2015 10:57 am

I’m using Arduino IDE 1.6.5

ahull Mon Aug 31, 2015 11:04 am

Looks like ” C:\Program Files (x86)\Arduino/Blink3.ino” is a Windowsland mistake.. surely ” C:\Program Files (x86)\Arduino\Blink3.ino” or ” C:/Program Files (x86)/Arduino/Blink3.ino”, but mixing both “\” and “/” in the path is asking for disaster.

michael_l Mon Aug 31, 2015 11:14 am

ahull wrote:Looks like ” C:\Program Files (x86)\Arduino/Blink3.ino” is a Windowsland mistake.. surely ” C:\Program Files (x86)\Arduino\Blink3.ino” or ” C:/Program Files (x86)/Arduino/Blink3.ino”, but mixing both “\” and “/” in the path is asking for disaster.

RogerClark Mon Aug 31, 2015 11:21 am

The Arduino IDE takes your_file.ino and adds various things like the necessary includes etc and generates you_file.cpp

You can open the cpp from the temporary directory

e.g. it adds this to the top of a blink sketch called GD32_test.ino

#line 1 "GD32_test.ino"
#include "Arduino.h"
void setup();
void loop();
#line 1

michael_l Mon Aug 31, 2015 11:25 am

Thanks!

Is there any chance to modify the Arduino build process a little ?

I’d like to modify this:

#line 1 “GD32_test.ino”

into hardcoded path e.g.

#line 1 “C:\users\me\My Documents\Arduino\…\GD32_test.ino”

zmemw16 Mon Aug 31, 2015 11:31 am

i did a quick look in ~/.arduino15, i suspect its from a .mk or Makefile
platform debian8 and arduino stock 1.6.5 linux 32bit binary
there is a ino.mk, actually a few, Makefiles and *.mk both way past my ability to follow:-)

stephen

RogerClark Mon Aug 31, 2015 11:45 am

This stuff is done internally by the IDE

The only place you could look to see if there is any slashes in the wrong direction is the platform.txt file.

its

Arduino\hardware\Arduino_STM32\GD32F1\platform.txt

However I took a quick look and I can’t see anyhing in there that looks like it would be doing what you’ve seen

Your best option is probably to post an issue to github.com/Arduino/Arduino

michael_l Mon Aug 31, 2015 12:05 pm

Is the whole source for Arduino IDE located here?

https://github.com/arduino/Arduino/tree/master/

I could try to hack something in first when I get a little bit of more time.

https://github.com/arduino/Arduino/comm … 359d886ccb

Looks like Sketch.java is the file to modify

EDIT: I was able to modify the .elf. I changed string Blinky.ino into c:\kky.ino (make sure you only overwrite)

‘info sources’ shows now this.

C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\hooks.c, C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\main.cpp,
C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\wiring_digital.c,
C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\wiring.c, c:\kky.ino,
D:\Users\lainemi\AppData\Local\Temp\build321087032653580089.tmp\Blinky.cpp

Let’s see what Eclipse says about that :-) Before that I have to copy original Blinky.ino –> c:\kky.ino.

michael_l Mon Aug 31, 2015 7:09 pm

michael_l wrote:
EDIT: I was able to modify the .elf. I changed string Blinky.ino into c:\kky.ino (make sure you only overwrite)

Let’s see what Eclipse says about that :-) Before that I have to copy original Blinky.ino –> c:\kky.ino.

RogerClark Mon Aug 31, 2015 9:22 pm

What do you mean when you say it doesnt work.

Do you mean it doesnt find that file, or is there some other error?

michael_l Mon Aug 31, 2015 9:44 pm

Ah.. Sorry. I mean that it still says it can’t find the source. In this case ‘c:\kky.ino’. Same path is now in .elf too but still it can’t find it. Unbelievable :shock:

michael_l Mon Aug 31, 2015 10:24 pm

It works with a small tweak !! Finally :-)

Image

.ino file in .elf –> not good. Have to get rid of that.

myblink.ino file contains only this line:

#include “C:\Program Files (x86)\Arduino\examples\01.Basics\myblink\myblink2.cpp”

myblink2.cpp:

#include <arduino.h>
// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin 13 as an output.
pinMode(13, OUTPUT);
Serial.begin(9600);
}

// the loop function runs over and over again forever
void loop() {
digitalWrite(13, HIGH); // turn the LED on (HIGH is the voltage level)
delay(100); // wait for a second
digitalWrite(13, LOW); // turn the LED off by making the voltage LOW
delay(100); // wait for a second
Serial.println(2);
}

mrburnette Mon Aug 31, 2015 11:08 pm

So this means it’s possible to get Eclipse debugging working with your STM32 with OpenOCD in WIndows in “5 minutes” without knowing much about GDB or OpenOcd. Eclipse is only used as debugging IDE and needs to have GDB and OpenOCD plugins installed.

@michael_l

OK, this is pretty darn cool… Looks like I will have to try and recreate this stew… always something to pimp my time :lol:

Ray

RogerClark Mon Aug 31, 2015 11:22 pm

Michael,

Thats fantastic news

Would it be possible for you to write some step by step instructions on how to do this.

Including which Eclipse to install etc

michael_l Tue Sep 01, 2015 6:07 am

Thanks, Ray and Roger.

Yeah, I’m happy to do that and save someone else’s time trying to do the same ! For some parts I’ll just refer to a great site which I found when investigating this. My order of Maple Mini’s and external ST-Link USB dongles are on their way so when they arrive I’ll try debugging with them also.

Now that debugging is working it’s time to start porting my Arduino Nano project for Nucleo and Maple Mini :) I posted an issue about this “.ino” to Arduino github – so let’s see what they think about that.

So for now getting .ino file opened in debugger remains as a mystery. When I have time I’ll try to do the same in Linux (or Linux in VirtualBox) just to see if the same problem exists there.

Sign in to reply