从d醒来后继续生产测试eep sleep

⚠️
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.wsdof.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
6 posts / 0 new
Last post
uta_lc
Offline
Last seen:1 year 1 month ago
Joined:2016-05-03 07:39
从d醒来后继续生产测试eep sleep

Dear Dialogue support,

We are running the production test mode (PTM) binary included in the SDK to perform production test. Can you pls hep us understand the behavior after waking up from deep sleep?

1. Say we downloaded the PTM binary using UART (P0.4 and P0.5 used) and we issue the following command on PC via UART and the chip enters deep sleep mode (OTP is still blank and not programmed):
prodtest.exe -p 28 sleep deep 0 30
2. After 30 seconds, the card wakes up from deep sleep, in this case, because OTP is blank, we will have to download the PTM binary again for other testing to be continued? In this case, before downloading the binary again, the serial connection between the PC UART and the chip uart should be broken?

What puzzles me is that after 30 seconds, I still can run "prodtest.exe -p 28 sleep deep 0 30" again without downloading the PTM binary first. It gives me the impression that the chip has not entered deep sleep; otherwise given OTP has to be reloaded (and OTP is blank) to get the production test to run again? What's the logic behind this?

Can you please explain or confirm?

Thanks,
uta_lc

Device:
MT_dialog
Offline
Last seen:2 months 3 weeks ago
Staff
Joined:2015-06-08 11:34
Hi uta_lc,

Hi uta_lc,

As in all examples, theres a CFG_DEVELOPMENT_DEBUG definition, that definition when defined it prevents the system from going in deep sleep in order to test the device, by default this flag is defined in the prod_test example, thus preventing the device from going to deep sleep when instructed (the sysram stays powered and the code downloaded before sleep has been retained). As soon as you undefine that, then the code will swicth of the sysram and go to actual deep sleep.

Thanks MT_dialog

uta_lc
Offline
Last seen:1 year 1 month ago
Joined:2016-05-03 07:39
Thanks for the reply.

Thanks for the reply.

Looks like there is something else to be done - I put the undef on CFG_DEVELOPMENT_DEBUG but it works the same. I've double checked the following defs:
#undef CFG_MEM_MAP_EXT_SLEEP
#define CFG_MEM_MAP_DEEP_SLEEP

Have you tried this on your dev board?

uta_lc
Offline
Last seen:1 year 1 month ago
Joined:2016-05-03 07:39
I hereby attached the config

I hereby attached the config file for you to cross check.

I understand that it is not possible to measure deep sleep current while UART is still hooked up. However I do expect that without a new download the UART should not be accessible.

Maybe there is still something I don't understand?

Thanks for your kind help,
uta_lc

MT_dialog
Offline
Last seen:2 months 3 weeks ago
Staff
Joined:2015-06-08 11:34
Hi uta_lc,

Hi uta_lc,

Just tested on a pro dev kit, the device if you undefine the CFG_DEVELOPMENT_DEBUG and send a deep sleep command through the RF Matser and with the prod_test.exe, it goes to sleep and never wakes up (no matter the timer you set), which is what the device suppose to do even with the CFG_DEVELOPMENT_DEBUG set in the prod_test, so i cannot verify what you are mentioning since i dont have access to the device after its been to deep sleep via the prod_test_tool.

Thanks MT_dialog

uta_lc
Offline
Last seen:1 year 1 month ago
Joined:2016-05-03 07:39
I rebuilt the firmware using

I rebuilt the firmware using SDK 5.0.4 files and deep sleep is behaving as expected now. Was on 5.0.3, not sure what happened.

Thanks for the hint.