13:54 <phr3ak> is it possible to check that the CPU is not dead and that there is any communication without giving the specific CPU type to openocd?

13:55 <phr3ak> it will be a GD32F450

15:12 <PaulFertser> phr3ak: sure, if you know its core

15:12 <PaulFertser> phr3ak: cortex-m?

16:26 <phr3ak> i tried it with gd32 and stm32f4xx cfg

16:27 <phr3ak> gd32e23x cfg

16:29 <phr3ak> xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc Info : device id = 0x16080419 Warn : Cannot identify target as a STM32 family.

16:30 <phr3ak> what do you think about this device id? is it sign of any life?

18:42 <PaulFertser> phr3ak: that means the core is detected all right. ID is about the flash driver etc.

18:42 <PaulFertser> phr3ak: if you get the message that lists hardware breakpoints number, it's alive all right.

19:07 <phr3ak> the external reset detected message kept repeating

19:08 <phr3ak> nrst is high

19:09 <PaulFertser> phr3ak: probably watchdog

19:09 <phr3ak> usually that is about 20sec

19:09 <phr3ak> it was so fast

19:10 <phr3ak> openocd did not accept connection from gdb

19:12 <PaulFertser> I suggest you try "halt" in openocd first.

19:13 <phr3ak> [gd32e23x.cpu] halted due to debug-request, current mode: Thread

19:13 <phr3ak> Error: [gd32e23x.cpu] clearing lockup after double fault

19:13 <phr3ak> Info : [gd32e23x.cpu] external reset detected

19:13 <phr3ak> xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc

19:14 <PaulFertser> And then? Looks like blank flash with hw watchdog enabled if it keeps resetting from that state.

19:15 <phr3ak> these messages were repeated very quickly

19:16 <PaulFertser> OK, so how are you checking that watchdog is not enabled?

19:16 <phr3ak> when you said halt in openocd, where should it be done in the init script?

19:18 <PaulFertser> phr3ak: I'd just do it over telnet connection.

19:18 <phr3ak> ah I forgot that interface