SPI get stuck on MQX 4.2 and K66

[ohadbenjamin]

Hello all,

I am in the process of porting our application from K60 to K66.

We are using MQX 4.2 and I have encountered a problem with the SPI.

In order to get our application with MQX 4.2 working on our board I had to set the OSC0 clock source (EXTAL0) to a 50 MHz clock instead of a crystal and to change the PRDIV value to divide by 5 to make the clock between 8 and 16 MHz at the PLL entrance and than set the VDIV to 24/36 for RUN/HSRUN modes.

Like in the MQX SPI example, we have a NOR Flash connected to SPI2 and after a few reading and writing cycles it gets stuck at the following code segment where the semaphore is never released:

    if (rx_len)     {         /* finish the transfer using ISR */         dspi_info_ptr->TX_BUF = txbuf;         dspi_info_ptr->TX_LEN = tx_len;         dspi_info_ptr->RX_BUF = rxbuf;         dspi_info_ptr->RX_LEN = rx_len;             /* enable interrupt and wait for ISR state machine to finish the job */         dspi_ptr->RSER = DSPI_RSER_RFDF_RE_MASK;         _lwsem_wait(&dspi_info_ptr->EVENT_IO_FINISHED);     }

Attached is a zip file of the files based on the example code that shows how the SPI gets stuck.

Message was edited by: Ohad Benjamin I updated the spi_test.zip file

Original Attachment has been moved to: spi_test.zip

[cwati]

I also have the same exact problem on K22F, using SPI2, and MQX 4.1.  Ohad's solution fixed the issues.  Thank you so much!!

[Carlos_Musich]

Hi Ohad,

Is this code inside an interrupt? As you can see in MQX Reference Manual that function shouldn't be called within an interrupt.

C:\Freescale\Freescale_MQX_4_2\doc\mqx\MQX_Reference_Manual.pdf

Regards,

Carlos

[ohadbenjamin]

Which code are you referring to?

The code I attached is of an MQX application with a single task.

The code I quoted in my post is a part of the MQX SPI driver...

[Carlos_Musich]

Sorry Ohad,

I did not notice that you pasted the code form the driver.

Have you been able to reproduce this behavior in one of our TWR boards or it just happens in your custom target? I will try to reproduce.

Carlos

[ohadbenjamin]

Hi Carlos,

Were you able to recreate the issue?

I have not received any update from you and this is a blocking issue for our team.

[Carlos_Musich]

Hi Ohad,

As I commented in the Service request you submitted, with MQX4.2.0.2 I did not see this problem.

Regards,

Carlos

[ohadbenjamin]

Hi Carlos_Musich​,

As I wrote in the service request the fact that you used MQX 4.2.0.1 may be the reason the you did not see the bug indeed, but not because it was resolved.

The patch does not change any code in the SPI driver.

As I wrote in my original post the problem disappears, if the code is changed by even a single line of code such as the print.

This indicates a memory leak problem or a timing problem which may appear later on in a larger application and is simply not being reproduced with the current application because you made a change to the code.

Please use the MQX 4.2 with not changes to see the bug.

[Carlos_Musich]

Hi Ohad,

This is already reported to MQX team.

Workaround is to use 2Mbps.

Regards,

Carlos

[ohadbenjamin · Accepted solution]

Hi Carlos_Musich​,

I think I found a workaround for this bug.

I think that setting the following in the user_config.h will work.

#define DSPI_FIFO_DEPTH 1

The reason is that the default value is 4 while only SPI0 has a FIFO depth of 4.

I use SPI2 which has a FIFO depth of 1.

[ohadbenjamin]

Hi Carlos_Musich​,

The 2 Mbps workaround doesn't seem to work for me.

[ohadbenjamin]

I updated the zip file with the sources to a version that works better and better illustrates the problem.

To use the sources simply copy them over the MQX SPI example.

There is a print at line 280 in main.c which when removed resolves the problem and when it is there the problem occurs.

[ohadbenjamin]

Hi Carlos,

Yes, I was able to reproduce this issue on a TWR board.

In fact, since I am porting my application from K60 to K66 I tried reproducing on both TWR boards (K60 and K65).

On the TWR-K60 I could not reproduce it while on the TWR-K65 it was easily reproduced with the code I attached above and with the code I attached to the service request I opened.

An important note is that the problem disappears if lines of code are added to the application which suggests either some timing issue or a memory leak in the SPI driver.