Can somebody point me to exact changes to SPI (MQX) driver from 3.8.1 to 4.1.1 ?

[nitinharish]

I can see the low level driver code changed a lot bw the 2 MQX versions.

Previously, SPI was declared as polled or interrupt driven but now we cannot change that and looks like using DMA or Not, also needs to be configured.

Can somebody point me to the exact changes that have happened.

I have upgraded my 3.8.1 code to 4.1.1 and SPI drivers seem to be all messed up.

[LuisCasado]

Hello,

From 3.8.1 to 4.1.1, there have been 4.0.0, 4.0.1, 4.0.1.1, 4.0.2, 4.1 and 4.1.1. (If I remember well) Every release adds in the release notes doc, what's new from the previous release.

I am attaching here the release notes 4.0.2 because includes the changes "What is new” and "Change log” from 3.0.

Then, you can check the changes in 4.1 and 4.1.1 in the section "What is New”.

Regards,

Luis

[Tim562]

Hi Louis,

     As a developer who is using the Freescale MPC-5125 processor, the latest revision of MQX I am able to use is 3.8.1.1. I have not been able to find a place on the Freescale website to download the revision notes for all of the versions. Thank you for including the three you attached to your post, but do you know of a link where I can download all the MQX release notes and keep up to date as new revisions are released? Thanks

Best Regards,

Tim

[RadekS]

Hi Tim,

Please go to MQX page – Documentation tab

Or simply use this link http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MQX&tab=Documentation_Tab​

... and select Supporting Information type of documentation…

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[RadekS]

In fact, we do not modify SPI driver. Instead of that we created new SPI driver and the old-one we renamed to SPI legacy. SPI legacy stay in MQX for backward compatibility with some old platforms.

If you use Kinetis, I would like to strongly recommend new SPI driver.

DMA/Interrupt/pooled mode could be selected by definitions in user_config.h file.

[nitinharish]

Please help me explain the situation I am in:

I have updated MQX3.8.1 to MQX4.1.1 (for MK60DXVMD10 processor). My K60 is connected via SPI2 with a CML modem processor.

My SPI bus clock was running at 1MHz with MQX3.8.1 and now with MQX4.1.1 my CML modem just reports its transfer queue being empty but If I set SPI2 channel to 5MHz, things are OK again.

To me it smells like a timing issue with MQX4.1.1 SPI drivers.

I am NOT using DMA and my SPI settings are right out of MQX4.1.1 box except baudrate (which I had to play around).

Any suggestions ?

Thanks and Regards

Nitin Harish

[RadekS]

Default baudrate parameter is defined in init_spi.c file (for example 10MHz).

In fact, total time overhead of new SPI driver is much smaller than in legacy SPI driver case. It is possible that real 10MHz is too high baudrate for your CML modem.

Anyway, I would like to recommend check real baudrate value after you try set new baudrate value.

[nitinharish]

I tried using DMA on my SPI channel. This resolved the issue but now I see the following: 5.25 DSPI issues related to the DMA usage

"

DSPI issues related to the DMA usage

When the DSPI uses the eDMA, it may transfer data incorrectly or fail when eDMA is used for another purpose. If the DSPI

driver is the only user of eDMA, it should operate correctly. This behavior is a result of the silicon design of the DSPI. DMA

usage can be disabled in the DSPI driver by redefining the macro BSPCFG_DSPIx_USE_DMA to 0 in user_config.h."

How do I ensure DSPI is the only user of eDMA ?

[RadekS]

For MQX 4.1.1: eDMA is currently used only by SPI driver. If you don't use it for anything else, it should work. Problem is here only with 8bit tranfers at some older specific silicons and unfortunately MQX SPI driver doesn't contain workaround for that.  

[nitinharish]

Thanks RadeS.

I am using K64 for another project, and I saw Section 5, page 9 that eDMA (http://cache.freescale.com/files/soft_dev_tools/doc/support_info/MQXTWRK64RN.pdf) cannot be used on SPI1 and SPI2.

But my board is designed and built to use SPI2, any workarounds ?

[RadekS · Accepted solution]

Unfortunately this is different issue and it has nothing to do with my previous answer (issue with 8bit access to DMA is also related to K64 chip).

Described issue with the same DMA for TX and RX channel is caused by hardware configuration directly on chip.

Unfortunately there isn’t any workaround except don’t use DMA for SPI1 and SPI2 and potentially complete rework of SPI driver and linking change (currently it is not on TO-DO list).

Third SPI issue at K64 is based on problem with FIFO depth. SPI1 and SPI2 FIFO size is just 1 (effectively like without FIFO, see "TX FIFO size" and "RX FIFO size" chapters in reference manual). Unfortunately current SPI driver cannot distinguish between SPI modules and FIFO depth must be specified according used SPI module with smallest FIFO size. So, if you use SPI2, please edit spi_dspi_common.h file and change

#define DSPI_FIFO_DEPTH 4

to

#define DSPI_FIFO_DEPTH 1     

[小勇邹]

Dear RadekS,

Both the SPI0 and SPI2 are used in my application. The SPI0 works in DMA mode and the SPI2 works in interrupt mode. Is it necessary to

change

#define DSPI_FIFO_DEPTH 4

to

#define DSPI_FIFO_DEPTH 1 ?  

[RadekS]

Hi Robin,

it depends on your MCU.

If you use Kinetis K64 and any of SPI1 and SPI2 modules, please set DSPI_FIFO_DEPTH to 1.

Otherwise please check your MCU reference manual for FIFO depth of SPI0 and SPI2 modules.

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[小勇邹]

Dear RadekS,

Thank you very much.

I have a question to ask you.

The K64+MQX4.1 SPI0 is used as mater and itworks in DMA mode.

The KL02Z SPI0 is used as slave and it works in interruptmode.

The slave receive the data correctly. But it cannot send out the data and
it can only send out one bytes. I debug it and find that “the SPI Transmit
Interrupt Enable” is set, the “SPI Transmit Buffer Empty Flag” is always 0(not
empty) and “SPI Read Buffer Full Flag” is always 1(full) after putting data to
the data register. The SPI0 CLK signal from the mater is normal. It seems that
the data is not got by the master. Can you tell me what the reason is? Thank
you very much.

[RadekS]

Hi Robin,

could you please place here your code for obtain data from SPI slave?

You can use something like:

    /* Read size bytes of data */

    result = fread (data, 1, (_mqx_int)size, spifd);

    /* De-assert CS */

    fflush (spifd);

if (result != size)

    {

        printf ("ERROR \n");

    }

Where data is pointer to your receive buffer (unsigned char *data) and size is number of bytes that you want receive.

Please check also generated CS signal and compare it with your KL02Z code expectation.

[小勇邹]

Dear RadekS,

Thank you very much for your help.

I do some test cases. The master is MQX4.1+K64 and the slave
is KL02Z. The SPI2 of master is used in the interrupt mode.

Case 1: The SPI works normally if
connecting the slave CS pin to the master CS pin.

The reading source code example in the K64:

         
UBYTE buffer_temp_1[31];

          
  for(int in_i=0;in_i<31;in_i++)

          
  {

                      
  fread (&buffer_temp_1[in_i], 1, (int)1, spifd_2);

                      
  fflush (spifd_2);      

          
  }

Case 2: If I connect the CS pin of the slave to GND and make
the slave always selected. The slave receives the data from the master
correctly. But it cannot send out the data .I debug it and find that “the SPI
Transmit Interrupt Enable” is set, the “SPI Transmit Buffer Empty Flag” is
always 0(not empty) after putting data to the data register. The SPI0 CLK
signal from the mater is normal.

Case 3: Change the source code in the K64 and connect the slave
CS pin to the master CS pin. The master also can only read one byte from the
slave.

The reading source code example in the K64:

UBYTE buffer_temp_1[31];

fread (&buffer_temp_1[in_i], 1, (int)31, spifd_2);

fflush (spifd_2);

The difference between the case 1 and case 3 is the CS
signal of the master. The CS signal is changing when reading each byte in the
case 1. But the CS signal changes to low when reading the first byte and
changes to high when reading the last byte in the case 3. It seems that the slave
KL02Z need the CS signal to change from high to low when sending out each byte.
Is it right? I must connect the CS signal of the slave to GND in my
application. Is there any solution for this case?

[RadekS]

Hi Robin,

Yes, your observation looks correct. Problem is probably in slave software or in selected communication mode.

From KL02 reference manual:

“When C1[CPHA] = 0, the slave's SS input must go to its inactive high level between transfers.”

So, only way how to transfer data with CS pin low is select transfer mode where C1[CPHA] = 1.

Of course, you have to set this mode on both sides (KL02 and K64).

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[小勇邹]

Dear RadekS,

Thank you very much for your help. Case 2 and case 3 working normally after changing the C1[CPHA] on both sides (KL02 and K64).

I still have a question.

Does the SPI communication support broadcast mode?

For example, the master select several slaves at the same time and then send a broadcast command to the slaves.

Best regards.

Robin Zou.

Robin-XiaoYong Zou

ABB Xiamen Low Voltage Equipment Company Limited

BU LPLS E&D China

No. 12-20,3rd Chuang Xin Road Xiamen SEZ,Fujian 361006 P.R.China

CN

Phone: +86 592 5767877

Telefax: +86 592 6038110

Mobile: +86 181-5089-3720

email: robin-xiaoyong.zou@cn.abb.com<mailto:robin-xiaoyong.zou@cn.abb.com>

[RadekS]

Hi Robin,

SPI itself do not specify any communication protocol for broadcast mode. It is just low level communication channel between master and slave. So, it depends on you how you will implement this feature.

In typical case we have one master and several slaves. CLK, MOSI, MISO signals are shared between all devices and master decide target slave by CS (SS) pins.

So, if you want send broadcast, you have to set active all (part of all) CS pins.

In case of MQX SPI driver you have two ways how to manage it:

1. You can generate CS pins by SPI module. In that case you will open SPI channel with more than one active CS signals. For example, if we will open channel “spi0:11”, CS0, CS1 and CS3 will be active during sending data trough this channel.
2. You can install CS callback and this callback you can drive CS pins according your needs. Advantage of this approach is that you are no more limited by number of CS pins and number of channel does not need fits to configuration of CS pins. For example, if we will open channel “spi0:99”, cs_mask parameter in callback told you that you should set configuration for channel 99. In that case you can simply set CS0, CS1 and CS3 as active during sending data trough this channel. When cs_mask parameter is zero, you should set all CS signals into inactive state.

So, there isn’t any limitation from SPI driver point of view.

Remaining limitation is only on electric side. In default solution, SPI works in full duplex mode – slave receives data from MOSI line and simultaneously sends data trough MISO line. The question is what happened when more than one slaves drives the same line with different voltage level.

So, broadcast could work only in case when we don’t connect MISO line (slaves just receiving) or we somehow protect output drivers by electric way (by disconnection, by wired-OR = open collectors,…)

Idea: In some cases, slaves allow serial connection. E.g. master output to Slave0 input, Slave0 output to Slave1 input, Slave1 output to Slave2 input, Slave2 output to Master input. In that case you can just serialize commands for all slaves and clocked out all together. However this option depends on SPI slave implementation…

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[小勇邹]

Dear RadekS,

Thank you very much for your help. The broadcast mode is OK in the SPI according to your advice.

The SPI2 interrupt mode is used in our application now.

But we want to use the SPI2 DMA mode in our application.

Is it possible to use the SPI2 DMA by modifying the SPI driver in the K64+MQX4.1?

If it is possible,we would like to buy the service for modifying the SPI driver.

Or is there a new OS version that support the SPI2 DMA mode for K64?

Best regards.

Robin Zou. 

[RadekS]

Hi Robin,

I am glad that it works now.

Yes, MQX SPI driver could be modified for safe DMA operations. It should be small changes however I am not sure whether these changes will not degrade all benefits from eDMA interface.

Unfortunately problem with DMA SPI at K64 isn’t based on MQX driver itself. It is rather combination of hardware issues and fact that this driver is older than K64 (it was not prepared for such configuration on hardware side). K64 DMA SPI issues:

1. SPI1 and SPI2 modules have shared DMA request sources for RX and TX.
2. There could be problem with 8bit transfers (eDMA supports 16- and 32-byte transfers) when SPI isn’t only one user of eDMA.
3. SPI1 and SPI2 has FIFO size(depth) just 1. DSPI driver is from time where all SPI modules at Kinetis parts have had the same FIFO depth (4).

I would like to note, that DMA has sense only in case of transferring some bigger data blocks, otherwise overhead for preparing DMA transfer will be inadequate to transfer time. So, if you transfer small chunks of data, interrupt driver is better choice.

Premium support channel for solution could be order from here:

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MQX_SUPPORT

Unfortunately I am not sure about “new OS version that support the SPI2 DMA mode for K64”.

In fact, Kinetis SDK contains different SPI driver which supports DMA. This driver could be used with MQX or other RTOSes in KSDK.

1. www.freescale.com/webapp/sps/site/prod_summary.jsp?code=KINETIS-SDK

This driver solves at least third issue – FIFO depth could be set per SPI module.

Unfortunately I am not sure how it looks with workaround implementations in driver for issues 1 and 2.

I will try getting more information from designers…

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------