• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 115 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.

TDA4VH-Q1: TDA4VH:Memory read and write QOS configuration for R5

li quan
Intellectual 955 points
Part Number: TDA4VH-Q1
Other Parts Discussed in Thread: TDA4VH

Tool/software:

Hi expers,

On TDA4VH, are those QOS of R5 configurable? I know VM is configurable, but all these registers on VH read 0.

Note: The reason I do this is because we have a problem on our side: When we turn on the display function, the spi interrupt processing time increases by one half, which causes the spi related functions of R5 core to be abnormal, so we try to modify the QOS to enhance the interrupt processing speed of R5 core. If you have other solutions to this problem or can reduce the spi interrupt processing time, please let us know.

  • 0
    TI__Guru**** 475725 points

    Hi Li Quan,

    Yes, these registers are correct and are accessible even on VH device. 0 might just be reset value of these registers. 

    Before going into solution, can you please elaborate on the issue? Display alone should not have affected SPI. How frequently are you sending or receiving messages over SPI? Are you using CPU mode or DMA mode in SPI? From which core are you accessing SPI? 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 955 points

    HI Brijesh，

    We send and receive data once every 1,2-3 milliseconds when MCU3_1 core accesses spi, and the maximum amount of data at one time is 132 bytes. The hardware processing of spi should be OK. From our test, we found that the main reason is that R5 interrupt processing function takes too long in software, which leads to related function abnormalities. Turning off the display significantly reduces interrupt function processing time.

    Our current suspicion is that R5's register accesses inside the interrupt take more time due to the lack of overall system performance resources, and thus the overall interrupt handling function takes more time.

    So we want to adjust the QOS to improve the access efficiency of R5 and reduce the interrupt handling function time.

    Regards,

    Li Quan

  • 0 in reply to li quan
    TI__Guru**** 475725 points

    Hi Li Quan,

    but display does not run on mcu3_0/1 cores, isn't it? So having display on mcu2_0 should not affect SPI interrupt on mcu3_1. 

    If the doubt is on the interrupt access, can we move the function/ISR of SPI to some internal memory of mcu3_0/1? 

    Btw are you doing some processing in display ISR? It shouldn't cause delay on SPI as such. 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 955 points

    Hi Brijesh，

    Here, we try to put the.text and.data segments and the main data and interrupt handling functions into RAM. This reduces interrupt handling time considerably. Therefore, we think that the DDR access rate problem should be caused by the overall system performance pressure, and the anomaly probability is reduced a lot at present. This problem is not directly related to the spi function and the display function, but the display function consumes a lot of performance, so the problem is fed back to the interrupt handling of spi.

    Regards,

    Li Quan

  • 0 in reply to li quan
    TI__Guru**** 475725 points

    Hi Li Quan,

    That's great. As such Display ISR does not consume much resource, this is why i was wondering why it is affecting SPI on the other core. Yes, but due to other traffic it can potentially, so it is good to move this logic to internal memory. 

    Regards,

    Brijesh