This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRESET/DIO pin specifications? recommended filtering, inconsistent state between resets.

As noted in recent past cases, we have an issue with the state of the nRESET pin that is causing unwanted resets when connected/disconnected from external hardware (programmer, battery charger.

In testing for state of the pin between resets (forced and unwanted), it is found to randomly come up either internally pulled up, or floating, and either immune to resets, or not. Adding an external 1K pullup has appeared helped to some marginal degree, but is not fully reliable. We have scoped the pint and there is invariably a significant glitch on the pin the characteristics of which seem to change based on, presumably, internal termination and/or other reset parameters.  There appears to be 3 fundamental conditions that the pin comes up in:

     1.)  Floating, in which case, any attempted connect or disconnect causes the chip to reset (most prevalent)

     2.)  Internally pulled up, in which case, connect may or may not cause a reset, and

     3.) Unknown pullup, but never resets when connected/disconnected (presumably somehow placed in debug mode?)

At any rate, we need to design some level of filtration ahead of this pin (and perhaps the SWCLK pin) to eliminate these unwanted resets, without affecting programmability. 

However, There appears to be no specifications in the documents for these pins that describe threshold levels and timing requirements for the reset and programming interfaces.

Can someone please help with this by either providing a "know to work"  pin cushioning circuit, or the specification for these pins to start a filter design?

Thank you all kindly,

Robin @ TL 

  • Hi,

    There is an internal 47kohm pull-up on nRESET/SWDIO pin. The chip will be kept in reset state until the input level reach logic high (>0.7 * VDD). The time this will take depend on external circuity, for instance additional external pull-up resistors and possible capacitance from pads, traces and additional external capacitors placed on the nRESET/SWDIO pin.

    You are free to add any additional circuitry you see fit, e.g. a capacitor or small resistor, the impact will be the time the chip is kept in reset state before logic high is reached. It may also impact max clock frequency during programming.

    Best regards,
    Kenneth 

    3.) Unknown pullup, but never resets when connected/disconnected (presumably somehow placed in debug mode?)

    Correct. 

  • Hello Kenneth,

    Good to chat with you again. .

    One of the points you haven't addressed is why the pin itself would boot up to different termination states, and, by the way sometimes ends up in a state that the programmer cant find the chip, even though our code appears to be running (a condition I failed to mention before, sorry) 

    Also, I have found no ref docs that suggest or imply that any external additional circuitry for "proper" function.

    W/R/T specifications:

    1.) Are there any rise/fall/hold times that need to be met for programming and/or reset function?

    2.) Where is the 47K pull up documented?  Is it supposed to always be there?  My testing indicates it inconsistent and when there more like 10 - 20K when there and >100k after some resets..  

    3.) What is the input voltage required for a logic low.  If as a GPIO, the spec is strangely written.  It appears that it could need to be pulled all the way to 0.00 volts before it will change. Can you clarify this spec please?

    Finally, do you have any ideas why the chip wouldn't be recognized by the programmer?  The only way I can recover is to hold power low on the board until just after the program command is initiated.  Sometimes ot takes several attempts before successful programming occurs.

    Thanks again,

    Robin @ TL 

  • It's difficult to remember all the quirks on the nRF51-series, it's been a while. But I do remember that if the chip entered system OFF state that would make the debug interface inaccessible, also make sure to write to the NRF_POWER->RESET register to enable pin reset in debug mode in start of main(). 

    The pull-up resistor value is not documented anywhere, but I do believe it is around 47kohm, it could also be that it was 13kohm, but I think it was reduced on the nRF52-series. How did you meausure the impedance? Did you simply power the chip (VDD) and connected an ampere (I) meter between nRESET and GND? Then the pull-up resistance should be simply ohms law R=VDD/I.

    The max clock frequence is a trade off between drive strength and capacitance, up to 4MHz works in all corners, but you may consider reducing this if you add additional circuitry to the board and you see that verification fails. There is a simple data and clock signal here, so either it works, or you need to reduce the clock frequency, you will be in any case running verification afterwards, so it will not affect the data integrery of the programmed data in any way if verification pass.

    The logic low and logic high is <0.3*VDD and >0.7*VDD, if it's between these two values we can't really guarantee if it's logic high or low. To trigger pin reset the nRESET pin should be pulled low for minimum 0.2us in normal mode and minimum 100us in debug mode.

    I have heard very little problems of programming the nRF51-series, other than the possible problem with system OFF and pin reset not enabled in debug mode mentioned in the start her. So if you need more exact electrical parameters for the SWD interface I would need to contact the designers.

    Best regards,
    Kenneth

  • Once again, Kenneth, pleasant regards,

    I tested pullup by resistively pulling down the pin and back calculating from pin voltage.  As mentioned, results varied as the chip was reset.

    I will definitely need more info on the SWD circuit specs to finish this interface design. Latest attempt/findings:

    An external 1K pullup added.  Cleaned up connection transient, but still resets chip when connecting (but not disconnecting)

    An external 1000 pF cap from nRESET to ground:. No connection/disconnection resets.  Programs/debugs from IDE, but not from jflash production programmer.  Core ID wrong, returns as FFFF.

    Next WAG attempt will be to decrease filter cap to 100pF. 

    I sure hate playing the guessing game, so please with all due urgency, speak with the SWD designers, or anyone else that might be able to shed enough light for me to reliably interface this pin to a connector.

    FYI, I this essentially a deprecated device, and I have advised updating, sorrowfully to no avail.  I am told thus must be the first of the product line to go to market.

    Once more, gratefully,

    Robin @ TL 

  • Robin said:
    An external 1000 pF cap from nRESET to ground:. No connection/disconnection resets.  Programs/debugs from IDE, but not from jflash production programmer.  Core ID wrong, returns as FFFF.

    I will try to get more information from the designers. Just to quickly comment on the above; This do sounds as the jlink flasher is using higher clock speed than when programming from the IDE. Can you try with lower clock speed, e.g. 1MHz. If it still fails it sounds to be related to the drive strengt of the programmer.

    Kenneth

Related