AnsweredAssumed Answered

SPI Hang 4.1.0 FRDM K64

Question asked by Kenny Koller on Oct 16, 2014
Latest reply on Oct 17, 2014 by Radek Sestak

After many successful transfers SPI reads or writes will hang--apparently waiting on a semaphore (call stack included as attachment). I am not using DMA but the standard interrupt driver. SPI1 with CS0 and CS1. Another task is using the driver with the other chip select but I have disabled it for my testing.


Looking at the waveforms the last transfer performs the chip select and appears to transfer the requested number of bytes. When it hangs it is always in the same place. I'm using full duplex with the same buffer for TX'd and RX'd data.


I'm using 4.1.0 because the 4.1.1 cloning wizard has a bug that would not allow me to clone the K64 FRDM with IAR and I needed to press on. Any know issues with the driver? I've tried breaking up the transfers in to 8, 16, 32, and 64 byte chunks but the issue persists.


New Information:


I diff'd (Beyond Compare) the directories and found that the SPI driver has not changed between 4.1.0 and 4.1.1.


The semaphore never seems to post when the last of the data is received. I disabled the use of the interrupt to deal with the RX data (didn't dig deep enough to understand why this is) by not setting DSPI_ATTR_USE_ISR in the initialization structure. In this case the polling loop hangs so it seems that the RX flag that would trigger the interrupt or exit this loop is not being set. There is nothing in the errata regarding SPI.


Any thoughts as to why this would work most of the time?


Thanks,


Kenny


    _file = fopen(DEVICE_NAME, (char const *)SPI_FLAG_FULL_DUPLEX);


    // Sometime later and repeatedly.


    mqx_uint code = ::write(_file, _buffer, count + HEADER_SIZE);

 

    fflush(_file);

Outcomes