This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LS MibSPI in slave mode using Transfer Group

Hi there,

I'm aware that there is one section missing for the coverage of the MibSPI configured in slave mode using transfer groups in the TRM spnu499b manual, so I'm seeking advise here as on what went wrong in my configuration.

I've the following configured with the MibSPI5:

  • MibSPI5 in multi-buffer mode and in slave mode
  • Only _CS0 is configured as functional pin (TG0 used)
  • TG0 configured to sent 4x16-bit words (TXRAM[0..3], TG1_START=4)
  • GIOA[0] configured as trigger source (0x1) and physically connected to _CS0 (do I need this?)
  • Trigger event set to low-active (0x6) - _CS0 at low during the whole data block transfer
  • Pointer reset PRST=1 (reset pointer of TG0 each time _CS0 raises)

Result: With the external SPI master keeping the _CS0 low on each data request block (4x16 clock periods), only data word stored in TXRAM[0] was transmitted 4 times, other data words were not transmitted - SPI sequencer pointer not increasing.

If I set trigger event to falling edge (0x2) and change SPI master _CS0 to toggle on every 16-clock frame (PRST don't care here), all data words are transmitted after 4 frames (so pointer had incremented correctly). This works but it is NOT as desired, since it would take too much time for the whole process (later on we need to transfer 120 data words).

Could you please shed some light on my problem?

Thanks!

  • I'm currently performing target integration works at our customer's premise with this being the show-stopper, so a quick reply would be highly appreciated.

    Thank you!

  • Hi Chuck,

    As I told you yesterday at the office, here are some information that could help you with your problem.

    Assuming the MibSPI peripherals in your device are the same as those in TMS570LC43x (can someone confirm please?), you will find in the TRM TMS570LC43x (SPNU563) the following information in chapter 28.2.6.7:

    • TGxCTRL.PRST should be cleared to 0 in MibSPI slave mode
    • Fields TGxCTRL.TRIGEVTx and TGxCTRL.TRIGSRCx are not taken into account by the sequencer.
    • the Transfer Groups are triggered automatically according to the Chip Selects that are asserted and set as functional. In your case, only CS0 as functional means that the MibSPI is inactive when CS0 is high, and TG0 is active when CS0 is set low.

    Now I think that you certainly have tried something with this information and that it doesn't work. So could you precise your program behaviour with these settings please?

    Thanks,

    Gael

  • Hi Gael,

    Thank you for the reply.

    Since I don't have the setup with me at this moment and I don't remember what was the result when PRST=0 (TRIGEVT and TRGSRC not considered anyway), I'll experiment that later today.

    However I've noticed that the SPI sequencer pointer was not resetting to buffer [0] when the _CS0 toggles, so my question is what would be the TG resetting mechanism in the case of an incomplete TG transfer?

    Please see the attached capture screen with multiple _CS0 toggling, where, from top to down:

    1. SIMO (0x0000, 0x0000,0x0000,0x0000)
    2. SOMI (0x0201, 0x0000, 0x5a5a, 0x5a5a)
    3. CLK (16 clocks each frame)
    4. _CS0 (toggle on each frame)

    You can see clearly that the _CS0 didn't reset the TG0 pointer since all buffers were transmitted.

    Thank you.

  • Ooops, forgot the pic. :)

  • Hi Chuck,

    In the errata of TRM TMS570LS31x-21x (SNPZ195D), there is an errata about the MibSPI in slave mode for low clock frequencies (when the clock divider applied on VCLK is more than 12) >> MIBSPI#110.

    Does it apply to your case? You could increase the clock frequency to see if the transfer group is reset when CS0 varies from low-high-low.

  • Hi Gael,

    During this integration phase, we use a SPICLK of 500 kHz, and since my VCLK is 60 MHz, the divider would be 12, but given that the SPI clock phase has been set as 0 and at least one _CS was used, the errata doesn't apply to my setup.

    Beside that, we don't have an incorrect data transmission issue. What we have is a TG0 pointer incrementing issue.

    With reference to the above oscilloscope snapshot, the SPI master has received correctly data from SOMI, and the SPI slave has also received correctly data from SIMO (I.e. we have tried other data then 0x00 in another test).

    Still waiting insight from TI support.

    Thank you!

  • Hi Chuck,

    I will study the described issue in more detail tomorrow before answering. Sorry could not get to this earlier in the day.

    Regards, Sunil

  • Hi everybody,

    The problem was to set the CSHOLD bit to 1 in the TG0 buffers in order to tell the SPI sequencer to increment PCURRENTx on a frame basis.

    Instead of that, keeping the CSHOLD cleared to 0 makes the SPI sequencer to increment PCURRENTx on a Chip Select basis.

    Chuck, do you confirm that your problem is corrected?

    Bye,

    Gael

  • Thank you Gael,

    I can confirm that the setting of the CSHOLD bit to 1 has indeed fixed the issue, as you've described.

    I suggested however TI to update the spnu499b TRM as soon as possible to add the missing section regarding "MibSPI Slave Mode Operation", which is really significant in terms of understanding. There is currently nowhere in the TRM that I can find answers to my questions regarding the subjected matter, and the fact that I've configured correctly the TG0 vs my chip select scheme was a pure coincidence.

    Best regards,

    Chuck.

  • Also in the TRM spnu499b where the TXRAM control structure and its fields is described, it has been stated that the CSHOLD bit is ignored in slave mode, while my experience has proven that the CSHOLD is being taken into account (for the control of the Transfer Group sequencer pointer) in accordance with the SPI master's chip-select scheme (whether continuously LOW or frame by frame).

    I believe this fact should also be corrected in the TRM spnu499b.

    Thank you!