• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 87 subscribers
  • Views 1033 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 278595
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

After disabling DCDC Regulator, the Master (phone) gets disconnected.

Rafi

I combined the BLE UART and SPIS Peripheral example of SDK V17.0.2 to receive 251 bytes of data from a microcontroller using SPIS protocol. The microcontroller sends data every 32 milliseconds and the BLE sends it over to the master every 128 milliseconds intervals. I increased the hvn_tx_queue_size to 20. I am using the breakaway module of MBN52832 DK. 

Before I enabled DCDC regulator, (using sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);) the device was working fine without any data loss.

However, after I enabled the DCDC regulator, the BLE connection is stable and works without data loss only when the DCDC regulator is enabled.

If I disable the DCDC regulator (using sd_power_dcdc_mode_set(NRF_POWER_DCDC_DISABLE);), or comment out the DCDC enable line, the connection drops after 5~10s with error code (0x8) GATT CONN TIMEOUT. 

I increased the "Connection supervisory timeout" and found out that, if the slave does not send data within the defined supervisory time, the disconnection occurs.

Even if I erase all firmware and load the DCDC regulator disabled firmware, the connection keeps dropping and only becomes stable, if the DCDC regulator is enabled. 

My query is, how can I go back to the part, where I had a stable connection with the DCDC regulator disabled.

Parents
  • +1

    Hi Rafi,

    Before I enabled DCDC regulator, (using sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);) the device was working fine without any data loss.

    This is strange that even after disabling the DCDC and going back to the state that was working before makes you see the disconnects. Can you please help me reproduce this error? Can you share your project, SDK version and the laser markings on the chip so that I can try to test it on my desk.

Reply
  • +1

    Hi Rafi,

    Before I enabled DCDC regulator, (using sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);) the device was working fine without any data loss.

    This is strange that even after disabling the DCDC and going back to the state that was working before makes you see the disconnects. Can you please help me reproduce this error? Can you share your project, SDK version and the laser markings on the chip so that I can try to test it on my desk.

Children
  • 0 in reply to Susheel Nuguru

    Hello ,

    Thank you for your response. I guess it was some sort of device issue as it was solved when I used a different device.

    However, I am facing a different problem Sweat smile. I am using the "read" function of MATLAB to receive BLE data and then I store them in a variable. A sniffer screenshot is given below. As you can see, the 251 bytes that was sent from the BLE is divided into three parts (123 + 123 + 5).

    After like 20 minutes of data collection, the nRF52832 stops sending data but stays connected to the master. Then the sniffer output only shows Empty PDU, just like the second row of the attached image (Empty PDU).

    If I restart the device, it starts to send data again.

    So, I think there might be some kind of buffer that is getting filled up and might be taking some forbidden memory space which is crashing the device. What should I do to debug this? 

  • 0 in reply to Rafi

    You device stays connected shows that it is still alive and functioning. It would be good if you can start your device with a debugger connected and in the debug mode. 

    Rafi said:
    I am using the "read" function of MATLAB to receive BLE data and then I store them in a variable.

    In the image, I see that there are notifications coming from the slave to the master. It is possible that your application on the slave has been stuck in some state machine where it is not sending notifications anymore. Starting the slave in debugger and waiting until you see only empty packets and then pause the debugger to see the context of what the slave is stuck into. Looking at the function call trace would give you a lot of insights into what might have gone wrong.

  • 0 in reply to Susheel Nuguru

    Thank you for the reply.

    As I am using SPI communication to send data from the microcontroller (master) to nRF52832 (slave), the debugger points to __WFE function when I paused the debugger during the above-mentioned error. This __WFE is waiting for the SPI event to happen. So, unfortunately, I can not know where the code is stuck by pausing the debugger when I get the error.

    However, on the microcontroller's side, after the CS is low, if I put a 100us delay before sending the data, there is no disconnection. 

    Even if I solved the problem, I need to know what was causing it. As I described the solution, do you have any recommendations on what should I do to debug the error? 

  • 0 in reply to Rafi
    Rafi said:
    As I am using SPI communication to send data from the microcontroller (master) to nRF52832 (slave), the debugger points to __WFE function when I paused the debugger during the above-mentioned error. This __WFE is waiting for the SPI event to happen. So, unfortunately, I can not know where the code is stuck by pausing the debugger when I get the error.

    When the debugger shows that the device has executed __WFE and is in idle state, then it means that there are no deadlocks or freeze states at that point. In that case, there has to be a logical error in your code. I would be surprised that this connection timeout is purely DCDC related, Can you please give me a minimalistic project for me to reproduce this error?

Related
Terms of service