LPC54S016 SPI Slave DMA Repeated first byte

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

LPC54S016 SPI Slave DMA Repeated first byte

ソリューションへジャンプ
2,454件の閲覧回数
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,253件の閲覧回数
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,254件の閲覧回数
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,417件の閲覧回数
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,401件の閲覧回数
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,386件の閲覧回数
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,331件の閲覧回数
andrewsglenn
Contributor III

Interrupt mode gets duplicated first byte.

0 件の賞賛
返信
2,364件の閲覧回数
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,331件の閲覧回数
andrewsglenn
Contributor III
Sorry for the typo. 512 bus = 512 bytes.
0 件の賞賛
返信
2,343件の閲覧回数
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,332件の閲覧回数
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,312件の閲覧回数
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,296件の閲覧回数
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,436件の閲覧回数
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 件の賞賛
返信