• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 249 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

TMDS570LS31HDK: SL_SelfTest_SCI SCI_ANALOG_LOOPBACK_TEST stuck waiting for pin to go idle.

RM44L920: LIN_ANALOG_LOOPBACK_TEST fail at verifying if LIN is not in reset state

Ilija Cakovic
Prodigy 110 points
Part Number: RM44L920

Tool/software:

Hello,

I am trying to perform an analog loopback test for the LIN module using the SafeTI Diagnostic Library. When I call the function SL_SelfTest_LIN() for this purpose, it fails at the step where it verifies if the LIN module is out of the reset state. The return value retVal is set to FALSE. Here's the code snippet that performs the reset state check:

Fullscreen
1
status = SL_SelfTest_LIN(LIN_ANALOG_LOOPBACK_TEST, SL_LIN1);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
/*verify LIN is not in reset state */
/*SAFETYMCUSW 439 S MR:11.3 <APPROVED> Comment_4*/
if(sl_linREG != NULL)
{
/*SAFETYMCUSW 134 S MR: 12.2 <APPROVED> Comment_5*/
if((LIN_GCR0_RESET_BIT|LIN_GCR1_SWRST_BIT) != (sl_linREG->GCR0 & (LIN_GCR0_RESET_BIT|LIN_GCR1_SWRST_BIT)))
{
#if (FUNC_ENTRY_COND_CHECK_LOG_ENABLED !=0)
SL_Log_Error(FUNC_ID_ST_LIN, ERR_TYPE_ENTRY_CON, 1u);
#endif
retVal = FALSE;
return retVal;
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

As I understand, this condition checks if sl_linREG->GCR0 has the value 0x81. However, the GCR0 register, cannot have this value, which makes me wonder if this is a bug in the SafeTI Diagnostic Library.

Here is my initialization function for LIN module

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
void sciInit(UartInit_t* Uart_init_struct)
{
/* USER CODE BEGIN (2) */
/* USER CODE END */
/** @b initialize @b SCILIN */
/** - bring SCI out of reset */
scilinREG->GCR0 = 0U;
scilinREG->GCR0 = 1U;
/** - Disable all interrupts */
scilinREG->CLEARINT = 0xFFFFFFFFU;
scilinREG->CLEARINTLVL = 0xFFFFFFFFU;
/** - global control 1 */
scilinREG->GCR1 = (uint32)((uint32)1U << 25U) /* enable transmit */
| (uint32)((uint32)1U << 24U) /* enable receive */
| (uint32)((uint32)1U << 5U) /* internal clock (device has no clock pin) */
| (uint32)((uint32)(Uart_init_struct->stop_bits-1U) << 4U) /* number of stop bits */
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

GCR0 register is set to 1, which means that module is out of reset, and at the end GCR1 is set to 0x80.

Is this a software bug in the library, or is there a configuration issue on my side?

Thanks & regards,

Ilija

  • 0
    Prodigy 110 points

    I was able to identify the issue causing the failure of the SL_SelfTest_LIN() function after some thorough debugging.

    The problem was that I should have used SL_SelfTest_SCI() function, but this function was causing error because it was checking SCI registers (with the base address FFF7 E500h) and since I had configured the SCI/LIN module's registers (with the base address FFF7 E400h), the check for the SCI module's reset state naturally failed, and the function returned FALSE.

    Additionally, I discovered that the SDL does not provide a specific function to perform an analog loopback test for the combined SCI/LIN module. If such functionality is required, it may need to be implemented manually by configuring the relevant registers for the loopback mode and verifying the results.

     

  • 0 in reply to Ilija Cakovic
    TI__Guru 63035 points

    Hi Ilija,

    My apologies for the late response.

    Ilija Cakovic said:
    As I understand, this condition checks if sl_linREG->GCR0 has the value 0x81. However, the GCR0 register, cannot have this value, which makes me wonder if this is a bug in the SafeTI Diagnostic Library.
    Ilija Cakovic said:
    GCR0 register is set to 1, which means that module is out of reset, and at the end GCR1 is set to 0x80.

    You are totally correct they should not check 0x81 in GCR0 for SL_SelfTest_LIN function.

    They should check 0x01 in GCR0, if this bit is 1 means LIN is out of reset. 

    Similarly, they should check 0x80 in GCR1, if this bit is 1 means LIN is in ready state.

    Here for LIN module, they are mistakenly checking 0x81 on GCR0 only. I will note down this issue and we will correct this in our future revisions.

    Ilija Cakovic said:
    The problem was that I should have used SL_SelfTest_SCI() function, but this function was causing error because it was checking SCI registers (with the base address FFF7 E500h) and since I had configured the SCI/LIN module's registers (with the base address FFF7 E400h), the check for the SCI module's reset state naturally failed, and the function returned FALSE.
    Ilija Cakovic said:
    Additionally, I discovered that the SDL does not provide a specific function to perform an analog loopback test for the combined SCI/LIN module. If such functionality is required, it may need to be implemented manually by configuring the relevant registers for the loopback mode and verifying the results.

    You are totally correct.

    There are two SCI instances are there in this controller.

    One is standalone SCI which is starting at base address 0xFFFFE500

    Another one is multiplexed with LIN module at base address of 0xFFFFE400

    And you are totally correct there is no SCI self test functionality available for this multiplexed SCI, only there is testing for stand alone SCI.

    Currently you can just manually add one more case in this SCI self test function to test multiplexed SCI.

    And you can use below highlighted MACRO for this purpose.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 110 points

    Hi Jagadish,

    Thank you for your response. I implemented a custom function for the SCI/LIN analog loopback test, ensuring that it checks the appropriate registers. The implementation seems to be working as expected.

    However, I am uncertain whether modifying SDL functions is a good practice. Could you please confirm if making such changes is advisable?

    Additionally, I have a question regarding the SCI loopback function in the SDL library. I noticed that, at the end of the function, bit 16 of the GCR1 register (loopback enable bit) is not cleared to disable loopback mode. Is there a specific reason for this, or should it be handled explicitly in the function?

    Thanks & regards,

    Ilija

  • +1 in reply to Ilija Cakovic
    TI__Guru 63035 points

    Hi Ilija,

    Ilija Cakovic said:
    However, I am uncertain whether modifying SDL functions is a good practice. Could you please confirm if making such changes is advisable?

    It is fine to modify the SDL code which is included for your project. And some customers will only use part of the SDL, some required testings, so it is okay to customize the SDL for your project.

    Ilija Cakovic said:
    Additionally, I have a question regarding the SCI loopback function in the SDL library. I noticed that, at the end of the function, bit 16 of the GCR1 register (loopback enable bit) is not cleared to disable loopback mode. Is there a specific reason for this, or should it be handled explicitly in the function?

    You are correct actually the loopback should be disable in the SL_SelfTest_SCI itself after performing the loopback test.

    Previously one customer also reported this issue:

    (+) SafeTI Diagnostics Library HAL layer differs from HalCoGen generated code - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    I will note this issue, and we will take action on our next releases. In mean time you can manually add the loopback disable code.

    --
    Thanks & regards,
    Jagadish.