OpenOCD support for external STLink debugger

[Lubos Medovarsky]

Posted on November 05, 2017 at 07:41

Hi all,

Is anyone using OpenOCD with genuine external STLinkV2 debugger/programmer and STM32L0? Clearly, there is an issue as I have tested multiple units and OpenOCD releases (0.9, 0.10.).

The debuggers are fully functional in non-OpenOCD environments like STLink utility, QSTLink, Keil, etc. Additionally, I have tested STLinkV2-1 firmware with L053-Discovery, Nucleo-L053R8, EVAL-L073VZ. The boards work with OpenOCD as expected.

Besides USB VID/PID, OpenOCD makes no difference between STLinkV2 and STLinkV2-1 in the scripts referenced below.

Tested devices: STM32L052/053/063 C6/C8 (QFP48, 16/32 kiB FLASH).

Environment: Linux.

Command line with freshly built release 0.10.0 and stlink support enabled:

/patch/to/openocd -s /path/to/openocd/share/scripts -f interface/stlink-v2.cfg -c 'transport select hla_swd' -f target/stm32l0.cfg --debug

returns:

...

Info : 306 36 cortex_m.c:2056 cortex_m_examine(): stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints

Debug: 307 36 target.c:1517 target_call_event_callbacks(): target event 22 (examine-end)Debug: 308 36 target.c:4313 target_handle_event(): target: (0) stm32l0.cpu (hla_target) event: 22 (examine-end) action:     ♯ DBGMCU_CR |= DBG_STANDBY | DBG_STOP | DBG_SLEEP    mmw 0x40015804 0x00000007 0

    ♯ Stop watchdog counters during halt

    ♯ DBGMCU_APB1_FZ |= DBG_IWDG_STOP | DBG_WWDG_STOP    mmw 0x40015808 0x00001800 0

Debug: 309 36 hla_target.c:750 adapter_read_memory(): adapter_read_memory 0x40015804 4 1

Debug: 310 38 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_mww 0x40015804 7Debug: 311 38 command.c:143 script_debug(): command - mww ocd_mww 0x40015804 7Debug: 313 39 hla_target.c:764 adapter_write_memory(): adapter_write_memory 0x40015804 4 1Debug: 314 40 hla_target.c:750 adapter_read_memory(): adapter_read_memory 0x40015808 4 1Debug: 315 41 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_mww 0x40015808 6144Debug: 316 41 command.c:143 script_debug(): command - mww ocd_mww 0x40015808 6144Debug: 318 42 hla_target.c:764 adapter_write_memory(): adapter_write_memory 0x40015808 4 1Debug: 319 43 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_flash initDebug: 320 43 command.c:143 script_debug(): command - ocd_flash ocd_flash initDebug: 322 44 tcl.c:1099 handle_flash_init_command(): Initializing flash devices...Debug: 323 44 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 324 44 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 325 44 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 326 44 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 327 44 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 328 45 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 329 45 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 330 45 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 331 45 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 332 45 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 333 45 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 334 45 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 335 45 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 336 45 command.c:364 register_command_handler(): registering 'ocd_flash'...Debug: 337 45 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_mflash initDebug: 338 45 command.c:143 script_debug(): command - ocd_mflash ocd_mflash initDebug: 340 46 mflash.c:1377 handle_mflash_init_command(): Initializing mflash devices...Debug: 341 46 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_nand initDebug: 342 46 command.c:143 script_debug(): command - ocd_nand ocd_nand initDebug: 344 47 tcl.c:497 handle_nand_init_command(): Initializing NAND devices...Debug: 345 47 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_pld initDebug: 346 47 command.c:143 script_debug(): command - ocd_pld ocd_pld initDebug: 348 48 pld.c:205 handle_pld_init_command(): Initializing PLDs...<hangs here>

The complete OpenOCD log is attached.

Using fake debuggers is not an option as I'm developing devices operating at low voltages, and we have already bought multiple genuine devices for our team.

Any suggestions are welcome.

#stlink-v2 #linux #stlink #debugger #stm32l0 #openocd

[Tesla DeLorean]

Posted on November 05, 2017 at 14:47

This would be something you need to take up with the OpenOCD dev team, via mailing lists, github or forums

[Lubos Medovarsky]

Posted on November 06, 2017 at 02:53

OpenOCD team is doing excellent job, but they are doing it for other than commercial reasons, I suppose. I do count on them as a last resort.

Anyway, I can't believe nobody else uses the original STLinkV2 with OpenOCD.

This inspired me to check SW4STM32. Based on 

http://www.openstm32.org/HomePage

:

ST-LINK support

I'll try asap, and keep this thread updated.

Regards

Lubos

[Lubos Medovarsky]

Posted on November 06, 2017 at 23:12

Hi all,

I've found a partial solution.

The original STLinkV2 programmer works with OpenOCD version 0.10.0-dev-00005-g4030e1c-dirty, bundled in SW4STM32. The trick is that it connects through stlink-server tool, which mediates the communication properly. The configuration is in SystemWorkbench/plugins/fr.ac6.mcu.debug_2.1.3.201710240950/resources/openocd/st_scripts/interface/stlink-tcp.cfg. The server listens at 127.0.0.1:7184/tcp.

It seems that vanilla OpenOCD 0.10.0 does not know (logically) how to communicate using STLink TCP interface:

Error: No adapter layout 'stlink-tcp' found

As OpenOCD is GPL licensed, I expected to find the patches on the vendor's site, but failed to find them.

Lubos

[LaurentL]

Posted on November 07, 2017 at 14:01

Hello,

In the log, the device id is read but return value is 0 so there is an issue there.

Is it working with SW4STM32 with openocd in normal mode ?

Note that you can change reset options in debug config window (in debugger tab).

If you didn't connect reset line from stlink to mcu, you might select 'software system reset'.

Rgds,

Laurent

[LaurentL]

Posted on November 07, 2017 at 14:15

Hi,

For the openocd src of SW4STM32, you should be able to clone the git :

git://git.ac6.fr/openocd

Or ask for help on SW4STM32 forum.

Rgds,

Laurent

[Lubos Medovarsky]

Posted on November 09, 2017 at 14:45

Thanks, I'll take a look at the TCP transport.

IMHO, this should be merged into the official tree. It's too useful to be forgotten. I'm debugging using TCP transport, it works like a charm.

[Lubos Medovarsky]

Posted on November 09, 2017 at 15:55

 ,

 ,

Good point. The very same OpenOCD binary from AC6 also works in normal mode, while vanilla 0.10.0 release does not.

Tried various standard and non-standard reset configurations with vanilla OpenOCD and ST boards, without success.

UPDATE:

Built OpenOCD from AC6, and it works!

Tested with:

• STM32L073-EVAL
• OpenOCD from AC6, master branch, HEAD at commit 2731f8b429568d206ecbed815e4cd6732bbadccb from 'Wed Feb 22 10:02:28 2017 +0100'.

This took pretty long. I'm not sure about STLinkV2 sales though. Am I the only one with my team, who emptied some warehouses recently? It looks like garage manufacturers in China are doing ST pretty significant favor for free. 🙂

UPDATE ♯ 2:

I compared AC6 repository against the official tree. The last common commit is 73b676c ('helper/fileio: Remove nested struct', 2015-10-04). The solution has to be located in the code commited after this particular commit.

UPDATE ♯ 3:

I've built OpenOCD from Eclipse repository at

https://github.com/gnu-mcu-eclipse/openocd.git

. They maintain their own branch (and don't mess up their patches with master branch as AC6). It does not work with STLinkV2. The symptoms are the same.

[Doug Kehn]

Posted on November 10, 2017 at 14:36

I'm not using STM32L0 so my configuration is different. However, for reference, I'm using openocd v0.10.0 with STLinkV2, STM32F777/765, and Atollic TrueSTUDIO Toolchain on Ubuntu 16.04 host with no problems. I'm also using openocd v0.10.0 with STLinkV2-1, Nucleo-144 767ZI, and ARM GNU Embedded Toolchain on Arch Linux host with no problems.

Have you tried telnet to port 4444 after starting openocd to determine if this interface is working?

[Lubos Medovarsky]

Posted on November 11, 2017 at 11:47

No. F0 target works well with OpenOCD. It's only relatively newer L0 that has issues.