LPC804 stuck in boundary scan after reset

[jforslof]

We have encountered a problem where a low level on PIO0_3 prior to external reset risks placing the LPC804M101JHI33 microcontroller into a mode where the output state of I/O pins above PIO0_5 is inaccessible from software.

Inaccessible pins behave either as sources, sinks or high-impedance inputs independent of GPIO, IOCON or PINENABLE configuration while digital input continue to operate normally. Reset does not recover normal operation.

The occurs intermittently across multiple devices and leaves the product in a state where power-cycling by disassembling the device is required for recovery. 

I request help in establishing the root cause of this issue and assessing potential workarounds. Thank you in advance for your assistance.

Reproducing the problem

A minimal and self-contained repro case which exhibits this problem has been attached. This code operates by:

1. Disabling pull-up and hysteresis on PIO0_3 (TCK/SWCLK).
2. Waiting for the pin to settle.
3. Looping by pulling down PIO0_5 (RESET) to generate a reset.

This causes PIO0_3 to slowly float towards ground. The fault occurs on crossing the ≈1.6V input threshold and at which point the digital input state is unstable due to the lack of hysteresis.

The actual target system disables SWD and sinks PIO0_3 (TCK/SWCLK). The fault is intermittent and difficult to reproduce in a lab environment in this configuration.

Additional findings:

• No abnormal supply voltages or other electrical deviations have been observed.
• SWD debugging operates normally after a fault.
• The fault does not occur if PIO0_3 is pulled high prior to the reset.
• The fault does not occur if SWCLK is disabled via PINENABLE0 prior to sinking PIO0_3.
• The fault occurs on the first edge and not if PIO0_3 is subsequently toggled during operation.
• Timing of the PIO0_3 reconfiguration and reset has no observable effect.

Traces

The below trace shows a test run from power-on. The fault can be seen where PIO0_12 (ISP) becomes a sink. The device traps into ISP mode and stops on the next reset.

Figure 1: CH1 = PIO0_5 (RESET), CH2 = PIO0_2 (TMS), CH3 = PIO0_3 (TCK), CH4 = PIO0_12 (ISP)

The next trace shows the same failure mode with a narrower time base. The accelerated RESET rise after the fault is normal and caused by a capacitive coupling to PIO0_22 which has started sourcing after the fault.

Figure 2: 500µs time-base

The next trace shows PIO0_12 (ISP) going high impedance instead. The resulting pin resulting configuration is not consistent.

Figure 3: ISP high impedance

The fault also occurs on the rising edge of PIO0_3 (TCK) during reset.

Figure 4: Fault at rising edge

Analysis

The MCU is assumed to have entered JTAG boundary-scan mode since:

1. The inaccessible pins correspond to the boundary scan cells. The accessible pins correspond to JTAG control signals and REST.
2. The boundary scan exit procedure of sinking PIO0_4 (TRST) during and asserting RESET restores normal mode.

The TCK pulled-up is restored on reset and results in a rising clock edge after the falling edge of RESET. This is assumed to sequence the JTAG TAP.

The effect of the falling clock edge after releasing RESET is less clear. A guess is that a floating input without hysteresis induces oscillation which results in a timing violation or metastability and places the TAP into an unintended state.

Clearly the intent is that boundary scan should normally only be operated during RESET. This is variously described in table 314 and the top of section 28.5.3 of UM11065 rev 1.3.

The sequence for exiting boundary scan includes releasing TRST and implies that that it may be possible to remain in boundary scan after RESET:

“Once the boundary scan operations are completed, assert the TRST pin to enable the SWD debug mode and release the RESET pin” (section 28.5.3 of UM11065, rev 1.3).

This section includes the surprising statement that the TAP operates outside of RESET and disregards TMS:

“POR, BOD reset, or a LOW on the TRST pin puts the test TAP controller in the Test-Logic Reset state. The first TCK clock while RESET = HIGH places the test TAP in Run-Test Idle mode” (section 28.5.3 of UM11065, rev 1.3).

Regards,
Johan

[xiangjun_rong]

Hi,Johan,

Regarding your following code, I do not think that the following code can Reset the LPC804.

If you want to Reset the LPC804, you have to connect the LPC0_5/Reset pin to source which can set/clear the pin.

If you want to reset the LPC804 itself with software, you can write the SCB->AIRCR.

SCB->AIRCR|=1<<2;

Hope it can help you

BR

XiangJun Rong

// Try for another round by pulling down PIO0_5 to force an external reset

ldr r0,=IOCON_BASE

movs r1,#IOCON_MODE_PULLDOWN|IOCON_HYS_MASK|IOCON_RESERVED_MASK

str r1,[r0,#IOCON_PIO0_5 /* RESET */] b .

[jforslof]

Hello XiangJun,

Thank you for your interest.

As near as I have been able to determine disabling the internal pull-up on the RESET pin without an external pull-up resistor present does appear to work in my tests. As can be seen in the oscilloscope traces the signal drops and recovers immediately on hitting the low level threshold as would be expected, and afterwards code execution again reaches the start of the vector with EXTRST asserted.

Using a software reset via AIRCR instead fails to reproduce the problem. I suspect that this is related to JTAG boundary scan operating independently of normal peripherals during the reset state and based on the physical signal. Incidentally. Incidentally, I believe that a 0x05FA << 16 vector key is also needed for the SCB to accept a software reset request.

To be clear we are not relying on this method of reset in our actual application. This is used purely to demonstrate the problem. The original test case used an external reset pulse generator but doing so internally in the code simplifies the setup by avoiding the need for external test equipment.

Regards,
Johan

[jforslof]

Hello again XaingJun,

On reviewing the LPCXpresso804 I notice that the development board has an external pull-up resistor R17 on the reset line. Our design lacks such a resistor and the internal pull-down may not be sufficient to sink it.

Was this the issue which you were referring to?

I current lack access to this development kit but have these on order for verifying the repro. In the meantime I have updated the test code to actively sink the pin as a workaround, which becomes slightly complicated since the pin function must be temporarily released.

Alternatively it should also be possible to run the original test case using a source of external reset pulses, such as by repeatedly pressing the reset pushbutton. Note that this the test is non-deterministic and may require a dozen or so attempts before triggering the problem.

Coupling some external noise onto the reset signal may help, such as by probing the pin.

I apologize for any confusion caused.

Regards,
Johan

[xiangjun_rong]

Hi, Johan,

Pls refer to the following Fig. I think you can use on-chip pull-up resistor by setting the Mode=2 to pull the Reset(PIO0_5) as high.

Pls have a try.

BR

XiangJun Rong

[jforslof]

Hello XiangJun,

I am not certain that I follow your suggestion.

Our design uses this internal pull-up and we have not had any issues with this signal. Conversely since the use the internal pull-up it is also possible to enable the internal pull-down instead to simulate an external reset.

The initial repro software relies on this. If so then you may have had issues running it on the LPCXpresso804 development board include an external pull-up resistor. To help reproduce the problem in this environment I have updated the code to actively sink the pin, which should be sufficient to work on the LPCXpresso804 board as well.

I must stress that this is tangential to our actual problem though. The reset pin is only manipulated to as a convenient way of generating a stream of external resets. The problem is also reproducible using an source for externa reset pulses, such as using an external signal generator or repeatedly pushing the reset button manually. My hope was that making the test case self-contained without relying on external equipment would simplify your task of investigating the problem, if this is not the case then I would suggest disregarding this part of the code and using an external signal instead.

For what it is worth we are currently evaluating a potential workaround of resetting the JTAG TAP by generating a glitch-free TCK pulse on reset by temporarily inverting the pin via IOCON_PIO0_3 prior to using this signal. This would appear to prevent inadvertent boundary-scan entry at least in the repro configuration but it is less clear whether it addresses all cases possible in the original application.

Regards,
Johan