Changing ADuC712x Core Clock Source with JTAG

I see in a previous topic ( that if the power management modes are enabled while using JTAG, the part must be mass erased.  This would seem to prevent using any core clock souce other than the internal oscillator PLL output, since in the description for the oscillator (p.49 in Rev0 of the ADuC7128/7129 datasheet), the datasheet provides sample code to put the part into nap mode while changing the clock source. 

Is there a reliable way to switch the clock source without using nap mode?  Does nap mode have to be used in the case where an external clock is used directly (without the PLL)?  I also don't see any restriction on changing the CD bits.  Can these be modified indiscriminately assuming the PLL is locked?

I'm also confused as to why the part needs to be mass erased.  If my code has a problem and the core remains in a low power mode, I can certainly see the jtag not being able to take control of the core.  But if the part is not currently in a low power mode and has a valid core clock, shouldn't the JTAG be able to take over the core?


  • 0
    •  Analog Employees 
    on Mar 21, 2011 5:56 PM


    The real situation is that the JTAG will not ever be able to talk or wake up the part if it is in a power down state.

    If your code is mainly in power down mode, and momentarily wakes up, then it is unlikely that you will be able to get the JTAG activity to coincide with this wakefulness. Your only recourse is to mass erase the part to regain JTAG control. This is what the recommendation is trying to convey.

    If you momentarily go to sleep, like when you want to change clock source, then it is a function of the application as to what percentage it is asleep versus it being awake. The likelihood is that for the most part it will be awake when you go to connect via JTAG. The recommendation to “mass erase” would not apply in this case.

  • 0
    •  Analog Employees 
    on Mar 21, 2011 9:06 PM

    You don’t need to nap when changing CD bits.

    I don’t know for sure what will happen if you debug through a momentary nap situation. I suspect that it might depend on what timeouts the debug tool that you are currently using.

    As far as I understand it, when you enter debug mode, the core switches over to the TCK clock input. The ARM7TDMI pipeline is then accessible to the debug tool via one of the scan-chains. This particular 33 bit scan-chain has a bit which can switch between the debug clock and the system clock for the next access. The system clock is needed for accessing memory resources for example.

    I am guessing here but I would expect that an access like this would be stalled for the duration you indicated, and it might depend on the debug tool as to how that stall would affect it.

    That said, I am guessing here, and I think that I must actually try it and see.

    Problem is that we don’t have 100 % visibility into what the debug tool is doing at any one time so the best we can figure out is if it works or not for a particular setting. This might be a question for them really.

  • Patrick,

    Thanks for your response. The forum also suggested this discussion (, which also talks about this issue. I'd missed it before.

    Can you comment on what happens to the JTAG if the part is being debugged and runs code that momentarily (say, 120us) puts the core into nap mode and then properly wakes back up into active mode?

    Also, can the CD bits be modified without the use of nap mode?



  • Patrick,

    Thanks for clarifying on the CD bits.

    I think I got the configuration wrong before, such that the core actually had no clock.  I'll try it again with a correction to the configuration and see what happens.  Erasing the part is pretty painless if it doesn't work as expected at this point.

    I am confused by your statement that the core uses the TCK input when in debug mode.  Does that mean that I should use the JTAG speed indicated in the console window (titled "build output" or "command" depending on debug mode in the keil tools) for any calculations dependent on core clock, such as baud rate?  That doesn't sound right to me...


  • 0
    •  Analog Employees 
    on Mar 22, 2011 9:38 AM


    The “core” in this context that I use is the ARM7TDMI, excluding the peripherals like the UART etc.

    And when I say “debug mode” I really should have said “halted in debug mode”.

    Apologies if I added confusion, the TCK has no effect on a baud rate or anything like that.