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.