• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 2 answers
  • Subscribers 33 subscribers
  • Views 507 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.

AM2634-Q1: AM263x LIN LIN_SCIINTVECT Questions

AndreTseng
Intellectual 2555 points
Part Number: AM2634-Q1

Hi expert, 

     I have questions regarding LIN_SCIINTVECT register. 

 

From register description:

Interrupt vector offset for INT0. This register indicates the offset for
interrupt line INT0. A read to this register updates its value to the
next highest priority pending interrupt in SCIFLR and clears the flag
corresponding to the offset that was read.

But from the source code, I can't not see any relationship in between this vector value and SCIFLR

/** @} */

/**
* \anchor LIN_IntOffset
* \name Lin Interrupt Offset
*
* Note: Definitions for the return value of LIN_getInterruptLine0Offset()
* and LIN_getInterruptLine1Offset().
*
* @{
*/
#define LIN_VECT_NONE (0x00)
#define LIN_VECT_WAKEUP (0x01)
#define LIN_VECT_ISFE (0x02)
#define LIN_VECT_PE (0x03)
#define LIN_VECT_ID (0x04)
#define LIN_VECT_PBE (0x05)
#define LIN_VECT_FE (0x06)
#define LIN_VECT_BREAK (0x07)
#define LIN_VECT_CE (0x08)
#define LIN_VECT_OE (0x09)
#define LIN_VECT_BE (0x0A)
#define LIN_VECT_RX (0x0B)
#define LIN_VECT_TX (0x0C)
#define LIN_VECT_NRE (0x0D)
#define LIN_VECT_TOAWUS (0x0E)
#define LIN_VECT_TOA3WUS (0x0F)
#define LIN_VECT_TO (0x10)
/** @} */

For example: when LIN in responder mode received ID, we got LIN_VECT_ID (0x04)  from reading LIN_SCIINTVECT by -LIN_getInterruptLine0Offset () API.

However the FIDRXFLAG in SCIFLR is bit 14. The vector offset is not corresponding to vector offset. I'm confusing.  

Any document to describe vector value in between each flag in SCIFLR and  SCIINTVECT value?

After reading vector, only flags for the receive [SCIFLR.9] and the transmit [SCIFLR.8] interrupts need to be cleared manually. Is this correct?

Regards

Andre

  • 0 in reply to AndreTseng
    TI__Prodigy 580 points

    Hi AndreTseng,

    Apologies for the delay. We have assigned this thread to a module expert. You can expect a response within 1-2 days.

    Regards,

    Abishek S S.

  • 0
    TI__Mastermind 22893 points

    Hello Andre,

    Thank you for your patience while I have been reviewing the details here.

    1) If a particular flag is set in SCIFLR the LIN_SCIINVECT register will directly reflect the corresponding values in SCIFLR.

    2) SCIFLR flags 8 and 9 are not cleared by LIN_SCIINVECT, the user must take care to clear these.

    If you have any LIN tests, please capture the SCIFLR and LIN_SCIINVECT registers at different flags per the SCIFLR register description. This should provide us with the required info to address any queries.

    Hope this helps to provide some additional clarity.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    TI__Intellectual 2555 points

    Zackary,

        The answer doesn't address my question:

    For example: when LIN in responder mode received ID, we got LIN_VECT_ID (0x04)  from reading LIN_SCIINTVECT by -LIN_getInterruptLine0Offset () API.

    However the FIDRXFLAG in SCIFLR is bit 14. The vector offset is not corresponding to flag offset.

    Same as IN_VECT_RX (0x0B)  and LIN_VECT_TX (0x0C) which corresponding bit number in SCIFLR are #9, and #8.

    You can see the mismatched setting in MCU+ SDK LIN Driver code. 

         

    "If a particular flag is set in SCIFLR the LIN_SCIINVECT register will directly reflect the corresponding values in SCIFLR."   Can you explain why we can't get the matched vector and bit flag? Thanks.

    Regards

    Andre

  • 0 in reply to AndreTseng
    TI__Mastermind 22893 points

    Hello Andre,

    Apologies for not properly addressing your issues here. I am looping our SW expert for additional insight into the LIN driver details. Thank you for your patience.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    TI__Intellectual 2555 points

    Zackary,

        Driver works well. So code setting should be OK. But I need some document to explain how to map SCIINTVECT and SCIFLR to customer. The register manual did not provide good explanations. 

    Regards

    Andre

  • 0 in reply to AndreTseng
    TI__Mastermind 22893 points

    Hey Andre,

    It's important to note the SCIINTVECT will only hold the highest priority interrupt. Is it possible that that ID interrupt (0x4) was also triggered?

    For these interrupts Offset 1 is the highest priority and Offset 16 is the lowest priority. Due to this fact, the SCIINTVECT register would capture the higher priority ID interrupt versus lower priority Receive interrupt.

    There isn't a direct mapping between these two registers. Instead, the SCIINTVECT register will always use the hardcoded offset values as defined in the driver code and TRM table (including below for quick reference).

    Reading the SCIINTVECT register will clear the associated flag in SCIFLR and update to the next highest priority pending interrupt in SCIFLR (with exception of receive/transmit (9/8) interrupts which as mentioning earlier must be manually cleared).

    Hopefully this helps to bring further clarification. Please follow up with any additional comments/questions.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    TI__Intellectual 2555 points

    Zack,

        I tested with responder mode and multibuffer mode. Responder will send back response data after it receives valid ID.  When LIN responder receives valid matched ID, according to TRM as below, it will only got ID interrupt. During this time, I got SCIINTVECT = 0x04 and bit 29 IDRXFLASG is set in SCIFLR.  The behavior is not matched your description.

      Regards

    Andre

  • 0 in reply to AndreTseng
    TI__Mastermind 22893 points

    Hello Andre,

    In this case it seems that the ID flag (ID) and Checksum Error flag (CE) are being set. Since ID vector (0x4) is higher priority than CE vector (0x8) so SCIINTVECT will contain (0x4) ID interrupt, after reading this, the ID error flag is cleared the next highest priority interrupt will be loaded. The CE flag will remain set until another read from SCIINTVECT register.

    This behavior is as expected. Remember that when viewing the SCIINTVECT register content in the Register View or Memory Map View still counts as register read and hence will clear the relevant bits in the SCIFLR register.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    TI__Intellectual 2555 points

    Zack, 

          We are circle around. VECTOR = 0x04 is not qual bit shift 29 in SCIFLR. 

    Any document to describe where this VECTOR value coming from? I can't always ask custom check .h file.

    If something goes wrong, how can we find it?

    Regards

    Andre

  • 0 in reply to AndreTseng
    TI__Mastermind 22893 points

    Hey Andre,

    The SCI/LIN Interrupt Offset table from the TRM describes the vector mapping. The first column is the offset value that is set in the SCIINTVECTx register according to the associated highest priority SCIFLR flag being set.

    Let us know if additional clarification is needed here.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    TI__Intellectual 2555 points

    Zack,

        This is much better then description in Register Addendum.

    Regards

    Andre

  • 0 in reply to AndreTseng
    TI__Mastermind 22893 points

    Thank you for pointing this out. I will file a ticket to have this Bitfield description updated to provide better clarity.