AM3359: Cortex-A8 does not restart on MPU wakeup when DBGEN is active

Dear all,

I'm currently trying to work out a full cycle for debugging Deep Sleep operation through JTAG. I have come pretty far already but there is a particular oddity I cannot really get around. I'm using OpenOCD, not CCS, because it neatly integrates into my development environment.

Here's the procedure I developed for debugging entry into a Deep Sleep or Standby state:

1. Prepare system for the target DS state (clocks, wakeup source, etc) and execute WFI
2. A8 waits in WFI instruction but PRCM doesn't wake up CM3 because ICEPick forces the MPU clock to active
3. Write 0x2000 into the ICEPick core control register of the A8 core (Register 0x60, IR=ROUTER), this clears the clock request from ICEPick
4. CM3 wakes up and completes the sleep cycle, A8 MPU power domain is now OFF

Provided the MOSC is still on (e.g. in Standby), PRCM and CONTROL registers can now be inspected and compared to desired values.

Now, wake up the M3 through one of the configure wakekup sources, it prepares the system for resume and eventually wakes up the MPU subsystem and here is where it gets odd. I could not find any hint that my resume function was getting executed and at first I thought I had made some programming mistake, but then I found:

After wakeup, the Cortex-A8 simply doesn't execute any instructions while the internal DBGEN signal is asserted.

Deasserting DBGEN by clearing bit 13 in the ICEPick core control register would immediately cause the A8 to start execution, but re-asserting it would just as consequently into the same strange halting state as before, consequently preventing debugging because the core would not accept commands written to DBGITR in this state.

Poking around in various debug registers I found that DBGDSCR states that the core is halted and the MOE field reads 0b0100, External Debug Request. However the core does not respond to restart requests. I also found that DBGPRCR contains 0x5, so the "HCWR" bit is set which would halt the core on a warm reset. That would make sense and describe the observed behaviour, but contrary to documentation the core doesn't restart if PRCR.HCWR is cleared. It simply stays halted.

The "Integration Input Status" register then gave the next hint, because there the "CTI EDBGRQ" bit it set and points towards the CTI.

Dumping the CTI registers showed a rather odd configuration:

CTI_ENABLE = 0x1
CTI_GATE = 0x0
CTI_INENx = 0xf (0 <= x <= 7)
CTI_OUTENx = 0xf (0 <=x <= 7)
CTI_TRIGOUT_STATUS = 0x1ff
CTI_TRIGIN_STATUS = 0x6f

TRIGOUT and TRIGIN would sometimes have other content but bit EDBGRQ of TRIGOUT would always be set, showing that the CTI indeed asserted an external debug request to the A8. However, trying to clear EDBGRQ by writing to CTI_INTACK did not have any effect. Eventually I found that the following sequence allows the A8 to restart and also allows asserting DBGEN and getting back full debug capabilities:

1. write 0x0 to CTI_ENABLE
2. write 0x8 to ICEPick core control register for the Cortex A8 (0x60)
3. write 0x0 to CTI_ENABLE again (actually, any access to any CTI register is will do, read or write doesn't matter)
4. write 0x2008 to ICEPick register 0x60

At this point the Cortex-A8 is running and DBGEN is asserted and it would respond normally to debug requests from the debugger. However, between de-asserting and re-asserting of DBGEN, the A8 will have executed quite a large amount of instructions which definitely prevents debugging of the initial wakeup code.

This strikes me as rather odd. It looks like it was attempted to allow debugging of the MPU wakeup, which would explain the value of DBGPRCR, but the CTI configuration found after waking of the MPU power domain looks more like a proper reset was missing.

So the question would be, is this behaviour as intended by the design? How would a proper restart of the MPU look like without loosing the ability to debug after a resume? Note, that without running through the steps 1-6 described above it is _not_ possible to debug the A8 with JTAG until the next Power-On-Reset, even if you never attached the debugger before the system went to DS. Attaching the debugger would simply halt the A8 core but not allow control, a state which is (almost) completely useless for debugging.

Best regards,

Matthias