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:
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?
Solved! Go to Solution.
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.
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.
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
Interrupt mode gets duplicated first byte.
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
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
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
Is it expected for the MISO line to tail off like this when you're using it as a slave?