Any access to CLK_USB branch registers causes debugger to crash

[lpcware]

Content originally posted in LPCWare by rlund on Thu Jul 24 11:35:36 MST 2014
We have triple checked the manual and other registers (such as the base clock), and everything seems to be in working order.

Using an LPC Link 2 debugger board
Using the free code limited version of LPC Xpresso
Tried using a KEIL MCB1800 (LPC chip 1857) demo board
Also tried using an 1837 xplorer board (with the same results)
Tried with multiple different "base" projects (a clean one, a custom one we were working on, even one of the LPC open projects)

Any reads from memory location 0x4005 1800, 0x4005 1804, 0x4005 900, or 0x4005 904 cause the debugger to crash, and require a reset of the target board.
These are the config and status registers for the USB branch clocks, within the CCU1 register.

Any help or pointers on common places to look would be very much appreciated.  Thank you in advance!

[lpcware]

Content originally posted in LPCWare by rlund on Mon Jul 28 09:00:38 MST 2014
I was afraid you were going to say that.  So it's not possible now, but as a future potential enhancement-- as a user it would be highly preferable if the disabled registers were just shown as inactive, and the remaining enabled ones within the peripheral view could still be read.

For your records, we have also tested and seen it happen with the same types of situations with other disabled registers, such as EMC, SPIFI, and CREG peripheral views.

Thanks for looking into it.  I do think we can work around it now that we understand the cause.  It's just somewhat unexpected.  Hopefully this forum post will help any one else who comes across it.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Jul 28 07:59:47 MST 2014
My investigations here indicate this is actually a restriction in the design of the CCU1 peripheral - you can access the branch clock registers (CFG and STAT) only if the respective branch clock is enabled.

Thus when you try to display the CCU1 peripheral in the debugger, it actually goes off and tries to read all of the registers. And if there are any at all where the corresponding branch clock is not enabled, this is basically going to trigger the problem.

At this stage I am not sure as to whether there is anything we can easily do from within the debugger to prevent this. Other than recommend that you don't view the CCU1 peripheral unless you have enabled all branch clocks.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by rlund on Mon Jul 28 07:26:57 MST 2014
I apologize, I didn't do a good job explaining.  This is what we have discovered thus far:

Scenario 1:
I pause the debugger in my program to check on the value of some registers.  If any of the base clocks are not enabled via their CGU control registers, (specifically ensuring the power down bit in the clock's CGU control register is set up to enable the clock) then this results in a problem when you click on the CCU1 peripheral view.  The peripheral view will come up like normal, and instead of there being information accessible via drop down, the label for CCU1 will have red text, with a tool tip that states something to the effect of the memory not being accessible or the peripheral being disabled.  (At this point I have usually clicked on the red text, so I don't know if the act of clicking is a contributing factor or not.)  Now everything still  appears to be good until you start trying to do other things in the debugger.  If you click on any other peripheral views, they will also come up as "inaccessible".  If you try to press play on the debugger again, you'll get an error about the debugger losing access to the target.  When you try to hit stop on the debugger, an error comes up saying "cannot halt processor".  The debug session then ends, but if you try to restart, you'll get the same "cannot halt processor" error.  Then a power cycle or physical reset of the target board seems to often be necessary to get it back on track and be able to start a new session.

The interesting thing is that if all the base clocks are enabled via their power down bit in their CGU registers, then the CCU1 regsiter peripheral view will pop up like normal, and everything can be seen, and everything will continue and work as expected.  Also, if you don't ever click on the CCU1 peripheral register view, then everything will continue as normal.

Scenario 2:
I try to read a register value via code in the program.  We can use my USB0 clock as an example.  If the PLL0 and USB0 base clocks are not enabled via their PD (power down) bits in the CGU register, then I cannot access thier CCU1 branch clock registers.  I read in the manual something to the effect of the fact that the CCU1 branch clock registers wouldn't be read or write accessible if the branch clocks weren't enabled.  So perhaps this is expected behavior.  Although I maybe would have just expected to read back invalid data.  At any rate, what happens is, I try to read the CCU1 CLK_USB0_STAT register value via my code (which I now know is a disabled register, due to the corresponding CGU USB0 CTRL register not having the base clock enabled).   I put a break point on my CCU1 CLK_USB0_STAT register read, which is copying the contents into a local variable.  When I tried to step through this line of code, I lose my little green line indicating which line I am stepping through.  I then get the debugger error of losing communicate with the target, and need to power cycle before being able to gain access again for a new debug session.

So scenario 2 works fine when the corresponding base clock is properly enabled, which is what I care about in my final program (which won't be running with a debugger).  But scenario 1 has slowed down our testing quite a bit.  It kind of seems like any attempt to view a disabled register via the debugger, whether through code or the register view, causes us an issue.

Our hardware setup:
LPC link 2 debugger board
LPC Xpresso, tried both 7.2 and 7.3, no difference
1837 Xplorer demo board (as the target), also happens with a Keil MCB1800 (LPC1857) board
PC is running Windows 7
Project is set up to use LPC Open
Providing power to debugger and target board via USB

Hope that helps, let me know if you need more detail or clarification.  I can take some screenshots too if that helps.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Jul 24 13:59:01 MST 2014
I'll ask again. What s the nature of the crash? Please explain exactly what you did and exactly what happened. This is not a known issue, so we want to understand what is going on a resolve the problem. Thanks.

[lpcware]

Content originally posted in LPCWare by rlund on Thu Jul 24 13:52:10 MST 2014
Well, it always crashes if we try to use the peripheral view for any of the CCU registers.

It does look like we may be in business now by accessing via code. 

I was confused because the CCU documentation states-- "Remark: The CCU registers for a given branch clock are only read and write accessible when the branch clock is enabled."  But you enable the branch clocks via the CCU registers.  I think it really means these CCU registers are only accessible if the corresponding BASE clock is enabled via the CGU.

I traced back and found a disabled USB0 BASE clock in the CGU peripheral.  Once I enabled that, it seems I was able to read the desired CCU branch clock register (via code only).

So it seems the core problem is solved.


It sure would be nice to view the CCU registers via the peripheral view though without crashing though.  It happens with a couple of the other peripheral views as well (CREG, and SPIFI).

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Jul 24 12:45:52 MST 2014
What, exactly, are the details of the crash? What error messages are displayed? What actually crashes? GDB? The debug driver (crt_emu*)?

How are you trying to read the memory? Have you tried using the peripheral view? Have you enabled the peripheral? By default many are powered off, causing a bus fault exception on the target if you tried to read them.