<re_irc>
<@mrbraindump:matrix.org> Hello my dear rust embedded developers. I try to turn on the built-in LED on an FRDM KL25Z board. I use the crate 'mkl25z4'. But it seems like every time I try to actually try to read or write to a register, the program just steps over it. For debugging I use openocd and gdb with 'cargo run'. Here is my...
<re_irc>
<@mrbraindump:matrix.org> Is this a syntax problem (aka I am just too stupid for Rust)
<re_irc>
<@mrbraindump:matrix.org> Or is this rather a problem of my debugger (aka the code seems to check out)?
<re_irc>
<@mrbraindump:matrix.org> Thank you in advance!
<re_irc>
<@adamgreig:matrix.org> mrbraindump: do the semihosting prints work, i.e. do you see them in the gdb output?
<re_irc>
<@adamgreig:matrix.org> I don't know anything about KL25Z, but the code looks more or less OK... at the end I noticed you set pin 13 as input, but you check pin 12's state
<re_irc>
<@adamgreig:matrix.org> on line 77 maybe replace `0x00001000` with `1<<13`?
<re_irc>
<@adamgreig:matrix.org> (I guess that's what you meant it to be anyway)
<re_irc>
<@adamgreig:matrix.org> debugging by single-stepping is often tricky, especially if you are building in release mode (`--release`) as optimisations can make it very confusing, you could try without release mode and see if that helps
<re_irc>
<@adamgreig:matrix.org> (also, maybe you need to enable or configure some clocks for this chip? I don't know about it)
<re_irc>
<@mrbraindump:matrix.org> Thank you very much for the hints, I will try them out!
<re_irc>
<@mrbraindump:matrix.org> adamgreig: yes i can see the semihosting-prints, that works fine.
<re_irc>
<@mrbraindump:matrix.org> adamgreig: ah i can only see them in the openOCD terminal, not in the gdb session.
<re_irc>
<@adamgreig:matrix.org> oh, sorry, that's fine too
<re_irc>
<@adamgreig:matrix.org> just checking they were showing up at all
<re_irc>
<@adamgreig:matrix.org> it could be that it looks like it's stepping over each write because they are optimised into a single memory write, there's no function call left in the final executable, but the write should still take place
<re_irc>
<@adamgreig:matrix.org> you could check in gdb by reading the register value yourself afterwards, e.g. `p *(0x40020000 as *const u32)` or similar (replacing that address with the actual full address of the register)
<re_irc>
<@mrbraindump:matrix.org> adamgreig: I had a breakpoint at the entry and the messages show up till the first call of a mkl25z4 call in line 38, fter that they stop, could that be optimization too?
<re_irc>
<@adamgreig:matrix.org> so you never see "PCR A13 value" from L39 get printed?
<re_irc>
<@adamgreig:matrix.org> but you do get "WTF" from L36?
<re_irc>
<@mrbraindump:matrix.org> I get the "WTF" from L36, but not "PCR A13 value" from L39
<re_irc>
<@adamgreig:matrix.org> that's odd. if you interrupt in gdb (ctrl-c), what's executing? e.g. `backtrace` or `where` in gdb
<re_irc>
<@adamgreig:matrix.org> maybe it's gone into a panic handler
<re_irc>
<@mrbraindump:matrix.org> It seems to just ignore it. But maybe the error is somewhere else:
<re_irc>
<@mrbraindump:matrix.org> I tried to read the PCR-Register I tried to set and it just says `Info : SWD DPIDR 0x0bc11477
<re_irc>
<@mrbraindump:matrix.org> Error: Failed to read memory at 0x40049034` So I can't even read the value from there
<re_irc>
<@adamgreig:matrix.org> try `set mem inaccessible-by-default off` in gdb too, but sounds like something else could be wrong too
<re_irc>
<@adamgreig:matrix.org> there might well be some configuration you need to set first, like enabling clocks or disabling a watchdog or whatever, that will be in the chip's user manual/datasheet
<re_irc>
<@adamgreig:matrix.org> if GDB can't read that memory address and gets an error, it's quite possible the chip also cannot read it and is faulting when it tries