The relationship between the VCLK1 setting and DMA & MibSPI clock

Yusuke Nomoto said:

I have a question for the relationship between the VCLK1 setting and DMA & MibSPI clock on TMS570LS2124.

I want to make the 2us MibSPI nCS negate time in VCLK1=90MHz, however it can't be available; because the maximum WDELAY value is 0x3F, so only 693ns is available.
Then, I changed the VCLK1 frequency to 30MHz (2.079us MibSPI nCS negate time is available).
 -> only the CLKCNTL register is changed
In consequence, the DMA transfer is suspended. (Some DMA transfers are completed; however the DMA transfer is suspended in midstream.)

With that, I have the following questions.

1. Are the DMA clock and the MibSPI clock synchronized?
   If not so, are there special settings to synchronize the DMA clock and MibSPI?

HW: VCLK1 set the speed limitation to access peripheral. So, it will slow down the memory access.

2. Is the maximum value of WDELAY 0x3F?
   WDELAY's of the SPIFMT register bit width seems 8bit in TRM.
   I think the maximum value is 0xFF.

HW: Maximum is 0xFF. TRM is wrong. Maximum is 0xFF for the 65nm devices while 0x3F for the 130nm devices

3. Is the PRESCALE value (the SPIFMT register) related to that result?
   I changed the value and re-tried, and then results are changed.
   Could you explain the relationship of the PRESCALE value and DMA & MibSPI clock?

HW: No. Prescale set the SPI clock speed, scaled from VCLK1. SPICLK = VCLK/(prescale+1).

Best Regards.

Nomoto

Hello, Haixiao-san

Thank you for your replay and I can understand your answer for No.2.
I'm so sorry but I can't understand for No.1 and No.3, so I want to more information.

For No.1:
I understand that the DMA module and the MibSPI module are connected different BUS.
The DMA module is connected to "Switched Central Resource", and the MibSPI module is connected to "Peripheral Central Resource Bridge".
And then, I want to know whether the provided clocks to these modules are synchronized.

Also, you mentioned "VCLK1 will slow down the memory access".
Is it occurred automatically?
And, if VCLK1 slow down the memory, are the clocks skewed between related module and memory?

For No.3:
I understood prescale set the SPI clock speed, however the prescale impacts result.
If you have any idea for the issue, could you give me advice?

Best Regards.

Nomoto

MibSPI clock is VCLK1, this defines the speed to access the mibspi RAM speed. If you VCLK1 frequency is half as before, reading a SPI RAM should increase two times as well. That is what I mean "slow down".

VCLK1 is snchronized with HCLK. I think DMA access the SRAM based on HCLK and access the SPI RAM based on VCLK1.

I don't know why the SPI clock speed impact the module and memory. In my mind, they should be irrelevant. What did see in the bench?

Regards,

Haixiao

Haixiao-san,

Thank you for your reply.
And I can understand "slow down" and that VCLK1 and HCLK are synchronized.

I'm verifying the MibSPI issue in loopback mode.
Do you think the loopback attributes to the MibSPI issue?

Also, it seems that the MibSPI baud-rate, VCLK frequency, T2CDELAY influence the issue.

Best Regards.

Nomoto

Hello Haixiao-san,

Could you check the attached project?
This project works with TMDX570LS31USB.
You will find the MibSPI transfer suspends along the way after a short time.

And if you change the baudrate prescale value from 6U to 5U, the issue will not occur.
(Bit-8 "baudrate prescale", mibspiREG1->FMT0, in mibspi.c)

Best Regards.

Nomoto

Hello Haixiao-san,

I'm sorry, but I wrote the incorrect information for the "baudrate prescale" value in above thread.
"from 6U to 5U" is incorrect, and "from 5U to 6U" is correct.

Now, I execute same program with TMDX570LS31HDK, however the issue occurs.
I will submit some additional information.

The first picture and second picture are the results when the "baudrate prescale" value is 5U.
The third picture is the results when the "baudrate prescale" value is 6U.

The first picture shows the TX arrays and the RX arrays.
It shows some data is transferred correctly.
rx_data10ms and rx_data1ms are receive data, and tx_data10ms and tx_data_1ms are transfer data.

The second picture shows the MibSPI1 SRAM.
Three TGs are defined, however two TGs are used, TG0 and TG2.
And 32-bit is transferred in one TG.
Therefore, the first TG and the third TG are used.
Also, this picture shows that the transfer is terminated and the illegal behavior.
For TG0's receive data (0xFF0E01F0 and 0xFF0E01F2), "Multi-buffer Receive Buffer Register Field" are different for the first word and the second word.
RXEMPTY of the first word is 1'b0 and the second word is 1'b1, so the DMA transfer suspends, I think.

Also, TG2 seems illegal, because transferred data is not series.
(Each half-word should be series)
TX data is "FFFFFFFF", where RX data is FFC0FFC0.
It seems that the transferred data is overwritten.

The third picture shows the correct result.
TG0 and TG2 data is transferred continuously.

Best Regards.

Nomoto

A quick update:

We have already reproduced this by simulation.

Next, our SPI design team will look into it and see why the receive flag is not set correctly.

Thanks,

Haixiao

Hello Haixiao-san,

Thank you for your reply.
However, your suggestion is not accepted by the customer.

There are three reasons.
1. I don't understand why DMA works continuously by changing BUFMODE to "5" from the current "7".

2. The solution conflicts with the TRM descriptions.
   "The buffer should be configured in as "skip until RXEMPTY is set" or "suspend to wait until RXEMPTY is set" in order to ensure synchronization between the DMA controller and the MibSPI sequencer."
   "The buffer should be configured in the as "skip until TXFULL is set" or "suspend to wait until TXFULL is set" in order to ensure synchronization between the DMA controller and the MibSPI sequencer."
   I think that above restrictions mean BUFMODE should be set to "7".
   These restrictions are described in RXDMAENAx and TXDAMENAx of "25.9.34 DMA Channel Control Register (DMAxCTRL)".

3. I don't know whether your suggestion is the permanent measures.

Could you give me a expertise?

Best Regards.

Nomoto

Hello Haixiao-san,

Thank you for the workaround.

I have a question:

If the buffer mode of the dummy group is changed to 0, is the priority between TGs kept?

For the background of the question, the low priority TG pre-empt the high priority TG when the SPI sequencer is in very short 'complete' condition.

As a solution, I remember that a dummy TG (BUFMODE=7h) is made between the high priority TG and the low priority TG.

If the buffer mode of the dummy group is changed to 0, is the behavior changed compared to BUFMODE=7h behavior?

Best Regards,

Nomoto