nerozero has quit [Remote host closed the connection]
nerozero has joined #openocd
rigid has quit [Read error: Connection reset by peer]
rigid has joined #openocd
rigid has quit [Changing host]
rigid has joined #openocd
Haohmaru has joined #openocd
cambrian_invader has quit [Ping timeout: 252 seconds]
cambrian_invader has joined #openocd
muli has joined #openocd
<muli>
Hi, 1st here for me. I'm trying to flash an STM32L151 with a Raspi5 via linuxgpiod. I got it working with the JLink-Debugger where I'm erasing the flash via GDB. No I'm trying the same via the GPIOs but I got the following error from "startup.tcl":
<muli>
(gdb) monitor reset halt
<muli>
Translation from khz to adapter speed not implemented
<muli>
Error executing event reset-start on target stm32l1.cpu:
<muli>
embedded:startup.tcl:1193: Error:
<muli>
in procedure 'ocd_process_reset'
<muli>
in procedure 'ocd_process_reset_inner' called at file "embedded:startup.tcl", line 1193
<muli>
[stm32l1.cpu] halted due to debug-request, current mode: Thread
<muli>
As far as I see "startup.tcl" is part of the OpenOCD binary and there are several files called "startup.tcl" but they are shorter than 1000 lines. How do I know where to look for the error. Grep gives me the following (from the source code):
<karlp>
muli: what version of openocd, and with what target/board config please?
<karlp>
what does openocd say when it connects, before you get gdb involved?
<karlp>
with gdb, you should be able to just use "load" without needing any manual reset halt steps.
<PaulFertser>
Hm, looks like a regression, linuxgpiod can't set frequency and so reset halt fails.
<PaulFertser>
muli: I suggest you comment out all "adapter speed" commands from target/stm32l1.cfg and retry.
Haohmaru has quit [Quit: saionara]
<muli>
Version is 0.12.0, The target config is the following: https://pastebin.com/c6B1bee8 it's nearly identical to the stm32l1.cfg but I added the 2nd bank (I know there's stm32l1x_dual_bank.cfg but I made a copy of the configuration to not mess with the original).
<PaulFertser>
muli: I suspect there's some regression with adapters that can't set speed
<muli>
Ok, I commented out all "adapter speed" comments. Got to plug things back in and see …
<muli>
The error is gone and it looks like the reset is working now.
<muli>
Thank you.
<muli>
Now I got to figure out how to unlock and erase flash memory. The obvious gdb-commands are failing.
<muli>
Do you think in general it's a good idea to try this with the GPIOs of the Pi5 or is it a deal breaker to not be able to set the adapter speed and I should stick to some kind of programming adapter?
<karlp>
what gdb commands are you using, and how are they failing?
<karlp>
also, this is breakage, we should get it fixed.
<muli>
For unlocking bank 1 I tried:
<muli>
(gdb) monitor stm32lx unlock 1
<muli>
SWD DPIDR 0x2ba01477
<muli>
Failed to read memory at 0x1ff80008
<muli>
STM32Lx unlock failed
<muli>
Protocol error with Rcmd
<muli>
To erase bank 1 I tried to methods:
<muli>
(gdb) monitor stm32lx unlock 1
<muli>
SWD DPIDR 0x2ba01477
<muli>
Failed to read memory at 0x1ff80008
<muli>
STM32Lx unlock failed
<muli>
Protocol error with Rcmd
<muli>
and
<muli>
(gdb) monitor stm32lx mass_erase 1
<muli>
[stm32l1.cpu] target was in unknown state when halt was requested
<muli>
SWD DPIDR 0x2ba01477
<muli>
[stm32l1.cpu] clearing lockup after double fault
<muli>
[stm32l1.cpu] external reset detected
<muli>
[stm32l1.cpu] halted due to debug-request, current mode: Handler HardFault