• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 273 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM2634-Q1: Chip Errata with respect to MCSPI+EDMA (i2350 ABSYNC Mode)

ngrkus
Expert 1020 points
Part Number: AM2634-Q1
Other Parts Discussed in Thread: ADS7038-Q1, ADS7038

Hi,

based on the on-going thread:

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1209787/am2634-q1-am2634-edma3-mcspi-spi-adc-system-performance-questions/4564154#4564154

I tried to relax the DMA sequence requests from 1.25us downto 5us. To do so I did want the EDMA to burst write 4 Channel requests for the external SPI-ADC into the FIFO of the MCSPI on-chip component. However doing so, the SPI-TX direction 'dies out' after a few transfers. The EDMA3 is configured to use ABSYNC mode to do so. I read in the chip errata (i2350) that there seems to be an issue with this DMA mode with respect to MCSPI on-chip IP's. However I do not really understand the meaning of the description. I tried to use the work around. However nothing better happened. Therefore I assume I do get something wrong. Any hint on how to use the workaround for the EDMA + Fifo mode in my example within the MCSPI would be appreciated.

Legend:

- Ch3 (Blue)       : EDMA trigger every 5 us
- Ch2 (Magenta): MCSPI SPI-CSn output. It runs at max speed with respect to the SPI-Clk
- Ch1 (Green)    : MCSPI SPI-Clk. SPI-Clk frequency is 25 MHz.

Two 5us SPI burst sequences do work. Then it dies out. No more SPI-Tx activitiy. Root cause not known. The EDMA trigger still occurs every 5 us (Blue-Trace). The EDMA3 is configured to run endless on this channel.

Same scope-shot as the first one. However zoomed in. In this setup the SPI-CSn (Magenta trace) does not meet all the requirements for the ADS7038-Q1 with respect to the chip select period time which is > 1us. ADS7038 SPI-CSn high time > 230ns, low time > 400ns are met. ADC sampling period is violated a small amount. However lowering the SPI-Clk frequency may(!) result in a combination that would work and may fullfil all the timing requirements.

I did configure the EDMA channel for transmission to write 4 words (16Bit words) into the Fifo of the MCSPI. This shall happen every 5 usec. It does start up as expected. However after two sequence it dies out. Does this relates to what has been described in the chip errata (i2350)?

br
Markus

  • 0
    TI__Mastermind 45975 points

    Hi Markus,

    I think the issue you observed above is exactly what is described in the Errata i2350:

    You used ABSYNC of EDMA and transmitted 4*16 bit > 32 bit data to the TX FIFO.

    The workaround is to use smaller burst size, like 2*16bit, that should solve the problem.

    Best regards,

    Ming

  • 0 in reply to Ming Wei
    Expert 1020 points

    Hi Ming,

    trying your suggestion I do get for 2*16 and for 3*16 DMA Write-Burst into the transmission Fifo the following pattern. Finally at the end if I use 1*16 but still in ABSYNC mode, which I know is the same as 1*16 in A mode it works. Therefore I am a little bit confused about the description of i2350 in the errata of the chip. Unless I do not something completely wrong it looks to me that 32Bit is not working either. It doesn't have to be > 32Bits, equal seems to be sufficient. Seems... I am not 100% sure.

    ABSYNC on MCSPI-Tx 3*16 - stopping after the third round ... :

    ABSYNC on MCSPI-Tx 2*16 - stopping within the fourth round ... :

    ABSYNC on MCSPI-Tx 1*16 - running endless ... :

    It is kind of pointless to use ABSYNC with one word being transferred. Anyway. For now it may not be possible to use any of the ABSYNC options for this type of application. Trying to reduce the number of bits being transferred doesn't really change anything. If for example I reduce the number of bits from 16 to 12 I should be able to permanently transfer 2*12 bits which is smaller than 32Bits using the ABSYNC option of the EDMA3 together with the MCSPI. However as it turns out it looks the same as for the 2*16Bit options in ABSYNC mode. Only the number of bits/clocks have been reduced from 16 to 12. Unless I do something wrong here it looks like I can not use EDMA3 in ABSYNC mode for the MCSPI IP at the moment.

    br
    Markus

  • 0 in reply to ngrkus
    TI__Mastermind 45975 points

    Hi Markus,

    Your observation seems to be conflict with the Errata i2350. I will need to discuss this with our HW apps team and the IP owner of McSPI and EDMA. WIll get back to you as soon as I get any update.

    Meanwhile, will the 1*16 A mode work for you as a workaround? If yes, it should be unblock your development.

    Best regards,

    Ming

  • 0 in reply to Ming Wei
    Expert 1020 points

    Hi Ming,

    the motivation of using the burst-write into the FiFo of the MCSPI from the EDMA was to relax DMA trigger rate now being 1.25us downto 5us. Actually it looks like we can run our planed application with the status quo - i.e. EDMA trigger rate will remain every 1.25us. Therefore yes we may just use 1*16 mode to write/read through the MCSPI-IP. I will close this thread. However in case there is an update on how to use the EDMA+MCSPI better of more efficient I would appreciate it if you could keep me informed.

    br
    Markus