• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 987 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TDA4VM: Spi_setupEB error

Cherry Zhou
Mastermind 22235 points

Part Number: TDA4VM

Hi team,

Here's an issue from the customer may need your help:

When debugging the SPI DMA, the return value when call Spi_setupEB is E_NOT_OK. The Spi_setupEB function of the Spi.c in mcal was added with a filter condition when the SPI DMA transfer was used, as the following figure:

The note here shows that Spi_setupEB can only set the data length of 32 when using SPI DMA, and the customer set the length of 8, as shown in the following figure:

Question: setting the data length to 8 is no problem when DMA transfers are not used. However, setting the data length to 8 is not possible after using DMA transfers. SPI With DMA transfers, can Spi_setupEB only set the data length to 32?

Could you help check this case? Thanks.

Best Regards,

Cherry

  • 0
    TI__Mastermind 22235 points

    Hi,

    May I know is there any updates?

    Thanks and regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Mastermind 36307 points

    Cherry,

    Your understanding is correct. The SPI can only use data length of 32 or multiplies of 32 (32*2, 32*3, etc) when DMA is enabled. This is a limitation imposed by the driver. If you want to transfer less than 32, you would need to transfer without the DMA enabled.

    Regards,

    Erick

  • 0 in reply to Erick Narvaez
    TI__Mastermind 22235 points

    Hi Erick,

    Thanks for your response.

    Using Spi_setupEB to set the data length to a value greater than 32 (64, 96, 128) and checking with oscilloscope and logic analyzer, the SPI waveform is no longer available. Only the data length is set to 32, the waveform is ok. Why is that?

    And here're 2 new questions:

    1) What does TXBuf and RXBuf do to place in the .bss section? Can local variables directly be used without this modification of TXBuf and RXBuf?

    2) What does SpiApp_wbCache do to modify TXBuf, RXBuf? Can it be removed?

    Thanks and regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Mastermind 36307 points

    Cherry,

    Cherry Zhou said:
    2) What does SpiApp_wbCache do to modify TXBuf, RXBuf? Can it be removed?

    The wbCache calls the Cache writeback function, which has the following description:

    /*
    66 * Writes back the range of memory within the specified starting address
    67 * and byte count. The range of addresses operated on gets quantized to
    68 * whole cache lines in each cache. There is no effect on L1P cache.
    69 * All cache lines within the range are left valid in L1D cache and the data
    70 * within the range in L1D cache will be written back to L2 or external.
    71 * All cache lines within the range are left valid in L2 cache and the data
    72 * within the range in L2 cache will be written back to external
    73 */

    Perhaps this is required when using DMA, I will double-check this point with our MCAL team.

    Regards,

    Erick

  • 0 in reply to Erick Narvaez
    TI__Mastermind 22235 points

    Hi Erick,

    Erick Narvaez said:
    Perhaps this is required when using DMA, I will double-check this point with our MCAL team.

    Thanks and expect the results.

    And is there anything new regarding the other 2 questions?

    Thanks and regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Mastermind 36307 points

    Cherry,

    I'm checking all three questions with them.

    Regards,

    Erick

  • 0 in reply to Erick Narvaez
    TI__Mastermind 22235 points

    Hi Erick,

    Understood and thanks for your support again.

    Regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Mastermind 36307 points

    Hi Cherry,

    I've received feedback on the second point:

    2) .bss section can reserve storage, but it can't initialize it. In the .data section, you could reserve storage and set it to an initial value. In the .bss section, you can't set an initial value. This is useful for buffers because we don't need to initialize them anyway, we just need to reserve storage.

    Regards,

    Erick

  • 0 in reply to Erick Narvaez
    TI__Mastermind 22235 points

    Hi Erick,

    Got it and expect the follow up on point 1.

    Thanks and regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Mastermind 22235 points

    Hi Erick,

    May I know is there any follow up?

    Thanks and regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Mastermind 36307 points

    Cherry,

    I've not received a response from our development team, I've submitted a bug against the SPI MCAL and will update you with their response.

    Regards,

    Erick

  • 0 in reply to Erick Narvaez
    TI__Mastermind 36307 points

    Hello Cherry,

    I've received a response to your remaining questions:

    - Why do we need to write-back to the cache for the buffers?

      - As R5 core is not Cache Coherent, Cache Write back is required if R5 writes to the buffers. Similarly before reading the buffers application needs to invalidate those.

    - Why do we need to wbCache() on the TX and RX Buffers?

      - It is because these buffers will be used by both R5F core as well as DMA engine.

    The team is currently looking at the >32-bit DMA transfer to see if they see the same issue you are facing here. Do you have any example of the modification you had to make to enable a higher DMA transfer, for example, a 64-bit DMA transfer?

    Regards,

    Erick

  • 0 in reply to Erick Narvaez
    TI__Mastermind 22235 points

    Hello Erick,

    Thanks for your updates!

    Now the largest data transfer is over 70. According to the previous reply, DMA transfers can be multiples of 32, so 96 is set, as shown in the following figure:

    Currently the SPI has no effect and no message is sent. For the same code, setting the buffer to 32 is able to send normally.

    The current solution is to set the CS of the SPI to normal IO, send 70 bytes of data three times, and send 32 bytes at a time, thus temporarily solving the SPI DMA requirement. However, it is not possible to send more than 32 bytes at a time through the MCAL function interface, which should not be normal. 

    Thanks and regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Mastermind 22235 points

    Hi Erick,

    Any feedback regarding the new condition? 

    Thanks and regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Mastermind 36307 points

    Cherry,

    Our developers are asking for a code patch they can try to reproduce this issue, so far they have not been able to reproduce. Could you provide this in order to help speed up the solution?

    Regards,

    Erick

  • 0 in reply to Erick Narvaez
    TI__Mastermind 22235 points

    Hey Erick,

    The customer simply multiplexes the CS to GPIO and then sends it several times and other basically remains unchanged:

    And the customer would like to confirm if SPI_setupEB only support setting size 32 under DMA transfers, or a multiple of 32 is also supported(32*2, 32*3, etc.)? 

    Thanks and regards,

    Cherry