LPC54S016 SPI Slave DMA Repeated first byte

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

LPC54S016 SPI Slave DMA Repeated first byte

Jump to solution
2,456 Views
andrewsglenn
Contributor III

I've got an LPC54S016 set up as an SPI slave on Flexcomm 0 using the standard settings on the Peripherals setup page.

I'm sending a 512 byte packet of data from the transmitter to the LPC, and simultaneously transmitting a 512 byte packet back from the LPC to the transmitter.

The LPC is receiving the packet correctly, but when transmitting, it will occasionally transmit a duplicate of the first byte, and omit the last.

The packet transmitted from the LPC consists of the repeated string "fedcba9876543210"

This is what I'm receiving. As you can see the first byte is duplicated on the first packet, and not on the second:

andrewsglenn_0-1728582863422.png

I've checked the signal with a logic analyzer, and can see the repeated byte going over the wire, so it does seem to be generated by the LPC, and not an artefact of the receiver.

I found this problem regarding the K22, and wondered if the LPC54 series had the same problem, and if so what the solution is: https://community.nxp.com/t5/Kinetis-Microcontrollers/K22-DSPI-in-Slave-Mode-Sometimes-Has-Duplicate...

I tried clearing the TX and RX FIFOS in the DMA callback, and it didn't seem to do anything.

Any ideas?

Tags (1)
0 Kudos
Reply
1 Solution
2,255 Views
andrewsglenn
Contributor III

Update: I spoke with an FAE who suggested checking CPOL and CPHA.

I discovered that in earlier testing I'd flipped the both CPOL=1 and CPHA=1 to get any kind of output from the thing, and had not swapped them back to CPOL=0, CPHA=0 at the end of testing. My controller was sending CPOL=0, CPHA=0 and I was receiving the opposite.

I have no idea why this would cause the duplicate first byte in the MISO and why MOSI was printed correctly on the target, but it did.

Setting both ends to CPOL=0, CPHA=0 removed the duplicate byte.

Problem solved.

View solution in original post

0 Kudos
Reply
12 Replies
2,256 Views
andrewsglenn
Contributor III

Update: I spoke with an FAE who suggested checking CPOL and CPHA.

I discovered that in earlier testing I'd flipped the both CPOL=1 and CPHA=1 to get any kind of output from the thing, and had not swapped them back to CPOL=0, CPHA=0 at the end of testing. My controller was sending CPOL=0, CPHA=0 and I was receiving the opposite.

I have no idea why this would cause the duplicate first byte in the MISO and why MOSI was printed correctly on the target, but it did.

Setting both ends to CPOL=0, CPHA=0 removed the duplicate byte.

Problem solved.

0 Kudos
Reply
2,419 Views
Harry_Zhang
NXP Employee
NXP Employee

Hi @andrewsglenn 

If you try to reduce the SPI clock speed, Will this problem still occur?

BR

Hang

0 Kudos
Reply
2,403 Views
andrewsglenn
Contributor III
1 MHz duplicates the first byte the same as 6.25 MHz does.

At the transmitter end I have a loop that sends the same packet repeatedly. I put a breakpoint on it so I send a message every time I hit 'go' on the debugger.

The length of time between pressing 'go' does not seem to change that every other message sends a duplicate first byte.
0 Kudos
Reply
2,388 Views
Harry_Zhang
NXP Employee
NXP Employee

Hi @andrewsglenn 

As a troubleshooting step, try implementing the transfer without using DMA (in polling or interrupt mode) to see if the problem still occurs. This might help isolate the issue to either the DMA or the SPI driver.

BR

Hang

0 Kudos
Reply
2,333 Views
andrewsglenn
Contributor III

Interrupt mode gets duplicated first byte.

0 Kudos
Reply
2,366 Views
andrewsglenn
Contributor III
I tried using 'transfer mode' instead of DMA and got the same thing.
Can polling keep up with 512 bus at 6.25 MHz?
0 Kudos
Reply
2,333 Views
andrewsglenn
Contributor III
Sorry for the typo. 512 bus = 512 bytes.
0 Kudos
Reply
2,345 Views
Harry_Zhang
NXP Employee
NXP Employee

Hi @andrewsglenn 

You can refer to the LPC540xx/LPC54S0xx Product data sheet.

HangZhang_0-1728900755336.png

BR

Hang

0 Kudos
Reply
2,334 Views
andrewsglenn
Contributor III

Hi Hang,

I'm not sure how that applies. 6.25 MHz is less than 14 MHz, so should be fine. My question was if the interrupt service routine could keep up with reading and writing 512 bytes at 6.25 MHz without overflowing.

Is 'Transaction Mode' in the peripherals tab DMA or interrupt? I sent 0x200 bytes using both Transaction Mode and DMA mode and both showed duplicate bytes.

Glenn

0 Kudos
Reply
2,314 Views
Harry_Zhang
NXP Employee
NXP Employee

Hi @andrewsglenn 

I try to verify it on my LPC54018 evk board. I import the SDK spi_dma_transfer examples,

In this example, one spi instance as master and another spi instance as slave. Master sends a piece of data to slave,
and check if the data slave received is correct.

I tested it without any problems. May I ask if you are a custom board or an EVK board.

BR

Hang

0 Kudos
Reply
2,298 Views
andrewsglenn
Contributor III

HI @Harry_Zhang 

Both ends are custom boards. The target board is the LPC54S016 board. The controller board is an FPGA sending 512 byte packets at 6.25 MHz.

I've confirmed with a logic analyzer the controller board is sending the correct 512-byte packet to the target, and the target is printing it correctly on receipt.

I've confirmed with a logic analyzer that the target board is sending duplicated first byte every other transmission, and the controller board prints the duplicated byte.

I'll try and make a cut-down example to show the issue.

Glenn

0 Kudos
Reply
2,438 Views
andrewsglenn
Contributor III

Is it expected for the MISO line to tail off like this when you're using it as a slave?

andrewsglenn_0-1728596373128.png

 

0 Kudos
Reply