⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.xmece.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
6 posts / 0 new
Last post
Merigh
Offline
Last seen:7 months 4 weeks ago
加入:2020-08-25 20:51
Current Spikes when in Extended Sleep

Hello,

I have a custom PCB with Dialog 14682. I am running into an issue where, when I enter extended sleep, the CPU appears to wakeup momentarily every 2 or 3 milliseconds. I am using an accurate DMM to see that the sleep current does drop to ~6uA, and that the spikes are in the 1s of mA, so not high enough that the radio is turning on, but rather indicating the CPU is waking up, possibly. This means that my average sleep current is something like ~200uA instead of ~6uA.

This occurs when running simple demo projects from the SDK, like extended_sleep and BLE_adv. This also occurs if I try to enter hibernation rather than extended sleep.

I am powering the Dialog chip off of 1.8V VBAT. This is built in to the system and can't be changed. Proper configuration changes, such as changing the battery configs to be TYPE_NO_RECHARGE, have been made to operate at this VBAT, but maybe I missed something there.

For more context, I have tried this on two separate 14682 PCBs (similar designs) with similar behavior. One board exhibits a 2ms period behavior, while the other exhibits 3ms period. I have some peripheral sensors connected to GPIOs that I have tried to configure correctly, and have cut the traces manually as well, with no change. I have tried playing around with the power domains such as 1V8 and 1V8P (on, off, sleep on, sleep off) and how the FLASH is powered (1V8 or 1V8P), with no effect. I have tried turning off the Watchdog with no luck, as well.

Any help is appreciated! Either any insight into SDK operations (auto-wake up if some power domain decays too much), or any tips on debugging custom hardware. I believe we have followed the layout guidelines to make these boards, but I can't rule out hardware issues, of course.

Thanks,

M

Device:
PM_Dialog
Offline
Last seen:15 hours 1 sec ago
Staff
加入:2018-02-08 11:03
Hi Merigh,

Hi Merigh,

Thanks for your question online and for your interest in our BLE solutions. Would it be possible to share a screen with that spikes?

Thanks, PM_Dialog

Merigh
Offline
Last seen:7 months 4 weeks ago
加入:2020-08-25 20:51
Please see attached.

Please see attached.

Thanks,

M

PM_Dialog
Offline
Last seen:15 hours 1 sec ago
Staff
加入:2018-02-08 11:03
Hi Merigh,

Hi Merigh,

Thanks for your input. Is that waveform when the device is advertising? Can you detect is over the air? How the sleep mode is configured? Does the adverting stop and then device is going into sleep mode?

Did you test is in our DKs?

Thanks, PM_Dialog

Merigh
Offline
Last seen:7 months 4 weeks ago
加入:2020-08-25 20:51
Thanks for getting back. This

Thanks for getting back. This happens when I am simply running the extended_sleep demo project in the SDK, so sleep mode is configured exactly how it is there. There is no radio on, no advertising, no tasks really.

What extra steps should I add to the extended_sleep project in order to ensure I go to sleep? Considering that this is a custom PCB with GPIOs connected to peripheral devices?

I can't reproduce the behavior on my Dev Kit, no. The dev kit looks fine, and runs my code well.

Thanks,

M

PM_Dialog
Offline
Last seen:15 hours 1 sec ago
Staff
加入:2018-02-08 11:03
Hi Merigh,

Hi Merigh,

This sounds like a PCB issue, so I would recommend you checking if the hardware design guidelines have been followed in your design.

//www.xmece.com/sites/default/files/an-b-061_da1468x_application_hardware_design_guidelines_v1.9.pdf

Did you follow that document?

Thanks, PM_Dialog