LPC2114 revision /01 SPI1 SPIF failure

[aerobaticant]

We have been making a product using the LPC2114 (64 pin TQFP) for 5 or 6 years.

Recently we built a new batch that now uses the /01 silicon revision.

We are now getting problems with the SPI1 interface. The units will work correctly for several hours, using SPI1 to poll external devices, and then for no apparent reason the SPIF flag fails to get set at the end of a SPI transfer. This causes a watchdog reset, however the SPIF flag continues not to work unless the power is disconnected.

Anyone seen this before?

[aerobaticant]

Hi Carlos,

I can confirm we're not modifying the SPI registers while running. We are only using SPI in a polled mode:

void spi_exchange_1(uint8_t *txbuf, uint8_t *rxbuf, uint32_t len)
{
    uint32_t i;

    for (i = 0; i < len; i++)
    {
        S1SPDR = *txbuf++;
        while (!(S1SPSR & SPI_SPIF));
        S1SPSR;
        *rxbuf++ = S1SPDR;
    }
}

I have already tried adding an extra read of the S1SPSR status register followed by a read of the S1SPDR to check for and clear ABRT, MODF, ROVR and WCOL before writing to S1SPDR to initiate a transfer. It is once the transfer is initiated that SPIF fails to be set some times.

The only interrupts we are using are for UARTs. At the time of failure, no UART communications are occurring.

In the errata the spurious interrupt issue appears to manifest itself as a reset. This is not what we are seeing. It is only the SPIF flag in SPI1 that is failing to set causing the loop to never end.

As I stated, the SPI0 port appears to work perfectly, we're only having this issue with SPI1.

The exact same code running on an older silicon revision also does not exhibit the problem - this has been shipping for over 5 years without issues.

[Dezheng_Tang]

Maybe try two things:

(1) Most of the bits in PSR will be cleared by read PSR only or both read PSR and

access to data register or write to control register. Can you make minor change as  

below? A simple read like you did will clear and erase all the evidence, we need to figure out

a way to log the events in between.

(2) Can you probe all the signals, CS, CLK, MOSI, and MISO and see if anything unusual when

failure occurs? This SPI IP is a very simple block and this MCU has been out for 10+ years. It's

hard to believe there are H/W issues inside this IP.

int psr_value, error_value[200], err_count;

for (i = 0; i < len; i++)
    {
        S1SPDR = *txbuf++;
        while (!((psr_value=S1SPSR) & SPI_SPIF));

        if ( psr_value & 0x78 )  {                      /* If any of error bit set, log it. */

          error_value[err_count++] = psr_value;

          S1SPSR;

        }
        *rxbuf++ = S1SPDR;
    }

[aerobaticant]

Hi, referring to my original post, reading the S1SPSR value won't help since when the fault occurs the code will hang in the while loop and the results will not be not accessible.

Probing the SPI signals hasn't helped since the interface works fine for several hours, doing may thousands of successful writes and reads, and then mysteriously the SPIF flag fails to be set.

We have had products working perfectly with exactly the same software for over 6 years.

This problem has definitely been introduced with the revision /01 silicon.

In the /01 version an SSP interface was added, sharing the SPI1 pins.

Also SPI 16-bit transfer widths were introduced so the silicon has been changed.

To catch the error we have to leave units running overnight.

ALL /01 based units we have tried have shown the problem. None of the earlier suffix-less based units show the problem.

As we have customers screaming at us, I have now had to implement a software bit-banged interface for SPI1.

This is not ideal as there is a significant performance overhead.

PS: here are the read back values:

PCONP:    0x00001FBE   (default reset value)

PINSEL0:   0x00055505   (using UART0, SPI0 and UART1)

PINSEL1:   0x000006A8   (using SPI1 and PWM5)

[CarlosCasillas]

Hi Ant,

Based on the additional details, it will be further investigated internally. We will post an update as soon as having news.

Best regards!

/Carlos

[CarlosCasillas]

Hi Ant,

An additional internal comment regarding this issue is the following:

Please try using biggest value of MAMTIM and see if it is improved. Also please try to add some delay after data write and before data read.

        S1SPDR = *txbuf++;

       while(i++<4) {asm(nop)}; // wait for some time

        while (!(S1SPSR & SPI_SPIF))

        S1SPSR;

       while(i++<4) {asm(nop)}; // wait for some time    

        *rxbuf++ = S1SPDR;

Please update us the result. If still has issue, please let us know the chip maskset including the chip picture.

Hope this will be useful for you.

Best regards!

/Carlos

[Dezheng_Tang]

Correction:

In page 212,

"Note: A read or write of the SPI data register is required in order to clear the SPIF status bit. Therefore, if the optional read of the SPI data register does not take place, a write to this register is required in order to clear the SPIF status bit."

Since your code does a dummy read already, no need to do read PSR again after logging the error.

Can you read out and post both SPI0 and SPI1 register value, in addition to that, your PINSELx and PCONP register value once you have further questions?

[aerobaticant]

Something says this has branched to a new discussion (thread 456648) but I can't follow the link - I get "unauthorized".

Please help as we have unhappy customers!

[CarlosCasillas]

Hi Ant,

The branch was indicated because I internally escalated your issue. Below you can find some replies:

Could you please verify if the code is not modifying the SPI registers while it is running? It may cause the SPI-related errata described at the document of the link below:

http://www.nxp.com/docs/en/errata/ES_LPC2114_24_00.pdf

Additionally, please check the following:

(1) If you do a master write, you want to pay attention to WCOL bit, if read, check ROVR bit. Basically, if SPIF is not set. All error related bit 3~6 need to be checked first.

(2) If you use interrupts, on LPC214x, we still have the spurious interrupt issue. An application note about how to handle it that can be found at the link below:

http://www.nxp.com/docs/en/application-note/AN10414.pdf

Hope this will be useful for you.
Best regards!
/Carlos
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------