15:27 <kraiskil> I'm having problems stepping through my code with openocd. The target is STM32F4, project uses libopencm3.

15:28 <kraiskil> When stepping through the code, it behaves oddly. Like jumping through functions and code like it was compiled with optimizations on

15:28 <kraiskil> but I checked that I am using "-O0 -g" flags for gcc.

15:30 <kraiskil> I have a STM nucleo F411 board where things work nicely, but now with this other STM32F407 based board and a ST-Link 2, it doesn't.

15:30 <karlp> did you compile the library with taht too?

15:30 <kraiskil> Yup. Tried that too

15:30 <kraiskil> same compiler to compile libopencm3 and my project

15:31 <kraiskil> not sure about the optimization flags for libopencm3 compilation, though. But those should not matter. Right? :)

15:31 <kraiskil> I just updated to openocd 0.12.0 release, but no change.

15:33 <kraiskil> The F407 board is something bought off an Alibaba-style vendor (I forget which), but the chip does look genuine...

15:44 <bencoh> did you try using an external jtag adapter?

15:45 <kraiskil> Yeah, the F407 board has none, so I'm using my trusty, well tested ST-Link2

15:46 <kraiskil> now I'm stepping through the assembly, and that looks like it is behaving correctly... So it feels it is more a problem of linking the source code lines with the binary

15:49 <kraiskil> Hmm.. or maybe not. Shouldn't "nexti" command in gdb step over the ARM function call with "bl" instructions?

15:49 <kraiskil> s/ARM/Thumb/

16:23 <kraiskil> Tried now to compile (both libopencm3 and my project) with gcc11, no improvement

16:23 <kraiskil> Though with the gcc11 provided by ARM, I can't use the bundled gdb. That fails to load libpython-3.6.0 :)

16:24 <kraiskil> So I am using the unpythohified gdb from the ARM gcc8 package.

16:25 <kraiskil> Maybe times have reverted, and one is supposed to compile the compiler toolchains from source again. Like it's 1999 :D

16:28 <kraiskil> ... and maybe this is not an openocd problem at all ...

16:35 <kraiskil> can I read the target stm32 chip info with openocd? Like core type, memory (RAM,flash) size, etc.?

16:46 <kraiskil> Hmm.. commenting out the RCC initialization "rcc_clock_setup_pll(&rcc_hsi_configs[RCC_CLOCK_3V3_84MHZ]);" - now it behaves deterministically...

16:47 <kraiskil> I just don't know what the clocks are configured to, but maybe this is an libopencm3 problem after all :)

16:52 <kraiskil> ...and rebasing my libopencm3 on top of latest master, and the rcc_clock_setup_pll() works too... :D

16:53 <kraiskil> thanks for everyone who read this spew of thoughts :)

20:58 <karlp> you're.... welcome? :)

21:24 <kilobyte_ch> Hello, I have a nRF5340 part. Any idea if it is possible to program/debug this part with openocd? It looks like it isn't supported yet.

21:25 <kilobyte_ch> Not really sure why it isn't supported yet, as this MCU is on the market since multiple years.

21:48 <PaulFertser> kilobyte_ch: hi

21:48 <PaulFertser> kilobyte_ch: if it has a supported core then it can be debugged. For flashing you'd need a flash driver that understand how to deal with that part's peripheral.

21:49 <PaulFertser> kilobyte_ch: cortex-m33 core should work with the current version, yes.

21:52 <kilobyte_ch> PaulFertser: Ok, thanks. Didn't know this difference.

21:55 <PaulFertser> kilobyte_ch: or you can probably flash by other means, e.g. via bootloader.

21:55 <PaulFertser> But debugging should work, no special support seems to be needed for this part.

21:59 <PaulFertser> kilobyte_ch: I know nrf51 and nrf52 SDK assumed one is using "softdevice" for wireless functionality, and that essentially made debugging by regular means impossible because you can't halt it at any point it happens to run. Nordic was suggesting to use JLink's custom method of getting data from the target to the debugger, called J-Link RTT. OpenOCD supports it with any adapter, not just J-Link.

22:01 <PaulFertser> For this new part it looks like "real time debug" is possible though, so it's much nicer in this regard: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fstruct_nrf53%2Fstruct%2Fnrf5340.html

22:02 <kilobyte_ch> It might be easier with nrf53 as all the wireless functionality should be running on the second core.

22:02 <PaulFertser> That too

22:02 <kilobyte_ch> btw, with the change from their "old" sdk to zephyr/nrf connect sdk the whole softdevice thing is gone :) It is now a kind of library within zephyr.

22:03 <kilobyte_ch> But I remember the softdevice hassle with the "old" sdk..