AIRCR on SAMD21

[crm]

https://developer.arm.com/documentation/dui0552/a/Cihehdge says "See you vendor documentation for more information about the use of this signal in your implementation". So, what vendor document describes this?

(Why? I have a custom SWD programmer for Atmel M0+ SAMDs. It seemed to work fine. Recently I wanted to use it for SAMLs too. It didn't work at first. Looks like my SWD clock was a bit too fast. I slowed it down a bit. Now SAMLs work. But somehow that broke SAMD programming. I narrowed this down to the AIRCR register. It looks as if writing 0x05fa0004 to AIRCR kills the SWD communication.)

[ataradov]

AIRCR is the core register, but all it does is assert a signal. What this signal does on the system level is up to the vendor that integrates the core. As far as I know on SAM D/L it is just hooked up in parallel to all other reset sources.

But it should not kill the communication, since it is a standard way for the debugger to reset the core after setting the vector catch bit. All my tools do that and it works fine for both DAM D and L.

There must be something else going on in your system.

Figure named "Reset Controller" in the datasheet describes what is reset by different reset sources. AIRCR request is "CPU" in that figure.

[crm]

Thanks Alex. Yes, this is very strange, I know. We have used this programmer for SAMDs for a while without any issues. I actually used your edbg and free-dap tools as an example when I made it to program SAMDs. The programmer itself an XMEGA. Because we had it since before we started using SAM micros.

Looks like everything seems to work even without writing 0x05fa0004 to AIRCR? By "everything" I mean I can erase the chip, program flash, etc. But I guess I still want to understand what is going on.

[ataradov]

You need AIRCR to get a "clean" system. Technically, you don't even need to halt the core, you can just start doing flash operations and existing running code will stalled while operation is ongoing and will continue to run (possibly the erased section or the new code) after operation is done. This is likely to cause CPU fault, but that does not inherently prevent further programming.

The reason you want clean state is when the running code is doing something that may interfere with the flash write, like writing the flash itself, or resetting the system. It is better to figure out what is going on and fix it, since you may run into weir situation depending on the programmed firmware, and this is not how you want tools to behave.

[crm]

Still cannot figure out what is going on. BTW, regarding my original "kills the SWD communication". It doesn't kill it completely. For example, I can still access the DP registers (like IDCODE, CTRL/STAT, etc). But get a FAULT in response to all AP requests.

Regarding the need for AIRCR for "clean" system. I'm going through what they call Cold-Plugging in the SAMD21 datasheet. Shouldn't that be enough? The datasheet says "The CPU remains in Reset due to the Cold-Plugging procedure".

[ataradov]

Cold plugging just lets you intercept the initial boot, but in order to do anything with the system you need to release the reset. The normal procedure is to halt (vector catch) the core, then release the reset. This way core does not run any code, but the rest of the system is not in reset.

[crm]

But in Programming section in datasheet:
4. The debugger generates a clock signal on the SWCLK pin, the Debug Access Port (DAP) receives a clock.
5. The CPU remains in Reset due to the Cold-Plugging procedure; meanwhile, the rest of the system is released.

[ataradov]

I'm not 100% sure, but I think they mean the things that need to happen. So, you are expected to put the system in that state.

Have you tried to do anything without releasing CPU reset extension?  I don't think it would work, but it was a long time since I experimented with all that.

[crm]

Yes, I have tried. Seems to work just fine (chip erase, flash programming, flash verification):
- Cold plugging (reset with CLK signal low)
- Switch from JTAG to SWD
- Read SWD_DP_R_IDCODE
- Write(SWD_DP_W_ABORT, 0x00000016)
- Write(SWD_DP_W_SELECT, 0x00000000)
- Write(SWD_DP_W_CTRL_STAT, 0x50000f00)
- Write(SWD_AP_CSW, 0x23000052)
- Write(DHCSR, 0xa05f0003)
- Write(DEMCR, 0x00000001), but it also seems to work without that

[ataradov]

All this I expected to work. As long as the actual communication with the flash controller is working, it is fine. I don't remember the exact details way I was doing things that way. Likely because I wanted to support the scenario of no reset line.

[Renate]

Just a side note (I think).

If the SAM was locked you have to skip writing to DHCSR and DEMCR (which would cause a bus fault) and proceed directly to mass erase.