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
        }


On 08/12/2020 21:43, Alexandre Abadie wrote:
Good know that it worked :)

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.

----- Le 8 Déc 20, à 21:24, Kees Bakker k...@ijzerbout.nl a écrit :

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?

On 08-12-2020 21:17, Alexandre Abadie wrote:
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

----- Le 8 Déc 20, à 21:10, Kees Bakker k...@ijzerbout.nl a écrit :

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.
--
Kees
_______________________________________________
users mailing list
users@riot-os.org
https://lists.riot-os.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@riot-os.org
https://lists.riot-os.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@riot-os.org
https://lists.riot-os.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@riot-os.org
https://lists.riot-os.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@riot-os.org
https://lists.riot-os.org/mailman/listinfo/users

Reply via email to