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.

TMS570LC43x MibSPI DMA example not working

Other Parts Discussed in Thread: TMDX570LC43HDK, HALCOGEN

Hello,

as part of our evaluation of the TMS570LC43x family we are testing the MibSPI DMA functionality using the TMDX570LC43HDK. We are using the example included with HALCoGen (example_mibspiDMA.c) but the DMA transfer does not succeed (RXDATA remains zero). We have created the project with HALCoGen as described in the example, and are using the completely unmodified file "example_mibspiDMA.c".

Is there a known issues with MibSPI DMA transfers on this chip, or the code created by HALCoGen, or the example?

The toolchain we are using is as follows:
HALCoGen: 04.02.00
Code Composer Studio: 6.0.1.00040
Compiler: TI v5.2.0

Any help would be greatly appreciated. I am attaching the Code Composer Studio project for reference.

4212.mispiDMA.zip

  • Markus,

    I will have a look at your code and get back to you.
  • Hello Marcus,

      There is a mistake in the example. The Halcogen example is setting the buffer length to 127 in the MIBsPI1 Transfer Groups tab. It should be changed to 128 like the below image then it will work. Please give a try.

  • Hi Charles

    many thanks for getting back to me so quickly and pointing out the mistake in the example. I have corrected the setting and regenerated the code; however, it is still not working (same behavior as before, no change to RXDATA). If I am not mistaken, RXDATA should be updated after the progam has run for a few seconds.

    Would you be able to confirm the example works as expected on the TMS570LC43x for you? 

    Thank you.

  • Hi Markus,

      Please try the attached project and it works for me after changing the buffer length to 128.

  • Hi Charles

    thank you very much for posting your project. I can confirm that this works without problems.

    I was obviously curious as to why your project works and mine does not. The core difference between our projects is that you used HALCoGen v4.01, while I used HALCoGen v4.02.

    On further inspection it turns out that the MPU configuration is at fault. If I configure the R5-MPU-PMU tab in the same way that it is configured in your uploaded project then the demo works as expected. For my tests, I used the default settings of HALCoGen 4.02. Did you set these settings manually, or have the default settings changed from v4.01 to v4.02?

    Again, thank you for your help; it is greatly appreciated.
  • Hi Markus,
    I'm using Halcogen 4.01.0 and take the default setting of the R5-MPU-PMU tab without any modification. I will take a look at the 4.02 MPU default setting and see how it affects the outcome.
  • Hello Markus,

      I tried HalcoGen 4.2.0 and could reproduce the problem. I found that by changing the MPU setting for region 3 to Write-through (NORMAL_OIWTNOWA_NONSHARE) cache rather than Write-back cache it becomes to work. In the meantime please use write-through cache scheme while we will further investigate how write-back scheme affects the DMA transfer. Thanks. 

  • Hi Charles

    many thanks for getting back to me on this with a fix. I would appreciate if you could keep me updated on further findings about why this occurs.

    Regards
    Markus
  • Hi Markus,

      The reason that the write-back cache scheme will not work in this particular DMA example is because in write-back cache scheme, the write (initializing the TXDATA buffer) is only writing to the cache memory. The write-back scheme normally improves system performance as it does not write to the L2 SRAM memory and hence reduces bus transactions/bandwidth. The write-through cache scheme always writes to both cache and the L2SRAM to keep the data coherent. In the HalcoGen example using DMA, the DMA will read from the TXDATA buffer stored in the L2SRAM and write to the MibSPI TXRAM. Since the MPU is configured with write-back scheme the TXDATA which are initialized by the CPU are only present in the cache but not in L2SRAM. The L2SRAM contains stale data which is currently all zeros compared to the cache. DMA is actually reading zeros from the L2SRAM and writes to the MibSPI RAM. If you disable the loopback mode and probe the MIBSPI_SPICLK and MIBSPI_SIMO signals on the scope you will find active SPICLK but the SIMO pin is always zero.

      To resolve this issue the write-through scheme should be used in a muti-master environment when these masters share the same memory to avoid data coherency issue. I have informed our HalcoGen team about this. They shall update the MPU setting in the future release. Let me know if this answers your question. 

  • Hi Charles

    Thank you for the explanation, it is much appreciated.

    Best
     Markus