LPSPI_DRV_MasterTransferBlocking misbehavior

[m_mishrikey]

I had LPSPI working fantastically, then I went and refactored my code.  It  is now broken, and I am unable to figure out what happened.

The code is pretty simple.   

Some clues - 

1) If I try to send one byte, it sends 7, then clock is stuck high and PCS0 is stuck low:

2) If I try to send three bytes, it only sends one.  Clock again stuck high and PCS0 is stuck low:

I did manage to get a screenshot when it did work:

Grateful for any troubleshooting ideas!

[Senlent]

Hi@m_mishrikey

regarding the transferByteCount settings,

This may be caused by the transferByteCount setting,

Usually Bits/frame is fixed, you can try to set transferByteCount to 3, if you want to send one byte,please try fill the remaining two bytes with 0 and test it again.

[m_mishrikey]

Regarding transferByteCount, I am able to successfully change the byte count from message to message.  So for example in the screenshot I sent, the first message is a single byte, D8, and subsequent ones are triplets.  This seems to work very well.  

[m_mishrikey]

I changed it to this:

uint8_t tx_buf[3];
uint8_t masterDataReceive[3];

lpspi_state_t masterStateSPI0;
LPSPI_DRV_MasterInit(SPI0, &masterStateSPI0, &SPI0_MasterConfig1553);
LPSPI_DRV_SetPcs(SPI0,LPSPI_PCS0,LPSPI_ACTIVE_LOW);

holt_6135_reset();

tx_buf[0] = enMAP1;  tx_buf[1] = 0x00; tx_buf[2] = 0x00;// send D8
LPSPI_DRV_MasterTransferBlocking(SPI0, (uint8_t *)&tx_buf, (uint8_t *)&masterDataReceive, 3, SPI0_TIMEOUT);

tx_buf[0] = FASTREAD(10); tx_buf[1] = 0x00; tx_buf[2] = 0x00;		// Read register 0x000A (10)  =  send 28
LPSPI_DRV_MasterTransferBlocking(SPI0, (uint8_t *)&tx_buf, (uint8_t *)&masterDataReceive, 3, SPI0_TIMEOUT);

and when it sends the first message it does only send the first byte.  It's not followed by the nonsense bytes, but it's also not followed by two zero bytes despite the 3 in the transferbytecount.

Very confused.  When I had it working, on the first message I was able to send a one byte frame followed by three byte frames:

[Senlent · Accepted solution]

Hi@m_mishrikey

The clock line of the first picture is terminated for some reason,and I don't see any problem with the code.

Maybe add some delay before sending, and try to increase the timeout value of sending.

[m_mishrikey]

Delay didn't help. I also tried changing the timeout to something much longer, and even OSIF_WAIT_FOREVER. No luck.

Something really bizarre.  Is the clock line termination an indication of a problem on the SPI Master (S32K148)?  Or could the slave be misbehaving?  According to the slave datasheet the clock is an input only with 50k pull-down.  

Tomorrow I will try to start a blank project from scratch.  Maybe I can narrow it down to being a hardware or software issue.

Thanks for your suggestions.  Will let you know if I find anything.

[m_mishrikey]

I was able to fix this problem by starting a new project from scratch.  I never figured out the root cause.  I diff'd the source code and the generated code, but did not see what the difference was.

I'm not sure if it's possible, but maybe there was something corrupted in the compiled output?  Oh well.