LPC54S016 SPI Slave DMA Repeated first byte

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

LPC54S016 SPI Slave DMA Repeated first byte

跳至解决方案
2,459 次查看
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?

标记 (1)
0 项奖励
回复
1 解答
2,258 次查看
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 项奖励
回复
12 回复数
2,259 次查看
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 项奖励
回复
2,422 次查看
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 项奖励
回复
2,406 次查看
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 项奖励
回复
2,391 次查看
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 项奖励
回复
2,336 次查看
andrewsglenn
Contributor III

Interrupt mode gets duplicated first byte.

0 项奖励
回复
2,369 次查看
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 项奖励
回复
2,336 次查看
andrewsglenn
Contributor III
Sorry for the typo. 512 bus = 512 bytes.
0 项奖励
回复
2,348 次查看
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 项奖励
回复
2,337 次查看
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 项奖励
回复
2,317 次查看
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 项奖励
回复
2,301 次查看
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 项奖励
回复
2,441 次查看
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 项奖励
回复