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

RogerClark Wed Sep 02, 2015 9:17 pm

Michael,

I can concur with Rick.

GDB on the command line works fine.

I had to use it yesterday to find a nasty bug which caused __error() to be called, and I used backtrace “bt” to show the stack and work out precisely which line number things were on.

Well, I must admit, I didn’t list / display the code when I was doing by debugging yesterday, but I’m sure I’ve done it in the past, so I’m fairly sure that GDB knows where to look even with the Arduino IDE adding the Ino into the elf file etc

michael_l Thu Sep 03, 2015 4:22 am

Thanks guys for your support. It is a bug in Eclipse IDE. I submitted an issue – let’s see what happens. Would be nice to fix it but I could not find any instruction on how to download and build Eclipse C/C++ plus CDT from source.

Well, I do seem to have a problem too with my new progam receiving SIGINT. I compiled and ran for the first time my original program for Nano.

Then I pressed ‘Suspend’ on the IDE

#0 0x080022fe in gpio_write_bit (dev=0x20000324 <gpiob>, pin=1 '\001', val=1 '\001') at C:\Users\mika\Documents\Arduino\hardware\Arduino_STM32\STM32F1\system/libmaple/include/libmaple/gpio.h:92
#1 0x080023c6 in throb () at C:\Users\mika\Documents\Arduino\hardware\Arduino_STM32\STM32F1\cores\maple\libmaple\util.c:141
#2 0x08002348 in __error () at C:\Users\mika\Documents\Arduino\hardware\Arduino_STM32\STM32F1\cores\maple\libmaple\util.c:56
#3 0x08002348 in __error () at C:\Users\mika\Documents\Arduino\hardware\Arduino_STM32\STM32F1\cores\maple\libmaple\util.c:56
#4 0x00000000 in ?? ()

RogerClark Thu Sep 03, 2015 6:28 am

Michael

I had the throb() problem the other day.

Well, throb() is not the problem, its a symptom of the problem.

There is a error exception callback defined in one of the jump tables, called __error() and __error() calls throb() which flashes the LED

When I was debugging an issue I had with USB Serial, it ended up in throb() but i was able to use backtrace “bt” to see the call stack and work out which line in the boards setup source had really caused the problem. I just opened the file in notepad++ and looked at the line and it was then obvious what I’d been doing wrong.,
In my case it was an issue of variables not being initialised when they were used (read)

Anyway, lets hope the Eclipse team accept it as a bug and fix it.

michael_l Thu Sep 03, 2015 9:21 am

Instructions to debug Arduino sketches in Eclipse C/C++ IDE with STM32 and OpenOCD

Most of the stuff has been taken from: http://gnuarmeclipse.livius.net/blog/ which I followed. Here it is in a little more compact form.

# Eclipse IDE

Download and unzip Eclipse Mars for C/C++ (Win32) here:

https://www.eclipse.org/downloads/packa … pers/marsr

# GNU ARM plug-ins

The recommended way to install these plug-ins is to use the Eclipse standard install/update mechanism: In the Eclipse menu: Help ? Install New Software… -> Add

fill in Name: with GNU ARM Eclipse Plug-ins
fill in Location: with http://gnuarmeclipse.sourceforge.net/updates

Select all the plugins and install. It might warn you about untrusted plugins. Ignore that.

Next we’ll install :
– toolchain
– optional build tools (if you are running on Windows)
– debugging tools

# Toolchain

https://launchpad.net/gcc-arm-embedded

and from right select the second one which should be this:

https://launchpad.net/gcc-arm-embedded/ … -win32.exe

Install to (default): C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q2

!! leave unchecked: ‘Add path to environment variable’ and ‘launch gccvar.bat’

# Build tools (for windows)

http://sourceforge.net/projects/gnuarme … d%20Tools/

Download the first one on the list: (win32 2.6.xx)
http://sourceforge.net/projects/gnuarme … e/download

Install to (default) C:\Program Files\GNU ARM Eclipse\Build Tools folder:

Check the global tools path: Windows->Preferences->Build->Global Tools Path. If you installed toolchain and built tools in default locations these should have been found by IDE

Image

# Debugging tools (OpenOCD)

Install GNU ARM OpenOcd plugin from here: http://sourceforge.net/projects/gnuarme … D/Windows/ . I installed 0.9.0 which was latest. Installation goes by default here: C:\Program Files (x86)\GNU ARM Eclipse\OpenOCD\0.9.0-201505190955

This will enable OpenOCD Debugging.

Check Preferences->Run/Debug->OpenOCD to see if openocd.exe points to correct folder. It was filled automatically by IDE.

Board config file goes into ‘Config’ section: “-f board\st_nucleo_f103rb.cfg”. In my case there was a ready made config file for Nucleo-F103RB. There are more board config files to choose in directory scripts\board.

It’s time to test if OpenOCD can connect to your board. In my case there was ready made config for Nucleo-F103RB. As you might understand this is a mandatory step to get debugging working. OpenOCD will talk to your debugging interface forwarding commands from IDE.

C:\Program Files (x86)\GNU ARM Eclipse\OpenOCD\0.9.0-201505190955\bin>openocd.exe -f ..\scripts\board\st_nucleo_f103rb.cfg
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 mi
ght 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
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.247525
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

RogerClark Thu Sep 03, 2015 10:13 am

Hi Michael

I think its best to leave it here until a few people have tried the instructions and have ironed out any kinks etc

Once we are sure the instructions work for most people, we can move it to the top of the thread

Thanks again

Roger

RogerClark Thu Sep 03, 2015 8:54 pm

thanks for the link

RogerClark Sun Sep 06, 2015 10:33 am

michael

I have tried following your instructions, and have installed Eclipse etc

However I had a problem with the Arduino IDE.

I changed my bink_pc13.ino to just have an include to my cpp e.g.

#include "C:\Users\roger\Documents\Arduino\blink_pc13\blink_src.cpp"

michael_l Sun Sep 06, 2015 6:27 pm

Roger,

Very good points here and a few mistakes from me. I just edited and added more information.

The error message you’re seeing is because you most probably didn’t create a ‘dummy’ STM32 project from File->New C Project->STM32F10x, did you ? This sets the correct path for ARM compiler and enables variables: {cross_prefix} and {cross_suffix}. I did get the same error. If you dont’ get this working I believe you can hard-code the full path to arm-none-eabi-gdb.exe because that’s what it uses.

Yes, you’ll have to have ST-Link drivers installed and working. I have Nucleo-F103RB which has on-board ST-Link v2.1.I just installed driver package from ST’s website. Anyway.. for Nucleo-F103RB there’s a ready made configuration under OpenOCD’s directory. It’s a script that executes several other config files:

# This is an ST NUCLEO F103RB board with a single STM32F103RBT6 chip.
# http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF259875

source [find interface/stlink-v2-1.cfg]

transport select hla_swd

source [find target/stm32f1x.cfg]

reset_config srst_only

RogerClark Sun Sep 06, 2015 9:11 pm

Hi Michael

I think I made the dummy project correctly, but as you say, I must be missing some config.

The laptop I was using for testing did not have STM’s STLink driver, but I have now installed this.

I will take another look this evening to see if I can figure out which paths are missing, but I have followed all of your instructions as far as I can tell.

michael_l Mon Sep 07, 2015 7:28 pm

Yes, this is interesting. I don’t remember setting those cross_prefix and cross_suffix variables anywhere. They must come within toolchain I think. Also where to find those variables under preferences or project settings is a bit of a mystery to me. Eclipse surely is a very nice IDE and there are many configuration options.

michael_l Wed Sep 09, 2015 3:03 pm

Roger, did you have any time to test this further ?

I just received my first “blue pill” and St-Link V2 dongle (clone). I’ll try how debugging works in next few days I believe.

michael_l Wed Sep 09, 2015 7:49 pm

Just tried debugging with ST-Link V2 “Dongle” Mini Metal Shield and ‘Blue Pill’ and it works okay. I used STLINK for uploading and I don’t have uploaded a bootloader.

For OpenOCD config I created a new file with this contents (thanks to Rick)


# This is for the $4.29 ebay ST-Link V2 Mini Metal Shell and an stm32f103 board
# http://www.ebay.com/itm/251642538698

source [find interface/stlink-v2.cfg]

transport select hla_swd

set WORKAREASIZE 0x2000
source [find target/stm32f1x.cfg]

reset_config none

ilg Fri Oct 09, 2015 7:25 am

RogerClark wrote:Anyway, lets hope the Eclipse team accept it as a bug and fix it.

robca Tue Dec 22, 2015 10:44 am

I’m trying to install the full toolchain to debug. I’ve done everything, but I can’t get the last step. The file http://www.megafileupload.com/54w6/ardu … p-2015.zip has been removed from megaupload due to lack of activity

I tried using the xxx.cpp trick (admittedly with a slightly more complex project), but I’m getting a lot of compile errors in the last phase. So I wanted to use the modified IDE instead but, well :)

stevech Tue Dec 22, 2015 3:25 pm

using what OS?

robca Tue Dec 22, 2015 3:43 pm

Windows x64…. everything works when used normally, I simply need the modified Arduino IDE at this point, to create the right .elf file

martinayotte Tue Dec 22, 2015 4:01 pm

What do you mean by “create the right .elf file” ?
It is already generated in the /tmp folder, and from it, the .bin is created.
This mechanism is driven by commands and flags located in the platform.txt

robca Tue Dec 22, 2015 4:08 pm

I’m referring to this:

Switch to Arduino IDE

enable ‘Show verbose output during [x] compilation’ from Arduino IDE

Now you have two choices:

1) Use regular Arduino IDE:
because of a bug in Eclipse Win32 IDE you have to make a small change in your .ino file. Without this step you won’t be able to debug original .ino file. Let’s say you have a sketch called blink.ino

for ‘blink.ino’ create blink2.cpp file (not blink.cpp)

copy contents of blink.ino into blink2.cpp

edit original blink.ino file so that it contains only this line: #include “C:\Program Files (x86)\Arduino\examples\01.Basics\myblink\myblink2.cpp” and add #include <Arduino.h> to the first line.

2) use modified Arduino IDE. Download link is here: http://www.megafileupload.com/54w6/ardu … p-2015.zip. During compilation of .ino file it will remove #line directives from the .cpp that Arduino generates. #line directive generates reference to blink.ino file in the .elf and it seems to confuse Eclipse IDE (Win32 at least) so that it can’t find the file. More about that in this thread.

In this post http://www.stm32duino.com/viewtopic.php … t=60#p5475

Or has that problem been since fixed?

martinayotte Tue Dec 22, 2015 6:24 pm

Ah ! I see …
No, the issue still probably there.
Did you try what Roger tried, ie : having a *.ino only to include a *.cpp and having all the code itself into the *.cpp ?

Sign in to reply