K900 has quit [Quit: Idle timeout reached: 172800s]
purdeaandrei[m] has joined #glasgow
<purdeaandrei[m]>
where should I look for any potential teardown actions performed by glasgow? I am seeing something weird:
<purdeaandrei[m]>
I'm trying to implement an emergency erase jtag sequence on mec16xx
<purdeaandrei[m]>
1) if I do a certain sequence of steps, then I return from interact(), then I power cycle, I can see my erase was successful
<purdeaandrei[m]>
2) If I put an infinite loop before that return, and I power cycle, then kill glasgow, then the erase is NOT successful
<purdeaandrei[m]>
3) If I put an infinite loop before that return, and I hit the emergency stop button on the glasgow, then I power cycle my taget, then erase is still NOT successful
<purdeaandrei[m]>
I hacked JTAGProbeInterface in the case of 1) to print everything with logging.INFO level, but after the return nothing is printed
<purdeaandrei[m]>
So in short there must be an extra action that allows the erase to complete, but I have no idea where it is and what it is 🙂
<purdeaandrei[m]>
4) If I ctrl-c that infinite loop before power cycle, then erase completes successfully
<purdeaandrei[m]>
5) if I ctrl-\ that infinite loop before power cycle, then erase fails
<purdeaandrei[m]>
must be something within a finally block or something like that
<Wanda[cis]>
huh.
<Wanda[cis]>
could be something more obscure like some destructor within libusb
<purdeaandrei[m]>
you mean like something registered by atexit()?
<Wanda[cis]>
that, or something called from a Python object destructor
<purdeaandrei[m]>
it's not in atexit() (if I put the infinite loop at the end of _main()'s finally, then it succeeds)
<purdeaandrei[m]>
it's not device.close() which is called in _main()'s finally, because if I put the infinite loop before it, it still succeeds
<galibert[m]>
I've noticed recently that infinite loops are hard in C/C++
benny2366[m] has joined #glasgow
<benny2366[m]>
while(true){
<benny2366[m]>
}
<benny2366[m]>
i mean ok that was hard XP
<galibert[m]>
And what do you think this compiles to with say clang? Not at all what you expect
<Wanda[cis]>
good thing this is a C-specific problem and doesn't affect other languages, such as Rust
<Wanda[cis]>
oh wait.
<benny2366[m]>
never used rust tbh
<galibert[m]>
In my case it was jumping in the next method iirc
<purdeaandrei[m]>
compiler bug?
<Wanda[cis]>
no.
<Wanda[cis]>
it just happens to be UB according to C standard.
<galibert[m]>
Nope, infinite loops are UB
<Wanda[cis]>
and compilers happily exploit it
<Wanda[cis]>
and "infinite loops are considered UB" was deeply ingrained into LLVM because of clang, affecting Rust as well
<Wanda[cis]>
it was a longstanding bug that took ages to fix
<Wanda[cis]>
(and probably other languages with LLVM-based compilers too)
<galibert[m]>
Had to do a while(v); where v was a extern volatile bool set in a different translation unit (and I'm not using lto)
<purdeaandrei[m]>
any best place where I can read up on this?
<purdeaandrei[m]>
@galibert: does a: goto a; behave the same?
<purdeaandrei[m]>
@Wanda so then the explanation would be that my last `await self.lower.lower.write_dr()` command wasn't really sent to the gasgow because it didn't return anything, right?
<Wanda[cis]>
mhm
<Wanda[cis]>
it was just queued up in som ebuffer
<Wanda[cis]>
s/som/some/, s/ebuffer/buffer/
<purdeaandrei[m]>
what's the right thing to call in the mec16xx program applet?
<altracer[m]>
The small pinout could be figured out by staring at two-sided PCB traces long enough, or with a DMM in continuity mode -- there's no buffers or other shenanigans
<Wanda[cis]>
hmmm. fair enough
<Wanda[cis]>
I think we may want to add a flush() to TAPInterface, making it one fewer .lower
<altracer[m]>
TP5 looks like it may be either VTref or ground; the others are a combination of Cortex-M SWD standard wires of SWDIO, SWCLK, Reset, Gnd/Vtref. I don't think a mouse would get full JTAG or at least SWO trace capture pin.
<Wanda[cis]>
I have some of my own additions to that class queued up, too
<purdeaandrei[m]>
I already started making that change, but do you prefer I don't make it, so we don't end up with merge conflicts?
<Wanda[cis]>
nah, do it
<Wanda[cis]>
just make it its own PR
<Wanda[cis]>
mine will take a while
<purdeaandrei[m]>
@Cathrine do you remember which exact MEC16xx the applet was originally tested with? I'm curious if I can reproduce the problem that caused the need for the non-burst `read_flash()` code. With the mec1633 I have not seen a single warning notifying me of a read glitch so far. (I did see that warning printed, but only in REPL mode when I forgot to call `enable_flash_access()`
<purdeaandrei[m]>
On another note I don't thing emergency erase ever really worked correctly in the past, on the different MEC either. It looks like the documentation is contradicting itself when it comes to the polarity of the VTR_POR bit. The mass erase sequence describes it wrong, while the register description is correct. And the contradiction seems to be the same way with other MEC datasheets to (e.g. MEC1609i).
hackwithanders[m has joined #glasgow
<hackwithanders[m>
hello guys
<hackwithanders[m>
i am a hacking expert and i can teach hacking real hacking for you with a much lower price than the online courses, plus practice and supprt and i will guide you through all your road to ethical hacking journey thank you.
hackwithanders[m has left #glasgow [#glasgow]
TriCento has joined #glasgow
jstein has joined #glasgow
redstarcomrade has joined #glasgow
TriCento has quit [Ping timeout: 256 seconds]
redstarcomrade has quit [Read error: Connection reset by peer]
TriCento has joined #glasgow
TriCento has quit [Client Quit]
FFY00_ has quit [Read error: Connection reset by peer]
cr1901_ is now known as cr1901
bvernoux has quit [Read error: Connection reset by peer]
<whitequark[cis]>
<purdeaandrei[m]> "@Cathrine do you remember..." <- hell if i know. it was so long ago
<whitequark[cis]>
do the commit messages not spill any information about it? or the docs imported into the archive?