AnsweredAssumed Answered

RFDF gets stuck on, putting program into infinite loop

Question asked by David Harmon on Feb 28, 2020
Latest reply on Mar 10, 2020 by Sebastián Del Río

I am running a KW41Z with FreeRTOS. I based my project off of the BLE UART freertos project. I got rid of the uart components and used the serial manager for SPI to communicate with several chips on the custom board. Everything worked fine until I added a task that is triggered by a interval timer via an event every 300ms to scan with the ADC several times then send some SPI data based on the results. After somewhere between 30seconds and a minute or two the board stops responding. I debugged and found that the SPI is doing what I think is constantly reading bytes because RFDF is set. I set breakpoints in that function and normally it will go through that main loop  in static void SPIx_ISR(void) in SPI_Adapter.c


while(DSPI_GetStatusFlags(baseAddr) & kDSPI_RxFifoDrainRequestFlag)


and exit after its done reading in the byte or two. But after a bit it just gets stuck in there forever which locks up the whole program as its a high priority task.


I cannot figure why it's stuck in this state. It also appears that the SPICLK line is running while this is happening by itself. I only had a freq. counter to check this (getting an oscilloscope today).


Another thing to note is I am using the serialmanager from the connectivity framework. And that I am using Serial_SyncWrite then Serial_Read immediately after to flush out the buffer. I am not using my own callbacks for RX/TX as its just a Master/slave/slave/slave situation so I am never unexpectedly receiving data from the slaves.


Also another really odd behavior about it is that I have a switch on it, and that triggers through the GPIO ISR so it can break through that infinite loop to execute some code. When I press that switch before the SPI lockup occurs it works correctly, which cycles a tricolor led with gpio through some colors. After the lockup occurs it sets every LED on the entire board to be on. We hooked the SPI bus to a LED Driver that is a shiftregister. So this would indicate that the SPI bus is also loading the TX with 0xFF after the lockup by itself. GPIO still seems to work correctly.