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 

Parents
  • 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

  • Hello yet again, Kenneth,

    I dont think it drive strength, since both programa us the same hardware.  I am not aware if clock speed can be changed from within the jprog software, but I will look.

    Yet again, 

    A resounding thank you

    Robin @ TL

Reply Children
No Data
Related