RFDF gets stuck on, putting program into infinite loop

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RFDF gets stuck on, putting program into infinite loop

1,097 Views
dave_harmonjr
Contributor III

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.

Labels (1)
0 Kudos
7 Replies

930 Views
dave_harmonjr
Contributor III

Adding a few more details.

The code in question is the evalzones function in the adccontrol.c file. I put flags on it to make it so it wasn't constantly spamming the SPI bus and it seems to have worked for now. I am not sure if it is just delaying the error from occurring.

0 Kudos

930 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi David, I hope you're doing well!

 

The flags could help in minimizing the possible SPI use. The issue your facing could be related to the way the Serial Manager was initialized for your new interface.

Could you please take a look at this document here? It shows how to setup and use the Connectivity Framework's Serial Manager, enabling a second interface to work alongside the default set interface.

 

Please let me know if you continue to have issues.

 

Best regards,

Sebastian

0 Kudos

930 Views
dave_harmonjr
Contributor III

So more interesting details.

I put flags on the different states so it's not repetitively setting the state of an led via SPI. But I am still getting that error. I started commenting lines out one by one and testing that task that executes several ADCs scans every 300ms (it uses GPIO to cycle through an analog multiplexer). I found that the GPIO_WritePinOutput function is causing the problem. If I comment out all of those lines the SPI bus works correctly. Is there a problem with using multiple tasks to call this function? Even if they aren't using the same pins?

I checked out that document and it appears I am using it correctly.  

0 Kudos

930 Views
dave_harmonjr
Contributor III

I dug deeper and discovered that there is a configuration for SPI Master Data Available Pin and it is set to my ADC pin (PTB1). So when I write the GPIO to active the MUX it causes a 2.1V on the ADC pin which is read from the SPI ISR as there being data available. Thus causing an infinite loop. I need to figure out how to disable this now as I have no slaves notifying me of data on this custom board.

0 Kudos

930 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi David,

 

Could you please let me know how is the Pin MUX being configured? Are you using ALT0 for functionality of your pin?:

 pastedImage_1.png

 

Are you still getting the constant interruption?

 

Please let me know if you are still having issues with the SPI configuration.

 

Best regards,

Sebastian

0 Kudos

930 Views
dave_harmonjr
Contributor III

Yes I was using ALT0 but the default project had a config for the ping to be an SPI Slave Data Available Pin which was causing it to get stuck on that when the code to cycle through the analog mux picked up a high voltage.

It was resolved by commenting out that code.

0 Kudos

930 Views
Sebastian_Del_Rio
NXP Employee
NXP Employee

Hi David,

Please let me know if you have any further issues.

Best regards,

Sebastian

0 Kudos