RM46L852: MibSPI in Slave Mode - Reading or writing SPI-RAM during transfer corrupts the data transferred

Hi Manuel,

I am running your code, but I noticed that the data is not copied to TXRAM correctly.

In slave mode, the MibSPI uses the chip-select pin (0~3) to trigger the transfer group. If CS0 is used, only TG0 will be triggered.

> I am running your code, but I noticed that the data is not copied to TXRAM correctly.

What exactly are you referring to? The data is copied to TXRAM before the transfer even starts, using your API calls, and I think that works.

Then, during the transfer I copy data to the other TG that is not involved in the transfer. This leads to the data from the SPI hardware line not being correctly copied to the RXRAM and the data from the TXRAM not being output correctly on the SPI hardware line.

I didn't check, but it is quite possible that the data copied to the unused TXRAM is also not copied correctly. Is that what you are talking about?

Or are you telling me I am doing something wrong in the code, then please correct me!

>In slave mode, the MibSPI uses the chip-select pin (0~3) to trigger the transfer group. If CS0 is used, only TG0 will be triggered.

Are you saying that in slave mode CS0 triggers TG0, CS1 triggers TG1, CS2 triggers TG2 and CS3 triggers TG3, and that is hardcoded and the CS-setting for each TG is ignored? There is nothing like that in the manual.

Best regards,

Manuel

Hello Manuel,

1. I run the code on my RM46 launchpad, and produced the issue you reported. The CPU has the priority over the MibSPI when accessing to the buffers RAM.

2. Please refer to "28.2.6.7 MibSPI Slave in Multi-buffer Configuration" of SPNU563A.

Hi!

>1. I run the code on my RM46 launchpad, and produced the issue you reported. The CPU has the priority over the MibSPI when accessing to the buffers RAM.

So what are you suggesting to do as a workaround? Never access the SPI-RAM during a transfer? The problem is that as a slave, you never know when a transfer starts, so this makes using more than 1 TG impossible.

>2. Please refer to "28.2.6.7 MibSPI Slave in Multi-buffer Configuration" of SPNU563A.

This is really interesting and explains a lot, thanks. I didn't have the idea of reading the TMS570LC43x manual when using a RM46x, I only ever looked in SPNU514C where there is no such chapter.

But it also raises more questions. Does the whole chapter 28.2.6.7 apply to the RM46x ?

I would never have expected such a CS "decoder" where you put the TG number as binary on the CS3..0 lines. As these signals are asynchronous, I am not sure how this can even work so that always the correct TG number is decoded. Does the SPI wait until the CS3..0 lines are stable for n VCLKs?

I need to use the 3-Pin mode, so this chapter also explains why I can only get it to work with TG0.

But this note is troubling me:

NOTE: The maximum input frequency on the SPICLK pin when in slave mode is VCLK frequency /2.
If the Slave is configured in either 3-pin or 4-pin (without SPIENA) modes, then, between end
of last SPICLK and the start of SPICLK for next buffer, there should be at least 6 VCLK
cycles of delay.

Is the "end of last SPICLK" the last CLK edge that caused the sampling of the input?

Is the "start of SPICLK for next buffer" the very next edge on CLK or the next sampling edge?

In other words does this limit the SPICLK frequency to VCLK / 6 or VCLK / 12 (if you cannot add a delay between every n-th clock) ??

Or does "there should be at least 6 VCLK cycles of delay" mean "additional" delay in addition to the minimum 1 VCLK ? (or 2 VCLK pedending on how to interpret start of SPICLK)

Best regards,

Manuel Köppen

Hello Manuel,

1. I don't have any workaround so far.

2. yes. this also applies to RM46 device. CS0 is used to trigger TG0, CS1 for TG1, and CS2 for TG2, etc. When 3-pin mode is used, only one transfer group can be triggered and it is restricted to Transfer Group 0 (TG0).

3. "end of last clock" is the end of the last clock cycle. "start of SPICLK for next buffer" is the first edge of next clock cycle". 

WDEL can be used to insert the delay between each transfer. The SPI master should insert at least 6 VCLK cycles before sending the clock to begin the transaction. My understanding is 6 cycles in total.

QJ Wang said:

2. yes. this also applies to RM46 device. CS0 is used to trigger TG0, CS1 for TG1, and CS2 for TG2, etc. When 3-pin mode is used, only one transfer group can be triggered and it is restricted to Transfer Group 0 (TG0).

A-ha so this is different from SPNU563A, no 4-to-16 "CS decoder" like  the TMS570LC43x  seems to have, but instead the CS0..CS3 directly select TG0..TG3. So TG4..15 cannot be used. Can you confirm that? I like that much more than a decoder because of the possible timing problems of such a decoder.

QJ Wang said:

3. "end of last clock" is the end of the last clock cycle. "start of SPICLK for next buffer" is the first edge of next clock cycle". 

It's still no clear between which edges the "delay" is needed or better the minimum time must be followed. I can do this only by slowing down SCLK so what is the maximum SCLK frequency in relation to VCLK when SCLK is a simple 50/50 rectangular waveform without additional delays at certain points?

In your picture, your arrow points to the "same" edge. In a longer transfer the last rising edge of the picture is the same edge as the first rising. Can you clearly mark 2 edges between which the CPU needs at least 6 VCLK total?

The master is not a hercules CPU, I have no WDEL.

Best regards,

Manuel Köppen

Hi!

That is a nice colorful explanation of how the "CS Decoder" works, although you didn't answer the question of how the 4 asynchronous CS lines are synchronized, that is for example within how may VCLK the CS must stabilize for a correct TG to be selected. Say for example CS0 becomes active just before the VCLK edge and CS1 just after, will TG3 be correctly selected? What if there are 2 VCLK edges between the CS0/CS1 edges?

But this is not my main problem. It helps me to understand how the MibSpi works and why I wasn't able to get more than one TG working though.

You didn't answer the main questions yet:

How to avoid data corruption? (See my first post).

And how fast can the SCLK really be? (See my last post).

Best regards,

Manuel

Hi Manuel,

As stated in datasheet, the input SPI clock should be <= 25MHz and <= VCLK/2, where VCLK is the peripheral clock frequency in slave device. If the slave doesn't use SPIENA handshaking signal, at least 6 VCLKs delay should be inserted between two buffers transfer. The delay is between the subsequent rising edge (for clock mode 0) of last SPI clock to the first rising edge for next buffer transfer.

I am sorry, I haven't found the workaround for data corruption caused by accessing TG while transferring data).

Hi!

QJ Wang said:

The delay is between the subsequent rising edge (for clock mode 0) of last SPI clock to the first rising edge for next buffer transfer.

So when I cannot insert delays, I need at least 6 VCLK between two rising edges, that means SPI clock must be <VCLK/6.

In my case, VCLK is 110 MHz, so my SPI needs to be below 18.3 MHz - I am currently using 16 MHz because 24 MHz did not work properly.

Will this be added to the RM46X manual (spnu514c)? There is no mention of this limitation there, only in the TMS570LC43x manual (spnu563a) it is mentioned.

QJ Wang said:

I am sorry, I haven't found the workaround for data corruption caused by accessing TG while transferring data).

So the only possibility to avoid data corruption is to not access any TG RAM while transferring data.

Will this be added to the RM46X errata?

Best regards,

Manuel Köppen

Hi!

It has been almost 4 weeks now since I last heard from you. Are you still working on it?

To prevent auto-close of the topic, I'm asking again:

Is my calculation correct (SPICLK with no delays must be <18.3 MHz for VCLK=110 MHz) and will this limitation be added to the manual?

EDIT: I just read your last answer, it wasn't displayed properly. So thanks for adding it to the TRM. Just to confirm, the calculation is correct?

Will the corruption problem be added to the errata? Did you find any workaround in the meantime?

Data corruption is a serious problem and because the ONESHOT flag is not working either, it's not even easy to securely prevent an access to the TG RAM while a transfer is running.

Best regards,

 Manuel Köppen

I will check

Dodging the auto-close again...

QJ Wang said:

I will check

Best regards,

Manuel

Hi Manuel,

I am sorry I haven't got chance to do more investigation. Will do it.