Program halted unexpectedly for DA14681

Hi auzzz,

The description of the probelm is quite generic i can't see where the problem is by the provided info, you will have to attach the debugger in order to check where the code has halted, this could give us a clue of what is happening with your custom hw.

Thanks MT_dialog

hi,
It seems that we meeting the same problem, we also designe our own board , and i download the pxp reporter of SDK 1.0.6.After about 8 seconds ,it reset ,and then reset again in the next 8 sceond over and over again...

Hi auzzz, kingwheat,

I dont think that the UART has something to do with what you experience, i trust that something else is wrong and what you are mentioning are just side effects caused by another issue. Some information, which package you are using, what is your soldering profile, and what is the thickness of your stencil on your custom hw ?

Thanks MT_dialog

Hi kingwheat, auzzz,

As far as i can tell what you are expericing has to do with the soldering of the grounding on your custom PCB's. Since after 8 to 10 seconds both of the boards are stalling most probably that is because the BOD kicks in and resets your boards as soon as the DCDC is activated. After 8 seconds the system changes from the LDO's to the DCDC supply, when the system runs on the LDO's the only reason to get a BOD reset is by having an actual voltage drop, when the system runs on the DCDC a BOD event might be triggered especially if the DCDC GND pin or the central GND pad has soldering issues. In order to check this you can disable the BOD by #define dg_configUSE_BOD (0), this will disable the reset (the issue still remains just in order to test if this is the actual problem). Also, you can try to press the SoC on the PCB or reheat the solder in case this improves what you are experiencing that will also verify that you have soldering issues.

Also in order to check that indeed this is your problem you can do the following in order to check the BOD_VREF. This should be accurate to 515mV with variance less than 50mV under any circumstances.

So add the following code in the system_init() before starting any new task to export the BOD_VREF to P1_7

//Export BOF_REF to P1_7
REG_SETF(GPIO, TEST_CTRL5_REG, TEST_BOD_VREF_OUT, 1); // Map BOD reference buffer output to testbus
REG_SETF(ANAMISC, ANA_TEST_REG, ACORE_TESTBUS_EN, 1); // Enable analog-testbus in ACORE
REG_SETF(GPIO, TEST_CTRL2_REG, ANA_TESTMUX_CTRL, 0x3); // Select analog-testbus in the PADs
hw_gpio_set_pin_function(HW_GPIO_PORT_1, HW_GPIO_PIN_7, HW_GPIO_MODE_OUTPUT, HW_GPIO_FUNC_ADC); // Set to P1.7 to ADC/open mode

Keep the BOD disabled, so it wont kick in by adding the #define db_configUSE_BOD (0) in the custom_config_qspi.h file and disable the sleep mode.

In order to see this on an oscilloscope you will have to isolate the power supply to avoid noise and run the laptop on Battery to isolate it from devices which can inject noise through the ground, so be very carefull.

关于你可以复制它basic kit, i am not able to see something like this on my setup, i ve downloaded run and used the UART with the proximity reporter and the multilink demo running on a cr2032 battery with the 1.0.6 SDK.

Thanks MT_dialog

hi, MT_dialog
Thank you very much for answer our question.
before the test, the project's configration is #define dg_configUSE_BOD (1), and turn on the sleep mode, it will reset
I have the test for that,
firstly, #define dg_configUSE_BOD (0), and turn off the sleep mode, it runs well.
secondly, #define dg_configUSE_BOD (0), and turn on the sleep mode, it will reset.
As it's shows , I find the reset is much more relative to the power mode mangerment,.

There is another problem i meet when i use the hardwear IIC.
I operate the IIC write function like this: ad_i2c_write(); read: ad_i2c_transact(dev, ®_addr, 1, reg_data, cnt);
it works well if I turn off the ble stack.if not ,some event may disturb the IIC interface.
我很迷惑,因为我使用hardwearic, after i operate the read or write function, I can let my cpu to do another thing after that has finished the opration they will give me a callback ...in this case ,how dose the ble event effect the hardwear iic? sometimes the iic will miss the callback and let my task to stay in Block..

Hi kingwheat,

Please if you find the previous response helpfull, mark the answer as accepted, also please dont respond to an answer with an additional question irrelevant to the thread's topic, if you would like to ask a new question you can always create a new thread.

Regarding your question, i am not sure i get it right, all i understand is that you are missing interrupts. In general the BLE interrupt has a higher priority from any other interrupts but that doesn't mean that you will miss the I2C interrupts. What could be happening is that your I2C interrupts occur the same time with the ble critical section, when the BLE is going to sleep, that has a Critical section that disables the interrupts for about 600us and perhaps this is where your program stalls.

Also regarding the callbacks that you are refering to when the operation has finished, you mention that you are using synchronous functions ad_i2c_transact() and ad_i2c_write() instead of the asynchronous corresponding functions ad_i2c_async_transact() those kind of functions take a callback as a parameter and will not wait for the operation to finish and the corresponding callback will be invoked when the operation has concluded.

Thansk MT_dialog