Is it possible to enter an illegal KL03 16 bit SPI mode?

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

Is it possible to enter an illegal KL03 16 bit SPI mode?

Contributor V

I will firm up the question as people respond ... as I'm not sure what I am looking at on the scope.

I am in need to make a 16 bit SPI transfer with a peripheral device.  I have successfully created code to do this natively  using the KL17 which can handle both 16 bit and 8 bit SPI transactions.  But I must also run this code on a KL03 processor.  However, the KL03 only has 8 bit SPI transaction support.  So, after adjusting my code it is working great!

Then comes the part I can not explain.

Every once in a while I get interrupted and need to abandon my SPI transaction.  I bring up the SPI CS line and lower it for the new transaction.  That should prepare the peripheral device.  I send out the 16 bit SPI message as 2 8 bit SPI messages.  And all looks well.   Except after several minutes, the SPI bus gets into a non-functioning mode.  The SPI clock under KL03 HW control goes low, says there for about 6 bit cycles, then toggles out 16 pulses.  But with no apparent pause between the 1st and 2nd group of 8 bits!  It's almost like the KL03 is operating in some illegal 16 bit SPI mode.  I say illegal because the KL03 is not supposed to have a 16 bit SPI mode.  This goes on and on for 1000s of failed SPI transactions. (I should add that because I am synthesizing a 16 bit SPI transaction, that I need to control the SPI CS in software.  And that the SPI SC falls before the SPI Clock falls.  But, my code, based on SPI status bits getting set by the KL03's SPI HW circuits, assumes to have received 16 bits of data before I see 16 SPI Clocks on the scope.  So the SPI CS line appears to go high prematurely on the scope.)

If that is not bad enough, here's the bit I am really confused about:

All it takes to fix this SPI problem, is to pause the IAR debugger then hit continue.  No reset required!

From then on, the SPI transactions are good.  Well, at least for the several minutes until the next SPI lock up.  And by normal I see the SPI CS drop followed by the 1st 8 bits followed by a pause followed by the 2nd 8bits followed by the SPI CS rising.  Just as expected.

Anyone have any ideas?  Anything that I could try?


Tags (2)
0 Kudos
1 Reply

NXP TechSupport
NXP TechSupport

Hi Rick stuart,

   1. Please add 10K external pullup resistor in the CS pin, then do the testing again.

   2. Please add some SPI waveforms about the issue.

   3, Please post partial code about your 2*8bits SPI code.

   4, don't add the debugger, just download the code to your chip, and test without the debugger.

Waiting for your reply!

Have a great day,

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

0 Kudos