S32K DMA SPI - words transmitted out of order?

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

S32K DMA SPI - words transmitted out of order?

Jump to solution
2,061 Views
mikesfn
Contributor III

I'm using the S32K146 LPSPI with DMA to transmit data to an external flash chip. I'm having an issue where data transmitted from the DMA source buffer is transmitted out of order, and I can't figure out what the cause is. I don't have the code in front of me, but the process is pretty simply described as follows:


//Initialization DMA TCD[10]:

- SADDR points to global array of type uint16_t.

- DADDR points to LPSPI0_TDR register

- SSIZE and DSIZE both initialized for 32-bit transfers (b10)

- SOFF and NBYTES set to 4

- DOFF set to 0

- CITER and BITER both initialized to 1

//Write function

- DMA transfers stopped by writing to CERQ

- Wait until LPSPI TX FIFO is empty

- LPSPI0_TCR[FRAMESIZE] updated: in this example I'll say its 63 (for a 64-bit frame size) - continuous transfer is not used. No linking of DMA channels either.

- Data written to source buffer, example: {0x9000, 0x0, 0xFFFF, 0x0}

- CITER and BITER both set to 4 (4 * 16-bits = 64bit frame)

- DMA re-started by writing to SERQ

In this example, with the given input buffer {0x9000, 0x0, 0xFFFF, 0x0}, when CITER and BITER are set to 4 as in the description above, the data is transmitted with adjacent 16-bit words reversed ; [0x0, 0x9000, 0x0, 0xFFFF]

If I change the frame size to 48 bits and CITER/BITER set to 3, the output is [0x0, 0x9000, 0xFFFF]

I don't get what's going on. I assume I've got something wrong in the TCD initialization, but trying different combinations hasn't got me anywhere. For example, if I change SSIZE/DSIZE to 1 (16-bit transfer) and NBYTES/SOFF also to 2, the output is the same with the first 2 16-bit words transmitted in reverse order.

What could be wrong?

Labels (1)
0 Kudos
1 Solution
1,950 Views
mikesfn
Contributor III

Hi Diana, 

Thanks for the response. I am not using the SDK, however I think I have solved my problem. The issue was that I did not consider the byte-ordering of the source buffer. Since The TDR register is 32-bits, I have to use 32-bit transfers otherwise the unwritten bits get stuffed with zeros. However, since the source buffer is an array of uint16, when the DMA controller copies data, it puts the upper 16-bit word into the most significant bytes of the TDR. Hence buffer[1] gets transmitted before before[0]. What I did to solve the issue was to set the TCR[BYSW] bit in the LPSPI_TCR register to perform a byte-swap before transmission.

Thanks

View solution in original post

0 Kudos
2 Replies
1,950 Views
dianabatrlova
NXP TechSupport
NXP TechSupport

Hello Michael,

 

I'm very sorry for the delay.

Have you checked the error status register "18.4.5.3 Error Status Register (ES)"?

Could you share your code?

Do you use SDK or nor non SDK project?

Thank you.

Best regards,

Diana

0 Kudos
1,951 Views
mikesfn
Contributor III

Hi Diana, 

Thanks for the response. I am not using the SDK, however I think I have solved my problem. The issue was that I did not consider the byte-ordering of the source buffer. Since The TDR register is 32-bits, I have to use 32-bit transfers otherwise the unwritten bits get stuffed with zeros. However, since the source buffer is an array of uint16, when the DMA controller copies data, it puts the upper 16-bit word into the most significant bytes of the TDR. Hence buffer[1] gets transmitted before before[0]. What I did to solve the issue was to set the TCR[BYSW] bit in the LPSPI_TCR register to perform a byte-swap before transmission.

Thanks

0 Kudos