Weird Issue observed with Nrf52832

[VishnuGS]

Hello,

We have a custom board with nrf52832. We have seen a problem during production. Our process is as follows (the below steps are ran in a script),

1. We recover the board

2. We flash a HQ test application FW for hardware quality check

3. We run the test

4. We erase the board

5. We flash application FW

6. Enforce read back protection

7. Ship the units.

We received reports that Hardware quality checks are failing for lot of devices.

So, we took few of our production devices and ran the tests with it. 

Procedure 1:

As our production units have Application Firmware(with read back protection) loaded onto them already, we perform the above mentioned steps, the success rate is below 80%

Procedure 2:

We take the units, recover them and kept aside for 15 minutes, then we perform the above mentioned steps. The success rate is 100%

I could not understand the difference in approach of,

1. Having erased board when it powers up helps to pass the test always

2. Having App FW on it when it powers up -> recover it ->perform the test ->fails.

I have tried the following steps to understand the problem ( Having APP FW preloaded when device powers up)

1. Recover -> Recover -> reset -> Test -> fails

2. Recover -> eraseall -> reset ->  test -> fails

3. Recover -> Recover -> eraseall -> reset -> reset -> test -> fails

4. Added delays between steps to see no improvement

5. Assumed Script might have issue, So performed the manual steps using command line tools and Putty for serial -> fails

Specifics:

1. Main APP FW uses SDK 14.2 and SD S132 V5.0

2. Test FW uses SDK 13.0 and SD S132 V4.0.3

3. Our Custom Board has big bulk capacitors on them, so I chose to discharge the board (wait for 15 minutes as mentioned in procedure 2)

Even after we recover the board is there any way that Main APP FW has impact on HQ Test FW?

Can you help me understand 

Recover -> wait for 15 minutes -> Recover -> Flash Test FW -> Reset -> Test Run -> SUCCESS

Recover->Flash Test FW -> Reset -> Test Run ->Fails (20% failure rate)

Thanks.

[hmolesworth]

Something else to think about, pardon me if you already know this. Once the reset pin is actually working as a reset pin (more on this in a while) erasing all flash does not stop it being a reset pin until after a full reset takes place, either via the reset pin or power cycle or other. The Flash registers which control the pin are only read following a reset, so until a reset happens the fact that the registers are erased is not recognised.

Once the reset pin is no longer a reset pin (erase all, hard reset or power cycle) and you set it to be a reset pin (write to the Flash registers) it does not become a reset pin until after a hard reset which is of course not possible by using the reset pin (in this case). If using Nordic examples, setting the pin as a reset pin automatically generates the required reset in software, but if setting by other means then the pin won't reset until after some other reset.

That's basically what your option 1 is doing, but the reset pin might not be a reset pin depending on what you did earlier and so may not reset, for example if you do 2 recover reset cycles. So .. --pinreset might not, and what is --reset?