<Giedrius>
it requires a cold plug reset sequence, and writing 2 registers via SWD
<Giedrius>
but it looks like during 'init' phase, openocd is trying to read various registers to identify the chip (which is impossible as it is locked), and fails to execute the required commands to chip erase tit
<Giedrius>
is there any way to skip the examination phase?
<PaulFertser>
Giedrius: hi
<PaulFertser>
Giedrius: probably replicating that requires using that old version :/
<Giedrius>
I did build one based on a random commit from 2017
<Giedrius>
any way to tie this to a commit id?
<Giedrius>
Open On-Chip Debugger 0.10.0+dev-00167-g29cfe9c (2017-07-10-13:29)
<PaulFertser>
29cfe9c
<Giedrius>
ok, I'll try this particular version
<Haohmaru>
Giedrius, i was doing pretty much exactly the same thing, don't remember if it was on SAMD20 or SAME54, and iirc i had to use an openocd version from that time
<Haohmaru>
and i'm not too sure if it fully worked
<PaulFertser>
There was a recent discussion on the topic, I'm trying to find what it ended up with.
<Haohmaru>
i think i also i tried to butcher "current" openocd to make it work but i failed
<Giedrius>
me too :D
<PaulFertser>
Haohmaru: ah it was with you indeed. Please help the fella :)
<Haohmaru>
perhaps a different program is needed for this, but i am no fan of $vendor java crap
<Haohmaru>
well, how?
<PaulFertser>
Haohmaru: tell what version you used, what additional patch you had and what command you run to make it work.
<Haohmaru>
iirc i spent a few days on butchering openocd and it wasn't getting anywhere and i think someone here told me to give up
<Haohmaru>
i don't remember
<PaulFertser>
No way, I have logs.
<Haohmaru>
if you have - ctrl+f for "cold-reset"
<PaulFertser>
12:55 < Haohmaru> ooh, i think it might have gotten erased now
<PaulFertser>
13:00 < Haohmaru> muchos thanks PaulFertser
<PaulFertser>
No butchering should have been invoved.
<Haohmaru>
well, my memory is foggy, but i seem to remember butchering
<Haohmaru>
might have been only on the "current" openocd version
<PaulFertser>
14:18 < Haohmaru> the worked out steps were to... use an older version of openocd (which doesn't have same5x support) and fool it that i'm using samd2x and then (with the cold_plug modification) manually poke the two registers needed for chip-erase
<Haohmaru>
^ wonderful
<Haohmaru>
basically, i gave up on it and i do not want to use that as a feature untill i have a tool that can do it
<PaulFertser>
Giedrius: I really hope you can first reproduce the success with old version, then properly read the -d3 log to compare with the current, find the difference and prepare a nice fix for upstream.
<Haohmaru>
before that i really tried to make "current" openocd do it, but i failed
<PaulFertser>
12:29 < PaulFertser> Haohmaru: yeah, you can manually mww to 0x40000000 this value, (1<<16) | (1<<5) | (1<<1), then to 0x41002100 (1<<4)
<PaulFertser>
12:29 < PaulFertser> Haohmaru: the last should be "mwb", not w
<Haohmaru>
i even littered openocd with debug printf() sh*t
<Haohmaru>
literally started butchering it towards the end
<Haohmaru>
so basically, some of the features of SAMD2x and SAME5x aren't usable via openocd at the moment
<PaulFertser>
It's /unfortunate/ you didn't manage to offer the fix upstream.
<Haohmaru>
who, me?
<PaulFertser>
Why not you? I do not have those atmel targets on my desk.
<Giedrius>
I suspect a proper fix would take some tectonic changes though, unless I am not seeing the big picture right of how openocd works
<Haohmaru>
well i just explained that i could _not_ get "current" openocd do it, no matter how much i butchered it
<Haohmaru>
and i think someone here told me to give up
<PaulFertser>
Giedrius: -d3 log would show
<Haohmaru>
iirc the way openocd worked then, and the way it works now has changed
<Giedrius>
if I'm understanding this right, the atsamd chip erase didn't work at all when the chip is already in the locked state
<Giedrius>
without the manual cold plug reset hacks
<PaulFertser>
Giedrius: right
<PaulFertser>
Giedrius: or the non-manual cmsis-dap specific hack from that patch
<Haohmaru>
what if i send you a board with SAMD21? ;P~
<Giedrius>
making it work with current openocd would require it to not interact with the chip, only to toggle rst and swclk pins in a particular way and write the 2 registers
<PaulFertser>
With cmsis-dap/daplink adapter? I'll make cold plug work with the current version then.
<Giedrius>
making it work with current openocd would require it to not interact with the chip, only to toggle rst and swclk pins in a particular way and write the 2 registers, with no error checking
<Giedrius>
in my usecase, I'm using raspberry pi's GPIOs to do the programming, it works quite well
<PaulFertser>
Giedrius: I'm not so sure, that register write was going through normal machinery. Really need -d3 log of an old version where it worked to compare.
<PaulFertser>
Giedrius: aha, then you can also manually do the right sequence by bitbanging GPIOs.
<Giedrius>
yes, resetting the device in a particular way is not a problem, bitbanging it correctly would require me to learn the swd and arm debugging protocols
<Giedrius>
I hoped I could make use of some of the interfaces in openocd to perform this work in a standalone app, but it seemed difficult to reuse, a lot of stuff is connected together through tcl only
<Haohmaru>
and on the 17th 08:25 <PaulFertser> Haohmaru: just reproducing won't help much anyway, don't bother.
<PaulFertser>
Giedrius: but you only need to bitbang the coldplug sequence, then start OpenOCD and it should be able to talk to the target somehow, probably you need to add ignore for few errors during examination.
<PaulFertser>
Haohmaru: right, I discouraged you from not aiming at properly digging and providing a patch upstream.
<Giedrius>
yes, I suspect the examination phase is what keeps it from chip erasing it, as it is interacting with the device, and failing
<Giedrius>
if it was possible to force openocd to assume a particular chip model, it would probably work
<PaulFertser>
Giedrius: examination isn't really about a chip model
<PaulFertser>
Giedrius: -d3 log shows everything.
<Giedrius>
ok, I'm still building the old version, the newer compiler is picky :)
<PaulFertser>
If the version that is known to work isn't working then probably the cold connect bitbanging isn't right. Or a glitch happens when openocd takes over.
<PaulFertser>
--disable-werror
<Giedrius>
thank you for the flag :)
<Giedrius>
btw, what does the examination do? I tried to look it up in the docs, but didn't find much mentions about it
<Haohmaru>
maybe an ugly possibility could be.. if you get an old version of openocd to "do it" even if you just use a very specific .sh script to toss the exact CLI arguments and blahblah, then you could put that openocd into an .AppImage and set it in stone
<Haohmaru>
that should work for supposedly a number of linuxes, hopefully
<PaulFertser>
Giedrius: it detects the version and capabilities of flash breakpoint unit and other debug hardware basically.
<PaulFertser>
Haohmaru: that is what I tried to discourage you from, yes. You have source code, you have datasheets, you have debugger. Everything needed to do the right thing and avoid ugly hacks.
<Giedrius>
would it be possible to tell all these parameters to openocd from tcl for cases where the chip is locked?
<Haohmaru>
PaulFertser, you expected me to make a proper modification of openocd?
<Haohmaru>
how could i possibly do that when i understand _zero_ of openocd and the related stuff?
<Haohmaru>
_____zero______
<Haohmaru>
i just wanted to unbrick the chip, and then if possible figure out a way to make this feature usable (the Security Bit thing)
<Haohmaru>
well, the conclusion is to not use the Security Bit when you don't have a tool that can turn it off afterwards
<PaulFertser>
Giedrius: probably but that's not implemented and unlikely to be the best solution
<PaulFertser>
Haohmaru: OpenOCD is a straightforward C code project.
<PaulFertser>
Haohmaru: so are you sending me cmsis-dap and board?
<Haohmaru>
i hate C
<PaulFertser>
I do not fancy C much either.
<Haohmaru>
i have 2 board revisions of my "samd21_daplink" and i think i might have bought 3 chips for them, the first revision is fully populated, but due to some wrong thing (i forgot what) it is not usable as what was intended, the new revision isn't populated yet
<Haohmaru>
i could send you the fully populated first revision, it has a SAMD21 and a bunch of LEDs and stuff
<Haohmaru>
plus my excelent soldering with RoHS solderwire
<PaulFertser>
Only SWD + reset is needed to debug this cold plug procedure I think.
<Haohmaru>
SAMD/SAME _require_ the RESET pin to be wired to the SWD port
<PaulFertser>
And having /known to be working/ daplink adapter might be essential.
<Haohmaru>
i mean, the datasheets require you to wire it up
<PaulFertser>
You can also find a lot on aliexpress and paypal me, I'll order myself.
<Haohmaru>
PaulFertser, this is probably the 2nd revision, but the actual SAMD21 on the old revision is wired up properly, you can program it, firmware runs, it can blink LEDs: https://antonsavov.net/tmp/samd21_daplink.pdf
<Haohmaru>
"Host SWD" (in the center) is the debug connector for the SAMD21
<Haohmaru>
normal 1.27mm-pitch 2x5 SWD connector
<Haohmaru>
the "mistake" iirc had to do with the 3 SPIs, signal mixup, it doesn't matter if you don't try to use them as SPIs
<Haohmaru>
i think even the USB worked
<Haohmaru>
aliexpress is not somewhere i go
<Haohmaru>
the components for this board were bought from comet.bg and farnell
<Haohmaru>
aliexpress to me sounds like a more eastern version of ebay
<Haohmaru>
i was thinking to unsolder most of it and transfer it to the new board, but somehow i lost interest, and i could just send it to you if you want
<Haohmaru>
they made it load the whole website instead of loading the picture alone
<PaulFertser>
"If you're seeing this message, that means JavaScript has been disabled on your browser, please enable JS to make Imgur work. "
<PaulFertser>
Please erase your memories about Imgur ever existing, they decided to part their ways with IRC people so be it.
<Haohmaru>
cool so what do i use now?
<Haohmaru>
img'r'us
<PaulFertser>
img.bb
<PaulFertser>
Eh
<PaulFertser>
ibb.co
<Haohmaru>
i wonder if my website works without java
<Haohmaru>
../javascript/whatever
<PaulFertser>
Yeah it works and looks good.
<Haohmaru>
it involved butchering a hugo theme
Giedrius has quit [Ping timeout: 256 seconds]
Giedrius has joined #openocd
Giedrius has quit [Ping timeout: 256 seconds]
Giedrius has joined #openocd
Giedrius has quit [Ping timeout: 256 seconds]
Giedrius has joined #openocd
<Giedrius>
I did not yet manage to make chip erase work, including using the old version of openocd (my environment can be different - I'm using Pi 5 which has no bcm2835 support for one)
<Haohmaru>
oh, i used a daplink
<Giedrius>
I hooked up a logic analyzer to the swd and rst pins so I can see what's happening and what I notice is when it's attempting to write the first 32 bit register, it gets an "ACK_FAULT" and even though the samd_handle_chip_erase intends to ignore the error, the 2nd register write is not attempted at all, due to the ACK_FAULT error being queued in
<Giedrius>
queued_retval in bitbang.c
<Giedrius>
any idea how to "sync up" the swd in between the register writes, so the 2nd register write is at least attempted?
<Giedrius>
the ACK_FAULT is probably expected at that point
<Haohmaru>
iirc the procedure involved doing a SWD thing that involved a fault that is supposed to be ignored
<Haohmaru>
but my memory is very blurry
<Haohmaru>
i remember "result -4" ;P~
<Giedrius>
the weird thing is that this delays the return error code by 1 operation
<Giedrius>
when using the bitbang driver, the line "res = target_write_u8(target, SAMD_DSU + SAMD_DSU_CTRL_EXT, (1<<4));" receives the error code of the previous u32 write
<Giedrius>
and the u8 write is not even attempted
<Giedrius>
SAMD_PAC1 is 0x41000000 and SAMD_DSU + SAMD_DSU_CTRL_EXT is 0x41002100
<Giedrius>
the debug output is:
<Giedrius>
Error: 1033 20 arm_adi_v5.c:381 mem_ap_write(): Failed to write memory at 0x41000000
<PaulFertser>
Giedrius: and what you say matches what Haohmaru had back then afaict now. Because manual mww then mwb worked while that special command failed and now we know the reason.
<Haohmaru>
note: the second one is invoking a modified "older version" of openocd
<Haohmaru>
i don't remember whether any one of them worked, but i ended up unbricking the chip
<Haohmaru>
i think the 2nd one might have been the working one, i see two invocations of openocd
<Giedrius>
mww 0x40000000 0x10022 - these values seem different from what is suggested for atsamd21, I assume it's for atsame5x?
<Haohmaru>
i had SAME54
<Haohmaru>
but SAME54 wasn't available in that version of openocd so i had to improvise even further
<Haohmaru>
i no longer remember what that 0x10022 is
<Haohmaru>
meeh
<Haohmaru>
also, i don't actually have a SAMD21 here, only SAMD20
<Haohmaru>
basically, blindless butchering wouldn't have been enough to make the "current" openocd do this, someone who understands things had to touch gently, and that can't be me
<Haohmaru>
i also don't have logic analyzer stuff, only a dumb scope here at $job
<PaulFertser>
Giedrius: I can't see where I got (1<<16) | (1<<5) | (1<<1) from, can't remember.
<Giedrius>
ok, the chip finally got erased
<Giedrius>
mww 0x41000000 0x02
<Giedrius>
mwb 0x41002100 0x10
<Giedrius>
however, doing both in the same run was not possible
<PaulFertser>
Giedrius: found, it was from same5_handle_chip_erase_command
<Giedrius>
I had to do them one by one, as openocd seems to stop after first mww due to its fault
<Haohmaru>
yeah that thing was nasty to figure out
<PaulFertser>
Now we know what's happening, cool!
<Haohmaru>
a special key value together with a code for the peripheral has to be written to the PAC thing
<PaulFertser>
Giedrius: same run you mean you needed to restart openocd?
<Giedrius>
yes
<Haohmaru>
Giedrius, that's in my .sh script comments and you can see i invoke ${OOCD} twice
<Haohmaru>
(the bottom one)
<Giedrius>
makes sense
<Haohmaru>
but this PAC constant might be different on the SAMD21
<Giedrius>
yes, SAMD21 manual states it only requires 1<<1 written to it to enable access to DSU
<Haohmaru>
0x10000 == "clear" and then 0x22 must be related to which peripheral you want
<Haohmaru>
^ .... for same54
<Haohmaru>
thus 0x10022
<Giedrius>
ok, so to summarize my today's findings - bitbang.c should not delay returning faults to future calls, and SWD_ACK_FAULT should be possible to tolerate and recover from in these specific circumstances
<PaulFertser>
Yeah
<Giedrius>
btw, I didn't include the cmsis_dap_usb.c patch in my attempts, as the code was not relevant for my setup
<PaulFertser>
Indeed
<Haohmaru>
no one likes cmsis_dap, huh
<PaulFertser>
Just not everybody has it.
<Haohmaru>
i feel so alone
* Haohmaru
hugs his daplink
<Giedrius>
I can't make the modern openocd version erase the chip though