• State Verified Answer
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 725 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 271504
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF52 reset after voltage/load step

jk1

I have a design that uses the NRF52810 as well as NRF9160. 

For safety reasons, it must have a fuse that is about 1 ohm into the system.  I'm seeing an issue after an input load-step of e.g. 1A (used to power the nRF9160 transmit), the nRF52 seems to reboot.  The only thing I could find suspicious is that the voltage that the nRF52 sees goes from ~2V to about 3V in about 1ms when the load is removed, and this is what causes the issue.  Interestingly its not when the load turns on and goes from 3V to 2V.  

Does this sound surprising?

I might try a regulator to just prove this step-up is the issue or not, but unfortunately, it will be very difficult for me to make this change due to some other circuitry that relies on 3.3V (stable) while the cellular isn't running! 

For what its worth, the reset pin is not used in this design as this was the first thing I thought (e.g. a glitch on the pin)

Parents
  • 0

    I found a footer note in the datasheet that says POR will reset if there's a 300mV/300ms rise.  That sucks but I guess that's exactly my issue.  Is there any further detail on this?  Ironically I have the nRF52 controlling the boost circuit, and have now implemented a controlled *rising* rate of change that seems to fix it.  However, it is VERY slow, so if you guys can explain that circuit at all, maybe I can be a bit smarter (I understand it would be "off datasheet" and carry some risk

  • +1 in reply to jk1

    Just closing this out.  Not quite ideal for routing/layout to split up my power supplies and references (the NRF52 is the GPIO ref to NRF91), but I'll figure it out some other way.  Right now I've simply limited the slope up after a dip and got past with our current hardware. 

    Is there any further detail you can provide about the POR and what causes this?  I'd like to possibly go off datasheet and speed up that slew rate if possible.  For example, since I'm monitoring maybe if the dip is only brief then perhaps I don't need to ramp back up as slowly (depends on how the internals look of course)

Reply
  • +1 in reply to jk1

    Just closing this out.  Not quite ideal for routing/layout to split up my power supplies and references (the NRF52 is the GPIO ref to NRF91), but I'll figure it out some other way.  Right now I've simply limited the slope up after a dip and got past with our current hardware. 

    Is there any further detail you can provide about the POR and what causes this?  I'd like to possibly go off datasheet and speed up that slew rate if possible.  For example, since I'm monitoring maybe if the dip is only brief then perhaps I don't need to ramp back up as slowly (depends on how the internals look of course)

Children
No Data
Related