NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
borneoa___ has quit [Quit: Connection closed for inactivity]
Hawk777 has quit [Quit: Leaving.]
indy- has quit [Ping timeout: 260 seconds]
nerozero has joined #openocd
Hawk777 has joined #openocd
borneoa___ has joined #openocd
crabbedhaloablut has joined #openocd
Hawk777 has quit [Quit: Leaving.]
Foxyloxy_ has quit [Ping timeout: 260 seconds]
Foxyloxy has joined #openocd
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
Foxyloxy has joined #openocd
shoragan[m] has quit [Remote host closed the connection]
Jybz[m] has quit [Read error: Connection reset by peer]
LinuxHackerman has quit [Write error: Connection reset by peer]
borneoa___ has quit [Quit: Connection closed for inactivity]
borneoa___ has joined #openocd
<phr3ak> I'm trying to connect to a running STM32F031. cannot read IDR. can it be readout protection or rather a communication problem?
<phr3ak> I tried with and without connected Vref
<phr3ak> although I think this is not necessary since it is a 3V system and I think this is the default for ulink2
<PaulFertser> phr3ak: proper debug adapters always need vref
<PaulFertser> phr3ak: if you can read IDR while holding the target in reset externally that means it's somehow disabling SWD, probably by remapping pins.
<phr3ak> it worked without Vref for other boards...
<phr3ak> yes, the alternate function for pins... this would have been my second idea as well.
Deneb has joined #openocd
Deneb has quit [Remote host closed the connection]
<phr3ak> the pins are not used for anything else, so I think they just want to screw me
<phr3ak> so do you think the IDR can still be read even with active readout protection?
<phr3ak> I'll try to find the reset, but I'm afraid it's not easily accessible
<PaulFertser> I'm not sure about F03 specifically, you need to check the datasheet.
<phr3ak> if i issue reset command in cli should be the reset pin active from ulink2?
<phr3ak> anyways, i held reset active manually and i could not read data
<PaulFertser> Can you show all output from OpenOCD?
<phr3ak> nothing special, "cannot read IDR". i tried to connect mcu reset line to RESET pin on JTAG header. but it does not reset the board. this is why i'm asking should the reset line change on ULINK2 in SWD mode in case of reset command in cli?
<phr3ak> it is a working setup I used it for SAM3
<PaulFertser> phr3ak: yes, and you should be able to see it in -d3, it says SRST asserted etc. Of course you need to use "reset_config srst_only" for the reset line to be used.
<phr3ak> thanks i'm checking
<phr3ak> > reset_config
<phr3ak> > reset_config srst_only
<phr3ak> none separate
<phr3ak> srst_only separate srst_nogate srst_open_drain connect_deassert_srst
<phr3ak> is it ok or more than needed? I don't know why the other options were activated
<phr3ak> target resetting is ok now. cannot read...
<phr3ak> maybe it is because the protection
<phr3ak> the doc was not straightforward for me
<phr3ak> let me copy that one sentence
<phr3ak> Level 2: chip readout protection, debug features (Cortex®-M0 serial wire) and
<phr3ak> boot in RAM selection disabled
<PaulFertser> Probably this level was activated.
<PaulFertser> Then SWD wouldn't be available.
nerozero has quit [Ping timeout: 260 seconds]
<phr3ak> have you tried this SWD exploitation? it's cool.
crabbedhaloablut has quit []
borneoa___ has quit [Quit: Connection closed for inactivity]