• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 32 subscribers
  • Views 596 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.

RM48L952: Explain Halcogen 04.05.02 to 04.06.00 SCI sciEnableNotification difference

Jamie Wardlaw
Expert 1895 points
Part Number: RM48L952
Other Parts Discussed in Thread: HALCOGEN

Hello, we have a build on the RM48x that integrates a third part communication stack utilizing the SCI driver. This build has been shown to successfully integrate the third party stack on a HAL generated from 04.05.02 of HALcogen, however we cannot get it to run on 04.06.00 HAL generation. The issues appears to be getting the TX interrupt generated and has been traced to the sciEnableNotification routine. It seems that in movign from 04.05.02 to 04.06.00 the sciEnableNotification routine has changed in how it loads (and clears) the SETINT register:

04.06.00

 

void sciEnableNotification(sciBASE_t *sci, uint32 flags)
{
    uint32 index = (sci == sciREG) ? 0U : 1U;

/* USER CODE BEGIN (23) */
/* USER CODE END */

    g_sciTransfer_t[index].mode |= (flags & (uint32)SCI_TX_INT);
    sci->SETINT                = (flags & (uint32)(~(uint32)(SCI_TX_INT)));

/* USER CODE BEGIN (24) */
/* USER CODE END */
}

04.05.02

void sciEnableNotification(sciBASE_t *sci, uint32 flags)
{
    uint32 index = (sci == sciREG) ? 0U : 1U;

/* USER CODE BEGIN (23) */
/* USER CODE END */

    g_sciTransfer_t[index].mode |= (flags & (uint32)SCI_TX_INT);
    sci->SETINT                = (flags);

/* USER CODE BEGIN (24) */
/* USER CODE END */
}

Can someone explain the reason for changing how SETINT is loaded and cleared? Running the 04.06.02 line of code in the 04.05.02 builds replicates our failure to generate TX interrupts so I think it is a root cause of our issues. If I understand why the driver has been changed I can work back to how we are calling it to ensure we transfer the appropriate data.


Thanks

Jamie

 

 

void sciEnableNotification(sciBASE_t *sci, uint32 flags)
{
    uint32 index = (sci == sciREG) ? 0U : 1U;

/* USER CODE BEGIN (23) */
/* USER CODE END */

    g_sciTransfer_t[index].mode |= (flags & (uint32)SCI_TX_INT);
    sci->SETINT                = (flags);

/* USER CODE BEGIN (24) */
/* USER CODE END */
}

  • 0
    TI__Guru 59540 points
    Hello Jamie,

    Most likely, this was due to a reported bug on the halcogen code, but I am not familiar with why the change was truly made. I forwarded your question to our SW lead so that he can reply with the reason for the change and if it was due to a reported bug, he can elaborate on the symptoms of the bug.
  • 0
    TI__Genius 14205 points

    Hi Jamie,

    I do not see any difference in sciEnableNotification() function between 4.05.02 and 4.06.00.

    The reason we do not want SCI_TX_INT to be enabled in SETINT before the data is written to TX register.

    User need not worry since when sciSend() is called for TX, SCI_TX_INT is enabled by the function.

    To use TX interrupt all that user has to do is either Enable TX_INT through HALCoGen GUI, SCI Tab, or passing SCI_TX_INT as parameter to sciEnableNotification(). rest all are taken care by  sciSend().

  • 0 in reply to Prathap
    Expert 1895 points

    Hello Prathap,


    I'm not sure I undersand why you say there is no difference? Clearly the setting of the SETINT register is done differently.

    04.05.02 : sci->SETINT                = (flags);

    06.04.00 :  sci->SETINT                = (flags & (uint32)(~(uint32)(SCI_TX_INT)));

    If we pass SCI_TX_INT to the enableNotification in the latest HALcogen build I do not get my interrupts generated which if I understand the change to the code would make sense as ~SCI_TX_INT inverts the bit?
    The third party stack we are integrating manages the TX and RX interrupts to transfer bytes of data, calling sciSendByte and sciReceiveByte upon receipt of the appropriate interrupt. On my 04.05.02 builds this works well, but on 04.06.00 builds with the line as shown above we lose our interrupts.
    I do enable the TX, RX and fault interrupts in HALcogen but our protocol also controls via sciEnable/DisableNotifications the status of the interrupts. This works with 04.05.02 but since you changed the above line of code in 06.04.00 it does not work.
    There may be other issues with our integration that I have not found yet, but I still don't understand why the above line of code was changed between 04.05.04 and 06.04.00