I assumed that your schematic is as follows.
Please let me ask some questions.
1) What is the output mode of the Control Register? If Pulse mode is used, what is provided to the clock input?
2) Control Register component has _Sleep/_Wakeup methods. Did you use these APIs? If you used, what is the calling order of these APIs?
You're right for the schematic, except the PWM is in 16 bits with only one output, and the reset input is forced at zero.
The Control Reg mode is Sync mode, and the clock is HFCLK/2. The reset input is the TC output of the PWM.
The order is as follows:
// Wake up with WDT
// Do something, now ready to sleep
I didn't think about it, but it's right that the Control Reg could be the culprit. However, when I was testing with only Sleep (not deep sleep), I used the API Sleep and Wakeup functions of the Control Reg, and the system worked well.
Thank you for your time,
1 of 1 people found this helpful
Thank you for clarification. It seems that the PWM component does not accept a trigger until the first clock edge is provided. If the problem is that the Control Register component is faster than the PWM component, please try to use same clock for the Control Register and the PWM components. Following figure is my solution. But I didn't try if the schematic works well because I have no hardware right now.
The LFCLK is synchronized with the 24MHz (HFCLK/2) clock and drives both components. The Control Register is configured as the Pulse mode to generate a one-shot pulse.
I believe the sleep/deep sleep modes also turn off the clocks to save power (depending on your firmware/code). Potentially, the clocks aren't quite ready for use/stable?
I'm probably wrong with this, but I figured it was something worth thinking about.
Thanks for the answer,
That definitely is possible, I will try that next week! But won't it result in the same result as just adding a delay in firmware, just more precise?
Also, does adding the Sync block consume more current?
The sleep mode doesn't, but deep sleep does turn off the high frequency clocks. However, I didn't have problems with a timer that uses the same clock as the PWM, so I don't think the problem is the clock. Also, I use Clock_Disable() and Clock_Enable() when entering and exiting deep sleep, and I think there's code in those functions that ensures that the clock is stable.
Yeah, waiting for the clock to stabilize would be the same thing as a delay in firmware. If the timing varies, then you would need to make a longer delay that isn't always necessary, but that depends on if and how much the timing varies
The Sync block might consume some power, but I would think it would be very small; A single AND gate at the transistor level would achieve the sync effect and would only use miniscule amounts of power.
(The documentation for the sync module should give you more direct information on the power consumption and specifications; Right-click on the module and select the open datasheets selection)
Have you tried putting the same clock for both the PWM and the Control_Reg as Noriaki suggested?
Not yet, I'll do it on Monday.