JLINK EDU segger JTAG to debug STM32 microcontrollers

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderators: RoccoMarco, barthess

aicastell
Posts: 12
Joined: Tue Sep 04, 2018 11:03 am
Has thanked: 6 times

JLINK EDU segger JTAG to debug STM32 microcontrollers

Postby aicastell » Thu Sep 20, 2018 3:24 pm

I have a j-link EDU SEGGER J-TAG available, and would like to use it to debug a Chibios application developed using a STM32F072B microcontroller. Packages openocd and arm-none-eabi-gdb are properly installed in my Ubuntu development host. The content of myboard.conf openocd configuration file is this:

Code: Select all

$ cat /usr/share/openocd/scripts/board/myboard.cfg

source [find interface/jlink.cfg]
transport select swd
source [find target/stm32f0x.cfg]

telnet_port 4444
gdb_port 3333
adapter_khz 10
init
reset halt


I can run openocd, and according to the log below, it seems to work fine:

Code: Select all

# openocd -f /usr/share/openocd/scripts/board/myboard.cfg
Open On-Chip Debugger 0.9.0-dev-00156-gc0b8e60 (2016-05-18-09:19)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : JLink SWD mode enabled
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
cortex_m reset_config sysresetreq
adapter speed: 10 kHz
Info : J-Link V9 compiled Aug 23 2018 09:45:44
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 93000
Info : J-Link hw type J-Link
Info : J-Link max mem block 69416
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0xffffffff
Info : Vref = 3.320 TCK = 0 TDI = 0 TDO = 0 TMS = 1 SRST = 1 TRST = 0
Info : J-Link JTAG Interface ready
Info : clock speed 10 kHz
Info : SWD IDCODE 0x0bb11477
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x080000c0 msp: 0x20000400


In a second console I execute gdb debugger:

Code: Select all

# arm-none-eabi-gdb
(gdb) target remote localhost:3333
(gdb) symbol-file /path/to/myproject.elf
(gdb) b myfunction
(gdb) cont


After very few instructions stepped with some dificulty, some errors appear on the openocd console:

Code: Select all

Error: SWD ack not OK: 4 FAULT
Error: Failed to read memory at 0xfffffff1
Error: SWD ack not OK: 4 FAULT
Error: Failed to read memory at 0xfffffff1
Error: SWD ack not OK: 4 FAULT
Error: Failed to read memory at 0xfffffff2


And the gdb console completely hangs.

Does some of you have some experience with this JTAG debugger? Can it be configured to be completely stable and functional?

Thanks in advance! :-)

User avatar
Giovanni
Site Admin
Posts: 14457
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1076 times
Been thanked: 922 times
Contact:

Re: JLINK EDU segger JTAG to debug STM32 microcontrollers

Postby Giovanni » Thu Sep 20, 2018 6:15 pm

Hi,

You need to configure it to use SWD not JTAG.

Giovanni

electronic_eel
Posts: 77
Joined: Sat Mar 19, 2016 8:07 pm
Been thanked: 17 times

Re: JLINK EDU segger JTAG to debug STM32 microcontrollers

Postby electronic_eel » Thu Sep 20, 2018 9:08 pm

I'm not sure how well J-Link and OpenOCD work together.

I'd try to use the gdb server from Segger instead. The J-Link probes and the Segger software are designed to work together.

aicastell
Posts: 12
Joined: Tue Sep 04, 2018 11:03 am
Has thanked: 6 times

Re: JLINK EDU segger JTAG to debug STM32 microcontrollers

Postby aicastell » Fri Sep 21, 2018 11:40 am

Hi all.

The openocd setup file attached previosly has this line:

Code: Select all

transport select swd


I assumed that option enables SWD as expected, but probably I am missing something else, the setup of that tool is more complex than expected (>_<), I just wanted to check the content of a variable [...]

I have tested JLinkGDBServerExe server as an alternative to openocd. It's a very nice tool. You can select exactly the microcontroller model, the endianism and the target interface (SWD). Now I can step over the instrucctions of my controller, as expected.

But I am getting very strange behaviours. For example, in a line like this:

Code: Select all

uint32_t aux1 = (lcp->dwDTERate[0]) + (lcp->dwDTERate[1] << 8) + (lcp->dwDTERate[2] << 16) + (lcp->dwDTERate [3] << 24);


I get this ilogical results:

Code: Select all

(gdb) p/x lcp->dwDTERate
$14 = {0x80, 0x25, 0x0, 0x0}
(gdb) p (lcp->dwDTERate[0]) + (lcp->dwDTERate[1] << 8) + (lcp->dwDTERate[2] << 16) + (lcp->dwDTERate [3] << 24)
$15 = 9600
(gdb) p aux1
$16 = 134246771
(gdb) p/x aux1
$17 = 0x8007173


Anyway, after a lot of fighting with this, I was able to modify my source code to work as expected. Debugger wasn't very helpfull after all.

Thanks a lot for your time!

electronic_eel
Posts: 77
Joined: Sat Mar 19, 2016 8:07 pm
Been thanked: 17 times

Re: JLINK EDU segger JTAG to debug STM32 microcontrollers

Postby electronic_eel » Fri Sep 21, 2018 9:24 pm

aicastell wrote:But I am getting very strange behaviours. For example, in a line like this:
I get this ilogical results:

This looks a bit like it could be caused by compiler optimization.

If you want to use the debugger, you either have to look at the assembler code or compile everything without optimization (-O0).

aicastell
Posts: 12
Joined: Tue Sep 04, 2018 11:03 am
Has thanked: 6 times

Re: JLINK EDU segger JTAG to debug STM32 microcontrollers

Postby aicastell » Mon Sep 24, 2018 7:28 am

Thanks a lot for your advice, that's a good point. I didn't fall into that detail but you are right, that could be the problem. I have checked it now:

The main Makefile of my project includes this line:

Code: Select all

# Compiler options here.
ifeq ($(USE_OPT),)
  USE_OPT = -O0 -ggdb -fomit-frame-pointer -falign-functions=16
endif


When I compile, the compiler starts with these logs:

Code: Select all

$ arm-none-eabi-gcc -c -mcpu=cortex-m0 -O0 -ggdb -fomit-frame-pointer -falign-functions=16 -ffunction-sections -fdata-sections -fno-common ...


So after checking the Makefile I think compiled binary includes no optimizations. However, it would be really useful to discover what is wrong because sooner than later I will need to use the debugger again.


Return to “STM32 Support”

Who is online

Users browsing this forum: No registered users and 48 guests