I installed MQX 3.8.1 on my computer. I was surprised I had to overwrite 3.8.0.
I compiled the libraries for the K60 using the Keil compiler and then compiled my "Working" 3.8.0 application.
First thing I discovered was that the application was no longer reading or writing to E2 memory through SPI.
I debugged into the MQX codes and was surprised to see that the SPI code had completely changed.
The FULL_DUPLEX option was now required to read from SPI. I added the parameter to my fopen command and this still did not fix the issue.
I complied the libraries to work with the K60 tower kit and then compiled the SPI example code. This code did not work.
It printed the error messages that the data read back in did not match the data written.
We need to move to MQX 3.8.1 because we are about to use the K20 processor that is only supported in 3.8.1.
Here are my questions:
Has MQX 3.8.1 been tested with the K60 and Keil?
Why weren't the changes to SPI mentioned in the changes document?
Is there a work around to get my code working now?
When is an update to 3.8.1 going to be available.
Please try replacing corresponding files in mqx\source\io\spi and mqx\source\io\spi\polled with the attached ones and let me know whether it solved the issue. The attached files include fix for possible RX overrun at higher baud rates. Thank you.
I have just tested 3.8.1 with the sources replaced as I posted in Keil (4.53).
The SPI example supplied with 3.8.1 works for me without any problems, both debug and release target.
I tested the example on TWR-K60N512 with TWR-MEM.
Could you, please, be more specific and describe your issue in detail?
I figured out that that acutal issue was with more than one time on the SPI.
The new 3.8.1 code was not correctly clearing a flag when the chip select was cleared.
Freescale has fixed the issue for me and sent replacement code.
The main reason the SPI driver was rewritten was to improve performance. There are further changes on the way for upcomming MQX releases.
We tested the driver on K60 and it worked fine, however later on was discovered that there is a possibility of RX FIFO overrun - this is already fixed in our development sources.
Concerning FULL_DUPLEX flag - it is definitelly not necessary to use this flag for reading from SPI, please double check the sources, the code after condition involving this flag is dealing with TX buffer during read operation, but it does not prevent data to be read from SPI.
Another possible source of issue you experienced might be slow peripheral - the SPI driver is now several times faster so there is a possibility that the peripheral is not ready if your code relies on fact that communication is slow enough to not check for completion of previous operation (when e.g. writing to serial flash).
We are going to do further tests on K60 and let you now about results and possible solution.