11:59 <davidmpye> Hello!  I have a somewhat niche SAMD20 question, if anyone might know the answer.   I am working on an OSS project to replace the firmware for Dyson vacuum cleaner battery packs.   The pack has an ATSAMD20 MCU on, with the security enable bit set.  I can unlock and erase it via Atmel-ICE and atmel studio, but for Joe-public, I'd like to be

11:59 <davidmpye> able to do it with Raspberry Pi and the GPIOs to provide an easy and cheap way for people to reflash the packs.

11:59 <davidmpye> The info about how to get openocd to clear the security bit is, well, a bit confusing.   The official at921samd file mentions 'not possible' but there are some patches I found that do seem to make it possible, but they were using cmsis-dap rather than Pi GPIO.

12:00 <davidmpye> <- patches https://sourceforge.net/p/openocd/mailman/openocd-devel/thread/58B890E3.70704%40users.sourceforge.net/

12:00 <davidmpye> has anyone ever tried or managed to do a similar feat with Pi GPIOs?

12:28 <PaulFertser> davidmpye: hi

12:29 <Haohmaru> davidmpye, there are cmsis-dap based debuggers that are cheaper and more obtainable than a raspberry pi

12:31 <PaulFertser> davidmpye: should be possible with RPi bitbanging too.

12:34 <PaulFertser> davidmpye: 4043 is certainly not adapter-specific and it was merged upstream.

12:35 <PaulFertser> davidmpye: 4044 you can probably imitate by "gpioset" commands before running OpenOCD.

12:35 <davidmpye> Thanks all so far, having a play here

12:36 <davidmpye> Haohmaru: That's true but my target hacker/maker 'market' will probably all have a Pi knocking around, but I hear you!

12:37 <PaulFertser> davidmpye: it just pulls both SRST and SWCLK low, then brings SRST high.

12:38 <Haohmaru> i don't have nor have had a single SBC

12:39 <davidmpye> tbf, if I can make a robust way to do it, then I should be able to make it possible for people to do with a variety of transports

12:39 <davidmpye> Haohmaru: At my hackspce, that would make you an outlier, but again, I get your point

12:39 <PaulFertser> One could probably even imitate that manually by connecting SWCLK to ground, not connecting SRST to the debug adapter, then pulsing SRST with tweezers, then connecting SWCLK to the debug adapter and starting OpenOCD.

12:39 <davidmpye> PaulFertser: The other problem, it seems, is that when the security bit is set you can't even connect to the device

12:40 <davidmpye> hence, it fails at Error: Error connecting DP: cannot read IDR

12:40 <PaulFertser> davidmpye: it extended reset?

12:40 <davidmpye> I think even in extended reset, you get a different ID, but I'll try further

12:42 <PaulFertser> davidmpye: also, are you enabling srst_only in reset config? And then you should be able to run command "at91samd chip-erase" even if it's not able to read IDR probably?

12:44 <PaulFertser> davidmpye: hm, so you have a CMSIS-DAP adapter already (the Atmel-ICE), you can try with the hack from 4044 and command from the users manual which mentions cmsis_dap_init_samd_cold_plug to have a reference point?

12:46 <PaulFertser> Hm, it should kinda connect in extended reset state.

12:47 <davidmpye> i'll have a tweak, and report back

12:47 <davidmpye> the DAP idea makes a lot of sense

12:48 <davidmpye> becuase I know that works

12:58 <davidmpye> I don't think cmsis_dap_init_samd_cold_plug ever made it fully upstream?

12:58 <davidmpye> the only reference to it seems to be in that patch afaics

13:01 <PaulFertser> davidmpye: yes, you need to apply it to current source

13:07 <davidmpye> Just having a play with the pi gpios to try to get extended reset to work - at present, as soon as I release the reset line, it starts running normally, which it shouldnt do if SWCLK remains low. Will dig further...

13:18 <davidmpye> So, in deep reset, you CAN connect to it (sort of) : Info : SWD DPIDR 0x0bc11477

13:18 <davidmpye> but you get Error: Target not examined yet in response to anything else

13:18 <PaulFertser> davidmpye: yeah, that looks correct.

13:18 <davidmpye> eg doing the "init; at91samd mwb 0x41002100 0x10; reset"

13:19 <PaulFertser> davidmpye: so how did you got into the extended reset state?

13:19 <davidmpye> which I am guessing, because it cannot do : "Error: Failed to read memory at 0xe000ed00

13:19 <davidmpye> "

13:19 <davidmpye> which it won't be able to do in secure mode, it just needs to write anyway

13:19 <PaulFertser> davidmpye: what about the special command "at91samd chip-erase" ?

13:19 <davidmpye> Error: Target not examined yet

13:19 <davidmpye> write to DSU CTRL failed

13:20 <davidmpye> but it needs to change the register address in secure mode, hence trying to use the mwb command

13:20 <PaulFertser> davidmpye: probably one just needs to skip that check if it's examined or not by adding another hack patch.

13:22 <PaulFertser> davidmpye: you should see all the details if you start openocd with -d3 log.

13:24 <PaulFertser> davidmpye: try commenting out the check in target_write_memory() in src/target/target.c to force writing

13:25 <davidmpye> you're right, d3 shows Error: 140 202 target.c:2674 target_write_u32(): Target not examined yet

13:25 <davidmpye> Error: 141 202 target.c:2715 target_write_u8(): Target not examined yet

13:28 <PaulFertser> davidmpye: you can try just removing that check for testing if it helps.

13:28 <PaulFertser> And then probably to add temporary change to examination status to chip-erase handler if it works.

13:31 <davidmpye> recompiling, back in an hour (pi zero...!)

13:38 <PaulFertser> davidmpye: you could have started checking with your normal computer and that cmsis-dap adapter you already have ;)

16:24 <davidmpye> Thank you for your help @PaulFertser

16:24 <davidmpye> That worked, and I can now do the necessary for the security bits

16:24 <davidmpye> Cheers!

16:25 <PaulFertser> davidmpye: probably add a hacking patch to the unclocking function upstream then? That would save current examined state, overwrite it, then restore.

16:25 <PaulFertser> davidmpye: do you have a link to your repo with that alternative firmware?

16:26 <davidmpye> There are a couple of things that would make that difficult - you'd need to hack something into each transport to do the cold reset, as well as change the read functions to not check for 'examined' status.

16:26 <davidmpye> It's disappointing, but I can see why things haven't got upstream

16:26 <davidmpye> https://github.com/davidmpye/V10_Dyson_BMS

16:26 <PaulFertser> davidmpye: no, I mean the examine problem, not the cold reset.

16:27 <PaulFertser> davidmpye: for cold reset we can just add documentation to the manual so people could do it even manually if needed.

16:27 <davidmpye> I need to update the documentation and do a lot of 'how to install it' info

16:27 <PaulFertser> davidmpye: btw, why were your initial tries unsuccessful?

16:28 <davidmpye> The raspi-gpio set stuff works fine, it was just working out what needed to be tweaked in terms of the write memory functions. There were several that needed the 'examined' status removed.

16:28 <davidmpye> I like that suggestion for the examined state, i'll see how it could be doine

16:28 <davidmpye> *done

16:30 <PaulFertser> davidmpye: in src/flash/nor/at91samd.c samd_handle_chip_erase_command function.

16:42 <davidmpye> Interestingly, there is a target_set_examined function defined  in target.h, but no 'clear_examined' function

16:42 <davidmpye> so you can set it, which will allow the writes to succeed, but no way to clear