• State Verified Answer
  • Replies 8 replies
  • Subscribers 87 subscribers
  • Views 2567 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 262740
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

abnormal reboot in nRF52832 (urgent)

Roh

Hi, guys.

Its developing with nRF52832.

I have a big problem rebooting. could you help me?

to solve this problem, I tried the following : (of course, it is very stable now.)

  > improving inrush current which of peripheral device to protect POR condition (like a 300mV, 300msec)

  > improving Batt. terminal's tension for conducted resistance reduction.

      - coin cell is LR44 and its internal resistance is 1.65 ohm.

      - working voltage 3V(=2 coincell)

The following are the pre-occurrence symptoms : 

  > continuous retry BLE connecting after occur communication disconnecting.

  > voltage drop (like below image)

ref. : Our SDK version is ver15.3 which is including a part of v16.0 and 17.2
        Because our device is a medical device, it is impossible to change the version.

  • +1

    It looks to me as the drop is up to 1V and the duration is up to 1.3seconds:

    This kind of drop in voltage will unfortunately trigger the POR when voltage return to normal ~3V. To avoid this you will need to either reduce the drop and/or reduce the duration of the drop. What is the connection and advertisement interval here? What is drawing all the current during the 1.3second period? Maybe you can look into increase the connection interval and advertisement interval here?

  • 0 in reply to Kenneth

    If using some hardware device driven by the nRF52 port pins (the trace looks suspiciously like this is the case) you could try shottky- or ideal-diode-isolating the nRF52 from the coin cell with the nRF52 capacitor at the nRF52 side. That way the pulse of current into the hardware device will still drop the battery voltage but now the nRF52 has isolated reserve power the voltage of which does not drop as much due to the private capacitor. It's a hardware change, unfortunately, but easy to test. If the port pins supply the power direct to the device then an intermediate buffer is needed, an ideal diode works well.

    If there is no such hardware device maybe try increasing the capacitance on the coin cell; at least 47uF is required, 150uF preferred. If using only 10uF then that is likely the primary problem.

  • 0

    I know well that the waveform in the picture is the POR condition.
    So, we improved the inrush current and Batt. terminal tension to get rid of it.
    BLE connection interval is a slave latency 3(75~100msec) and AD interval is 230msec before pairing and 750msec after pairing. (in the picture, a small point is AD interval sign which it is at left/right side of deep point..)

    our SW engineer worry about next :
    -If AD interval is extended, access trying is not available.
    -If connection interval is extended, data through put is slow-going.


    The idle current is 0.3uA before reset and when reset is occurred, we couldn't catch it since the phenomena had occurred very non-periodically.

  • 0 in reply to Kenneth

    A capacitor of 100uF is installed in the circuit.
    If it's an neighbor cause of MCU, the shotky diode will work, but if it's an MCU itself cause, the diode won't help.
    Most of the gpio for external device control is pull up or down with 1M or 10K ohms resister.
    For reference, there was no action on the peripheral circuit when the symptoms occurred.

  • 0 in reply to Roh

    Reducing the advertising rate would improve the situation, assuming each of those downward voltage steps is caused by an advertising transmission burst. Perhaps try an extreme case, advertise once per second to see what happens to those voltage steps. If that helps, perhaps there is a compromise advertising rate.

    I'm assuming that once connected there is no issue?

Related
Terms of service