Hi, Dialog
I downloaded the program 'projects\target_apps\ble_examples\prox_reporter\Keil_5' to the board 'DA14580DEVKT-B' instructed in the document 'Training_04_sleep_modes_current_measurement_v1.0.pdf', however, it seemed that program halted soon. I did not find it by a BLE debug tool named 'nRF Master Control Pane(BLE)', and I can find its advertisement with other program whose variable 'app_default_sleep_mode's value is 'ARCH_SLEEP_OFF'.
Thanks.
Keywords:
Device:
It works after changing the CFG_LP_CLK from LP_CLK_XTAL32 to LP_CLK_RCX20, though there is a 32Khz XTAL connected to the Y pins on the board. I don't know why the document does not mention it.
Hi Linjuncheng,
Be aware that all dialog kits are equipped with an external XTAL32, so you should be able to run the examples when using Dialog's dev kits without changing the Low power source. If you suppose that the XTAL32 was the issue, then I would suggest that the XTAL32 doesn't operate properly. Although, please try to check first where exactly the code halts when having selected the XTAL32 option. For example, your code halts because WDOG expired or an NMI hits. So, try to debug your code, and try to find where it halts in order understand which is the issue
Thanks, PM_Dialog
Hi, PM_Dialog
函数中的代码停止NMI_HandlerC范围h commented with something about WDOG timeout, and I can see the caller is 'ble_deep_sleep_stat_getf' in the call stack while debugging. The function 'ble_deep_sleep_stat_getf' is only called at 663 line in function rwip_sleep, it seems that the code is waiting for the BLE core to do something.
Thanks.
Hi Linjuncheng,
If the NMI hits into the ble_deep_sleep_stat_getf() function, this means that is an issue with the LP clock. So, yes the most probably reason is that there goes something wrong with the XTAL32 on the dev kit.
Thanks, PM_Dialog