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

[Robin]

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 

[Kenneth]

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

[Robin]

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 

[Kenneth]

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

[Robin]

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

[Robin]

Hi Kenneth,

Here's the latest:

1.) I can indeed reduce the programming clock rate in both the IDE, and jProg applications.

2.) At 1 MHz both successfully program the chip.

3.) With filter caps on both the SWDIO and SWCLK pins and each pin respectively pulled up/down by 1K, things are greatly improved.  I have done this to 2 boards.  An older board with a chip code ending in 1, and a newer board with a code ending in 3.  The boards behave a bit differently.

4.) The board with the older chip does not reset when connecting/disconnecting.

5.) The board with the newer chip resets about 1 in 5 connect/disconnects.  I suspect this may actually be a connector problem, but that is difficult to prove/disprove.

6.) We can live with the reset rate so long as it never corrupts code, which was the original problem. 

7.) To test this I have downloaded the latest nrfjprog to verify flash between resets, however I cannot get the program to work.  I have another case open to try to helo resolve this.  Please have a look at case 274972 and let me know what your thoughts are.

8.) Finally, one last unknown: When a hard reset happens via the nRESET pin, is flash protected, or is there a way to detect the reset and do so?  There are flash write in our code, but very seldomly performed.  

With the specs you are chasing on the SWD  interface and help on 7 and 8  I think we could wrap this up.  Whatever you can do is greatly appreciated.

Gratefully,

Robin @ TL

Kenneth,

Here my proposed "Program Enable" circuit.  Can you find any reason this should not allow the chip to be initially programmable, and then re-programming enabled/disabled as needed afterwards?

Thx

Robin

 Program Enable.pdf

[Kenneth]

Hello again, 

Some quick comments below, I have asked the designers if they can provide more electrical parameters for the SWD interface.

For test 4 and 5, is this programming cable or charger? I don't expect testing with a programming cable is a realistic test for the end product, though I can understand that a reset when plugin the charger is a problem.

7. Each nRF command line tools release is tested with a specific segger j-link release, so mixing with a different j-link version can cause problems yes.

8. Causing a pin reset during a flash write or erase operation I would assume can be problematic yes, I don't see any way to easliy work around this other than try to avoid it by design (e.g. filter on nRESET like you already do).

Kenneth

[Robin]

Hi Kenneth,

With regard to charge/programming cable, they are both the same type USB-A to micro-USB.  We jave custom Segger interface board to implement that interface.  Reset plugging into programmer is not a test, just a noted similar response.

Are different release versions of the NRF available for download?  I did not see them if they are, and the tool version is not the same as the Segger dll version.  Can you tell me which tool version aligns with the Segger dll I have?

Thx

Robin @ TL