Anyone using openocd with STM32L476G-DISCO

Hi,

Recently I received this board: STM32L476G-DISCO. It has an ST-LINK unit on-board which connects via USB.

I'm having a problem to flash. openocd gives this error

Open On-Chip Debugger 0.10.0+dev-01524-g861e75f54-dirty (2020-12-08-16:29) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html hla_swd Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : clock speed 500 kHz Info : STLINK V2J37M26 (API v2) VID:PID 0483:374B Info : Target voltage: 3.209430 Error: init mode failed (unable to connect to the target)

Does anyone have this board too? I'm wondering if this should be working or not.

BTW. I've build openocd from the latest source code. The standard version in Ubuntu 20.04 is considered too old. It stops at the same error, though.

Hi,

I have that board at the office and should be able to test tomorrow.

From the openocd output it seems that openocd is not able to connect to the target. Can you try to press the reset button and release it when openocd tries to connect to the CPU ?

Alex

Woow, that did the trick.

2020-12-08 21:22:36,670 # �in(): This is RIOT! (Version: 2020.10-devel-2705-ga07d3) 2020-12-08 21:22:36,671 # Hello World! 2020-12-08 21:22:36,676 # You are running RIOT on a(n) stm32l476g-disco board. 2020-12-08 21:22:36,679 # This board features a(n) stm32 MCU.

Thanks.

BTW. Is this something that I could/should have read somewhere, in the famous RTFM?

Good know that it worked :slight_smile:

It's just that there's a missing command in the openocd configuration to force a reset when connecting openocd to the CPU. If that's not done, the connection could fail if the CPU is in deep sleep or crashed.

This is documented in the OpenOCD manual [1] (search connect_assert_srst [2]), but then you have to also know how things are wired in the RIOT build system, and this is not documented.

Alex

[1] http://openocd.org/doc/html/Reset-Configuration.html [2] The connect_type tokens control flags that describe some cases where SRST is asserted while connecting to the target. srst_nogate is required to use this option. connect_deassert_srst (default) indicates that SRST will not be asserted while connecting to the target. Its converse is connect_assert_srst, indicating that SRST will be asserted before any target connection. Only some targets support this feature, STM32 and STR9 are examples. This feature is useful if you are unable to connect to your target due to incorrect options byte config or illegal program execution.

Please be careful with inserting reset commands into the ocd scripts, sometimes you want to connect without reseting the device first (debug something that happend while you where not in a debuging session). Better soulutions might be to wait after bootup for the debugger to connect (use some busy waiting not not the xtimer wakeups since they save power) or if you dont need (that much) powersaving keep the debugports active while saving power.

busy waiting: (had this in a project that was much about getting the powerusage down)

  int x = 1000;   const uint32_t stop = xtimer_now_usec() + x - 1;   while(xtimer_now_usec() < stop);

or less power saving: (i got this in my devepolment main.c)

  void init_dbg(void){   #ifdef DBGMCU       DBGMCU->CR |= DBGMCU_CR_DBG_SLEEP_Msk|DBGMCU_CR_DBG_STOP_Msk|DBGMCU_CR_DBG_STANDBY_Msk;   #endif   }