How do I configure custom_config_qspi.h given that my circuit has no 16khz crystal?
The system appears to attempt to use the 16khz crystal before switching over to the internal crystal. A few seconds later, the app closes with an "unhandled exception." Since this board has no 16khz crystal and the development daughter board does, I'm assuming this is the issue.
The code works perfectly on the deveopment daughter board but fails on my board with no 16khz crystal.
I've changed this setting from LP_CLK_32000 to:
#definedg_configUSE_LP_CLK LP_CLK_RCX
but the issue remains.
Device:
Hi ddustin,
I think that you have created a similar forum thread which is the following:
https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bluetooth-low-energy-%E2%80%93-hardware-device-reference-designs/chip-seemingly
In custom_config_qspi.h you could define the Low Power (LP) clock of the system.
Could you please clarify if you 16KHz or 16MHz? In case you mean 16KHz, this is not possible to be achieved, because for LP we are using a clock at 32.768KHz. The LP clock is been using when the system goes in to sleep mode. Except from the LP, you should have a system clock which will be running when the device is in active mode. The system clock should be defined in system_init() function.
In case you are using an external XTAL16:
Please check the system_init() function from the pxp_reporter example for the SDK. In case you don’t want to have an external crystal oscillator, you should replace the sysclk_XTAL16M with sysclk_RC16.
I would strongly recommend you to have a look at Figure 21: Wake/Power-Up timing and PMU operations of DA14682 datasheet.
Thanks, PM_Dialog
Hi,
Ah right, yes I’m using a 16Mhz primary crystal but don’t have a sleeping crystal. So I specified this setting in the config to use the internal crystal for sleeping: define dg_configUSE_LP_CLK LP_CLK_RCX.
I took the ble_peripheral example code and ran it on both the daughter dev board and my own board, painstakingly removing pieces of the code and putting them back until I found the specific line that breaks on my board but not the daughter board. I changed this line from FOREVER to NOWAIT.
ret = OS_TASK_NOTIFY_WAIT(0, OS_TASK_NOTIFY_ALL_BITS, ¬if, OS_TASK_NOTIFY_NO_WAIT);
// ret = OS_TASK_NOTIFY_WAIT(0, OS_TASK_NOTIFY_ALL_BITS, ¬if, OS_TASK_NOTIFY_FOREVER);
This seemingly corrects the problem (albeit by wasting tons of cycles). I believe this implies that sleeping is failing on my board. Similarly changing the sleep mode to idle instead of extended sleep resovles the issue. How much power is this going to waste?
pm_set_sleep_mode(pm_mode_idle);
// pm_set_sleep_mode(pm_mode_extended_sleep);
Whats the best way to diagnose this further? Is it possible this particular chip has a faulty internal crystal — if so how would I check?
Thanks for your help.
Edit: Visually comparing the daughter board and my board -- the biggest difference is the size of the L1 inductor. I used a physically much smaller inductor on my board. Is it possible that would screw up something with the DC-DC while the device is asleep?
Hi ddustin,
Let me check your issue and I will get back to you as soon as possible.
Thanks, PM_Dialog
Hi ddustin,
OS_TASK_NOTIFY_FOREVER attribute, will force the underlying task to enter the BLOCKED state for as long as there are not pending notifications. If there is no other task in active mode, the IDLE special task will be executed, and the device will enter sleep mode. In addition, the task will be executed as soon as a notification comes either from the BLE manager or the code itself. So, your statement is wrong.
pm_set_sleep_mode(pm_mode_idle) will set the M0+ Core to the IDLE state only if there is not any functionality that requires the CPU interference.
While the chip is in sleep mode, the DC-DC will be de-activated and only the LDOs are powered on. Please, check the Figure 11: Power management unit block diagram in DA14682 datasheet. Only the red bocks are activated in sleep mode. The green blocks are activated / de-activated per user’s requirements.
Thanks, PM_Dialog
Okay that's fine.
Now why does the example provided by you guys, ble_peripheral, *NOT* work? I described the issue earlier but I will describe it again.
When the device enters OS_TASK_NOTIFY_FOREVER, the program haults in approxiately 3 seconds.
This is solved by changing the sleep mode to pm_mode_idle.
其他睡眠模式做*不*工作。为什么他们not work? How do we investigate why they do not work?
Please help. Telling me me statement is wrong is not helpful!! Tell me how to actually investigate the issue please!
Hi ddustin,
I ran the ble_peripheral example of the SDK1.0.14.1081 in the Pro-DK with the internal RCX enabled and it is working perfectly. The default example of the SDK is fully functional. You could clarify it in your Pro-DK as well and use the ble_peripheral project without any modifications in a clean SDK path. Just change the dg_configUSE_LP_CLK macro from LP_CLK_32768 to LP_CLK_RCX. In addition, I would suggest you to run the same project with only the aforementioned modifications in your custom board. If it is working in the Pro-Dk and not in your custom board, this means that is a hardware issue on your custom board and not in the DA14682 SoC. So, my recommendation would be to review your own board.
You could read theAN-B-061 Application Note: DA1468x Application Hardware Design Guidelines从我们的支持门户为了找到硬件design guidelines that will help you to review your schematics and PCB. If you were able to share your schematics and PCBs, I would be more than happy to review them.
Thanks, PM_Dialog