• State
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 108 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM13E23019: Questions about AM13E2x I2C driverlib

Oleksandr Ohlashennyi
Prodigy 61 points

Part Number: AM13E23019

While working with I2C peripheral using driverlib module from am13e2x SDK version 01.00.00.EA2, we had some findings about the following:

  • DL_I2CC_DMA_INTERRUPT_TXFIFO_TRIGGER
    This definition mapped to non-existent UNICOMMI2CC_DMA_TRIG1_IMASK_TXTRG_SET. It seems that it should be UNICOMMI2CC_DMA_TRIG0_IMASK_TXTRG_SET.

  • DL_I2CC_enableDMAEvent
    This function accepts DL_I2CC_EVENT_ROUTE and DL_I2CC_DMA_INTERRUPT, which we found hard to untangle.
    This isn't a bug or a problem for us, but rather the feedback that we spent some time connecting all the ends:
    In the SDK, routes are enumerated as 1 and 2 and fixed to DMA_TRIG1 and DMA_TRIG0 accordingly, while in the TRM, they are not explicitly enumerated. At the same time, each DMA_TRIGx has its own IMASK register (also not explicitly tightened in the TRM description) that serves a specific purpose -- TX or RX irq.
    For the SW developers, it would be nice to, perhaps, improve naming (e.g. route_tx, instead of route_rx) or relationship descriptions in the TRM and/or have some mapping in the driverlib for easier work

  • DL_I2CC_getRXFIFOCounter/DL_I2CC_getTXFIFOCounter
    1. These functions are supposed to return the number of bytes that can be read from FIFO, but returns value of SR_BCNT, which seems to serve a different purpose
    2. In DL_I2CC_getRXFIFOCounter, the value is not shifted by UNICOMMI2CC_SR_BCNT_OFS

BR,
Oleksandr

  • 0
    TI__Mastermind 20512 points

    Hi Oleksandr,

    Oleksandr Ohlashennyi said:
    DL_I2CC_DMA_INTERRUPT_TXFIFO_TRIGGER
    This definition mapped to non-existent UNICOMMI2CC_DMA_TRIG1_IMASK_TXTRG_SET. It seems that it should be UNICOMMI2CC_DMA_TRIG0_IMASK_TXTRG_SET.

    This has been fixed in the SDK that was released in mid-march. The v26.00.00.06 version has the reference 

    Oleksandr Ohlashennyi said:
    DL_I2CC_enableDMAEvent
    This function accepts DL_I2CC_EVENT_ROUTE and DL_I2CC_DMA_INTERRUPT, which we found hard to untangle.
    This isn't a bug or a problem for us, but rather the feedback that we spent some time connecting all the ends:
    In the SDK, routes are enumerated as 1 and 2 and fixed to DMA_TRIG1 and DMA_TRIG0 accordingly, while in the TRM, they are not explicitly enumerated. At the same time, each DMA_TRIGx has its own IMASK register (also not explicitly tightened in the TRM description) that serves a specific purpose -- TX or RX irq.
    Oleksandr Ohlashennyi said:
    For the SW developers, it would be nice to, perhaps, improve naming (e.g. route_tx, instead of route_rx) or relationship descriptions in the TRM and/or have some mapping in the driverlib for easier work

    I'll share this feedback with both the software and the production applications team.

    Oleksandr Ohlashennyi said:
    DL_I2CC_getRXFIFOCounter/DL_I2CC_getTXFIFOCounter
    1. These functions are supposed to return the number of bytes that can be read from FIFO, but returns value of SR_BCNT, which seems to serve a different purpose

    The BCNT is actually the max data that can be read from the RxFIFO or TxFIFO in the Controller, before starting a transaction we set the BCNT value as an indication of " how many bytes this transaction is going to last for ", so it makes sense to return the BCNT in this design.

    Oleksandr Ohlashennyi said:
    2. In DL_I2CC_getRXFIFOCounter, the value is not shifted by UNICOMMI2CC_SR_BCNT_OFS

    This looks like a valid bug, i've reported it internally and this should be taken care in the next SDK release (Internal tracking link: https://jira.itg.ti.com/browse/MSDK-1788)

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Prodigy 61 points

    Hello Shaunak, thank you for the response!

    • Shaunak Deshpande said:
      This has been fixed in the SDK that was released in mid-march. The v26.00.00.06 version has the reference
    • The latest version I can find is 01.00.00.EA2 from Feb 18. Maybe you can share the reference where we can get it, please?
    • Screenshot you attached still maps DL_I2CC_DMA_INTERRUPT_TXFIFO_TRIGGER to UNICOMMI2CC_DMA_TRIG1_IMASK_TXTRG_SET, which seems to be wrong. From the TRM, we would expect mapping to TRIG0, or have we misread the TRM?
    • Thank you very much!
    • Shaunak Deshpande said:
      The BCNT is actually the max data that can be read from the RxFIFO or TxFIFO in the Controller, before starting a transaction we set the BCNT value as an indication of " how many bytes this transaction is going to last for ", so it makes sense to return the BCNT in this design
    • Ok, thank you, I think we've missed that SR.BCNT is updated by hardware when the transfer length is > 1.
    • Shaunak Deshpande said:

      This looks like a valid bug, i've reported it internally and this should be taken care in the next SDK release (Internal tracking link: jira.itg.ti.com/.../MSDK-1788)

    • What will be your suggestion on how to proceed with the current thread (e.g. keep it open until your internal ticket is resolved)?

BR,
Oleksandr

  • 0 in reply to Shaunak Deshpande
    Prodigy 61 points

    Another concern about BCNT:

    It holds up to 0xFFF bytes and, in my understanding, represents the total length of the transfer, which can be higher than the max FIFO size (16 bytes).

    So if we have a 20-byte-long message to send, at first, TX will be filled with 16 bytes of data, and BCNT will be loaded with 20, which does not correspond to the actual FIFO level

  • 0 in reply to Shaunak Deshpande
    TI__Mastermind 20512 points

    Hi Oleksandr,

    You can find the latest SDK at: https://www.ti.com/tool/download/AM13E2X-SDK

    Updated product page: https://www.ti.com/product/AM13E23019

    In future, all the latest SDKs and TRMs will be uploaded directly to the product page and the SDK pages

    Regarding the I2C Bug, i'll keep this thread open until the bug is fixed and i can provide a patch.

    Also, i checked in the driver, the I2C DMA integration is not yet complete. The design I see right now is that the I2CT (target) is mapped to DMA_TRIG0 and I2CC (controller) is mapped to DMA_TRG1. This design can change if it has issues when the DMA support gets integrated, which is currently scoped in for 26.01 release (mid june).

    Also, for the question regarding BCNT:

    The BCNT will be loaded with 20 bytes, and only when the 20 bytes are processed a STOP condition would be issued. Once data is loaded into the FIFO, the count would be reduced from BCNT, so after FIFO is filled with 16 bytes, BCNT will become 4, and so on, once the 4 bytes are filled, BCNT will become 0, and a stop will be triggered.

  • 0 in reply to Shaunak Deshpande
    Prodigy 61 points

    Hi Shaunak!

    About the IRQ triggers. We followed the next logic from TRM (which works in our driver implementation):

    The second publisher(DL_I2CC_EVENT_ROUTE_1) is tied to TRIG 1 and the third(DL_I2CC_EVENT_ROUTE_2) to TRIG0:

    From the TRM table 25-20. "UNICOMMI2CT_REGS Registers" we see that interrupt-related registers have 3 groups, where we expect 2nd group to correspond to TRIG1 and 3rd to TRIG0:

    3rd group (offset 88h) corresponds to TXTRG flag:

    From this we conclude that:

    TX trigger <-> TRIG0 <-> 3rd publisher <-> DL_I2CC_EVENT_ROUTE_2

    RX trigger <-> TRIG1 <-> 2nd publisher <-> DL_I2CC_EVENT_ROUTE_1

    *This configuration worked in our tests

     

    Additionally, in the SDK v26.00.00.06 I see that DL_I2CC_DMA_INTERRUPT_TXFIFO_TRIGGER/DL_I2CC_DMA_INTERRUPT_RXFIFO_TRIGGER are the same as in the 01.00.00.EA2:

    1. DL_I2CC_DMA_INTERRUPT_TXFIFO_TRIGGER mapped to UNICOMMI2CC_DMA_TRIG1_IMASK_TXTRG_SET, while UNICOMMI2CC_DMA_TRIG1_IMASK_TXTRG_SET do not exist

    2. DL_I2CC_DMA_INTERRUPT_TXFIFO_TRIGGER and DL_I2CC_DMA_INTERRUPT_RXFIFO_TRIGGER are mapped to the same TRIG1, which seems impossible according to TRM.

    I'm not sure that the design you mentioned will work, as RX and TX must have separate routes to trigger separate DMA channels, so they cannot be both tied to one TRIG, or have I misunderstood the architecture?

    ----------------------------------------------------------------------------------

    About BCNT:

    Yes, exactly. And this means that BCNT does not contain the "number of bytes which can be read from RX FIFO"/"number of bytes which can be put into TX FIFO" as the SDK documents for functions DL_I2CC_getRXFIFOCounter/DL_I2CC_getTXFIFOCounter. To me, this sounds like these functions do not behave like they are supposed to. At the same time, I don't see any possible replacement for BCNT (e.g. MSPM0G had separate FIFO status registers for this purpose).

    For now, this is not a blocker for us, but we would like you to clarify the behaviour of these functions and improve documentation/remove them if functionality is not achievable

    BR,
    Oleksandr