NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
tsal has quit [Ping timeout: 268 seconds]
tsal has joined #openocd
thinkfat has quit [Ping timeout: 248 seconds]
thinkfat has joined #openocd
defiant has joined #openocd
nerozero has joined #openocd
kraiskil has joined #openocd
kraiskil has quit [Ping timeout: 268 seconds]
Haohmaru has joined #openocd
indy has quit [Quit: ZNC 1.8.2 - https://znc.in]
indy has joined #openocd
<braunr> hello
<braunr> i get a lot of "Cortex-M PARTNO 0xfff is unrecognized" when i start openocd
<braunr> (working with an stm32f7 but i don't think that matters much)
<PaulFertser> braunr: hi. Is this a regression?
<braunr> no
<braunr> it's always been there
<braunr> it seems completely random
<braunr> and once i get it to work, i leave it on for the day
<braunr> but until i get it to work, it takes a few attempts
<braunr> about 10 today, which is why i'm asking
<braunr> vdd is 1.8V, maybe that counts
<PaulFertser> Is that reproducible with -d3 ? I suggest you pastebin a log with that.
<PaulFertser> What debug adapter are you using?
<braunr> jlink pro
<braunr> it could be related to the rcc configuration
<braunr> i do'nt see HSION anyway
<braunr> anywhere*
<PaulFertser> braunr: the issue happens before OpenOCD tries to affect target's state anyhow, so RCC shouldn't be related.
<PaulFertser> braunr: the log looks like it all works until it suddenly reads this odd value
<braunr> my attempts seem to work better if i connect soon after power up
<PaulFertser> braunr: are you sure the power supply is steady and there's enough appropriate capacitors etc?
<braunr> yes
<PaulFertser> braunr: ok, what do you get if you connect reset line too and use "reset_config connect_assert_srst"?
<braunr> that's much better
<braunr> yep, always succeeds
<braunr> on 5 attempts but that's much better than anything i had until now
<PaulFertser> So it's your target's firmware doing something fancy like entering sleep or something.
<braunr> our clock configuration, once everything has booted, is hse and pll on, hsi off
<braunr> hm
<braunr> it mostly sleeps with wfi for now
<PaulFertser> So OpenOCD has issues connecting, no wonder.
<braunr> ah
<braunr> wait let me check, i think we only use wfi in release mode for that kind of reason
<braunr> ah, my mistake, wfi is indeed enabled
<braunr> PaulFertser: yes, that solved it, thanks :)
<PaulFertser> braunr: :)
<PaulFertser> braunr: I personally was always using release versions with full optimisations enabled and connect_assert_srst.
<PaulFertser> braunr: once OpenOCD connects, it runs a mww command to enable full debug in sleep modes anyway.
<PaulFertser> Having a separate debug versions means you just have more uncertainty and subtle bugs due to differences.
<braunr> i agree
<braunr> but we sometimes want to attach without resetting
<PaulFertser> GDB output is sometimes a bit confusing with -O2/-Os but I got used to it.
<braunr> i personally oversee projects to make sure there are as few differences between our debug and release modes
<braunr> i use -Og currently
<braunr> it's fine for our needs
<PaulFertser> Attaching without resetting is still possible, just you have to run openocd in a loop so it tries until it manages :)
<PaulFertser> If -Og is fine for your _release_ builds then it makes sense, agreed.
<braunr> no it's for our debug builds only
<PaulFertser> Then I would not recommend it. Because different optimisations make different bugs surface.
<braunr> i agree
<braunr> but most people can't deal with reading O2/O3 assembly
<braunr> using gdb is already difficult for some
<PaulFertser> -O2/3 doesn't inhibit source level debug, no assembly is involved unless you want to peek inside
<braunr> so this is a debug/release difference i'm willing to keep in mind
<braunr> oh it makes a lot of things <optimized out>
<PaulFertser> Yes, that's the part one can get used to.
<braunr> and on our older arm processors, pc doesn't always refer to the faulty instruction
<braunr> that has got some people very suspicious about the reliability of the debugger
<braunr> (agreed, Og doesn't help with that either)
<braunr> i think it's a good thing that we build with different optimization levels actually
<braunr> precisely because it helps expose different bugs
<braunr> and the fact that it almost never happens is a kind of confirmation that the way we write code is pretty good
<braunr> (and when it does, it's the kind of thing i just asked about, so pretty minor)
<PaulFertser> Good to hear it works for you.
<braunr> for now
<braunr> with a team of only very experienced people, i guess i'd do the same as you
<PaulFertser> Yes, for me MCU firmware was a one-man show, so that makes a difference indeed.
gnom has quit [Ping timeout: 265 seconds]
gnom has joined #openocd
wingsorc__ has quit [Ping timeout: 246 seconds]
indy has quit [Ping timeout: 264 seconds]
indy has joined #openocd
kraiskil has joined #openocd
kraiskil has quit [Ping timeout: 268 seconds]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
Haohmaru has quit []
wingsorc has quit [Quit: Leaving]
kraiskil has joined #openocd
nerozero has quit [Ping timeout: 246 seconds]
kraiskil has quit [Ping timeout: 246 seconds]
zjason` has joined #openocd
zjason has quit [Ping timeout: 246 seconds]
josuah has quit [Quit: WeeChat 3.4.1]
josuah has joined #openocd
wingsorc__ has joined #openocd