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: UDMA uart rx write latency

Part Number: TDA4VM
Other Parts Discussed in Thread: AM6548

j7 udma ip was updated to support the issue that is documented in https://e2e.ti.com/support/processors/f/791/p/751871/2806066#2806066

Is the new bit I am suppose to use PDMA_PSILCFG_REG_STATIC_TR_Z[31].eol . 

What should the other values be in the tr desc. I have been able to get it to write each byte as it comes in but I haven't seen a way to get a infinite loop. I saw the STATIC bit 4 but that is for type 8 and 9 block move trs.

What register can I read to let me know the current buffer index that is flushed to ram?

  • Hi,

    Can you continue to post the question in AM6548 forum?

    Regards

    Sivaraj R

  • The other thread was locked. Can you unlock it? The thread is only relevant to j7 since am6548 silicon does not support this feature. Is it ok to discuss a unreleased product in the public am65xx forum.

  • I figured out why my count at NAVSS0_UDMASS_INTA0_CFG_GCNTRTI wasn't increasing. Based on "Table 10-103. Global Event Map" I need to set ROES to a event number > 36864 to map it to UDMASS_INTR_AGGR0 GEVI vs UDMASS_INTR_AGGR0 SEVI.

    Remaining questions

    1)When that GEVI count increases will the data be in memory so I can read it by the a a72 or r5 core? I am currently sending an event every byte by setting EVENT_SIZE to 1 "Event is generated when the second inner most loop (ICNT1) is decremented by 1."

    2)How do I set the dma to be in infinite loop?

    3)Instead of GCNTRTI saturating at 0xFFFFFFFF it would be nice if it just rolled over so I don't have to write to the register. If there is a way to make it rollover please let me know.

  • Hi Ryan,

    2) You need to submit a new TR once the current TR is processed to use DMA in infinite loop. You can also you the 'Reload Count' to specify how many time the TR will reload after it's processed but again this is a finite value. You can use function 'CSL_udmapCppi5TrSetReload()' to set this value.

    For others let me check and get back.

    Regards,

    Ankur

  • I would suggest updating the TRM to change "Reload Enable" to "Reload Count". I had "Reload Count" set to 0x1ff but it never worked and I thought it was because I didn't have "Reload Enable" set to 1 and I could never find Reload Enable. I thought it might have been the STATIC bit used for tr8/9. The reason why it didn't work was because i set EOP in the tr rqst flags which was causing "EOP on incoming data stream was encountered late (long packet)" which stopped it from looping. The CSL_udmapCppi5TrSetReload is how I figured out Reload Enable and Reload Count are the same thing.

    Let me know how I can know when the write completes. Based on "j7 trm "10.4.3.2 DRU Output Events" it looks like tr complete event is the only one that waits for writes to complete but hopefully there is another way to know if a write is complete.

  • The write completion is indicated by the generation of the event. It doesn't matter if the event is triggered for the entire TR completion or for ICNT1/2/3 decrement type.

    Hope this clarifies all the doubts

    Regards

    Sivaraj R

  • Thanks. That seems to work and I haven't seen any coherency issues.