AWRL6432BOOST: Add LIN bus function issue to Kick_to_Open examples code

Hi Johnny,
I have looped in our SW expert. Please allow us a day or so to provide the respond.

Thanks and Regards,
Sivaprasad

Hi,

Have you looked through this document in the Radar Toolbox?

https://dev.ti.com/tirex/content/radar_toolbox_2_20_00_05/source/ti/examples/Fundamentals/LIN_Integration/docs/LIN_Integration_User_Guide.html

Thanks,

Clinton

So I can't use Lin bus through interrupt?

I referred to radar_toolbox_2_10_00_04-LIN_Integration and modified the following parts

//======

typedef enum{
LIN_RESPONSE_RX,
LIN_RESPONSE_TX,
LIN_RESPONSE_IGNORE,
}linResponseType_t;

typedef struct{
uint16_t ID;
linResponseType_t responseType;
uint8_t datalength;
uint16_t transmitData[8];
}linFrameProcessStruct_s;

linFrameProcessStruct_s linFrameDatabase[] = {
/* ID Response Type Length Response Frame (if Any) */
{ 0x10, LIN_RESPONSE_RX, 8 },
{ 0x11, LIN_RESPONSE_TX, 8, { 0x12, 0x34, 0x56, 0x78, 0x90, 0x12, 0x34, 0x56 }},
};

void LIN_write(uint32_t baseAddr, uint16_t id, uint16_t *data, uint16_t length)
{
if(LIN_isRxMatch(APP_LIN_BASE_ADDR))
{
if((LIN_getRxIdentifier(APP_LIN_BASE_ADDR) & 0x3F) == 0x10)
{
LIN_setFrameLength(APP_LIN_BASE_ADDR, 8);
}
else if((LIN_getRxIdentifier(APP_LIN_BASE_ADDR) & 0x3F) == 0x11)
{
LIN_setFrameLength(APP_LIN_BASE_ADDR, 8);
/* Set the buffer from where the data is to be sent (of length sentFrameLength)*/
LIN_sendData(APP_LIN_BASE_ADDR, (uint16_t*)linFrameDatabase[1].transmitData);
/* Wait until Transmit buffer is empty and has completed transmission */
while(!LIN_isTxBufferEmpty(APP_LIN_BASE_ADDR));
}
}
}

//======

The situation is the same, there is no response after the first transmission!

Hi,

Thanks for the additional details. We'll follow up in a day or so with more feedback.

Thanks again,

Clinton

Hey Johnny,

You should be able to use interrupts with the LIN bus by enabling interrupts in SysConfig for your project and enabling the Rx buffer ready and Tx buffer ready interrupts for one of the interrupt lines. You can then define an ISR for the given line which checks whether a Tx and Rx operation has occurred and does any additional signaling or functionality needed. You can see an example of this in the LIN external responder interrupt example under <MMWAVE_LSDK_INSTALL_DIR>/examples/drivers/lin/lin_external_responder_interrupts which includes some additional interrupts such as wakeup and error handling.

Regards,

Kristien

I enabled all interrupts and printed the log of Void level0ISR(void * args) as follows

No further interruptions will occur thereafter.

level0ISR:vectorOffset 0x10
level0ISR:vectorOffset 0x00
level0ISR:vectorOffset 0x04
level0ISR:vectorOffset 0x00
level0ISR:vectorOffset 0x0B
level0ISR:vectorOffset 0x00
level0ISR:vectorOffset 0x10
level0ISR:vectorOffset 0x00
New Frame Received 0x10(ID) 01 02 03 04 05 06 07 08

Hey Johnny,

Just to clarify, after enabling the interrupts, you are able to receive data from a signal interrupt, but the program fails afterwards, right? Are you using DebugP_log to print out during an ISR? If so, DebugP_log can crash out a program due to its high latency, hence why print outs are only included in the main loop of the LIN external responder interrupt example.

Regards,

Kristien

I no longer use DebugP_log, but display the log through UartWrite. The situation is the same whether it is displayed or not. After receiving the first command from the lin bus, I saw the TX interrupt, but the Lin bus master did not receive any data. No further interruptions will occur after this.

Hey Johnny,

Just to verify, are you sending the request frame as well (ID 0x11)? Based on how your linFrameDatabase is set up, there would be no response from 0x10 which appears to be true based on your previous reply. Otherwise, the only way to trigger a transmit from the radar LIN transceiver would be to send over the request frame 0x11.

If you are triggering the Tx interrupt, does this occur after the new frame received? Again, based on your previous reply, I only see the interrupts being triggered for timeout (0x10), ID (0x04), Rx (0x0B), and no interrupts (0x00).  

Finally, just so we are on the same page, are you using the LIN external responder interrupts example for testing currently? If so, are the only changes: changed the linFrameDatabase to match your application; printing interrupt values over UART; and enabling all interrupts in SysConfig for interrupt line 0? Is there a particular reason you enabled all interrupts rather than just the Tx buffer ready, Rx buffer ready, wakeup, and matching ID interrupts which should support most of the necessary functionality needed here?

Regards,

Kristien

It is normal for the LIN bus to use interrupt mode and polling mode alone. However, there is a problem when adding the above functionality to the Kick_to_Open sample code. Refer to radar_toolbox_2_10_00_04-LIN_Integration, adding LIN bus polling mode will also have the same problem.

It seems to be related to low power mode, but according to radar_toolbox_2_10_00_04-LIN_Integration, I don’t know why there is still a problem.

Hey Johnny,

During low power deep sleep (LPDS), the LIN peripheral is powered off along with most other peripherals. This means that no LIN messages can be received or sent out during the duration of LPDS. 

You could either disable LPDS if lower power consumption is not a priority or attempt to define a new power state for the device which does not disable LIN. The latter option is more complicated as it involves modifying and expanding the power state control including the power management task, policy functions, and power state functions.

Regards,

Kristien

So I referred to radar_toolbox_2_10_00_04-LIN_Integration and modified the following part

//======

typedef enum{
LIN_RESPONSE_RX,
LIN_RESPONSE_TX,
LIN_RESPONSE_IGNORE,
}linResponseType_t;

typedef struct{
uint16_t ID;
linResponseType_t responseType;
uint8_t datalength;
uint16_t transmitData[8];
}linFrameProcessStruct_s;

linFrameProcessStruct_s linFrameDatabase[] = {
/* ID Response Type Length Response Frame (if Any) */
{ 0x10, LIN_RESPONSE_RX, 8 },
{ 0x11, LIN_RESPONSE_TX, 8, { 0x12, 0x34, 0x56, 0x78, 0x90, 0x12, 0x34, 0x56 }},
};

void LIN_write(uint32_t baseAddr, uint16_t id, uint16_t *data, uint16_t length)
{
if(LIN_isRxMatch(APP_LIN_BASE_ADDR))
{
if((LIN_getRxIdentifier(APP_LIN_BASE_ADDR) & 0x3F) == 0x10)
{
LIN_setFrameLength(APP_LIN_BASE_ADDR, 8);
}
else if((LIN_getRxIdentifier(APP_LIN_BASE_ADDR) & 0x3F) == 0x11)
{
LIN_setFrameLength(APP_LIN_BASE_ADDR, 8);
/* Set the buffer from where the data is to be sent (of length sentFrameLength)*/
LIN_sendData(APP_LIN_BASE_ADDR, (uint16_t*)linFrameDatabase[1].transmitData);
/* Wait until Transmit buffer is empty and has completed transmission */
while(!LIN_isTxBufferEmpty(APP_LIN_BASE_ADDR));
}
}
}

//======

The situation is the same, there is no response after the first transmission!

Hey Johnny,

Please respond to the following questions below.

As asked before, are you sending the request frame as well (ID 0x11)? Based on how your linFrameDatabase is set up, there would be no response from 0x10 which appears to be the only message sent based on the UART log posted in one of your previous replies. Otherwise, the only way to trigger a transmit from the radar LIN transceiver would be to send over the request frame 0x11.

If you are triggering the Tx interrupt, does this occur after the new frame received? Again, based on your previous reply, I only see the interrupts being triggered for timeout (0x10), ID (0x04), Rx (0x0B), and no interrupts (0x00).  

In the LIN integration example, did you only change the following: changed the linFrameDatabase to include a receive ID and response ID; printing interrupt values over UART; and enabling all interrupts in SysConfig for interrupt line 0? Is there a particular reason you enabled all interrupts rather than just the Tx buffer ready, Rx buffer ready, wakeup, and matching ID interrupts which should support most of the necessary functionality needed here?

Where are you calling LIN_write in the LIN integration code? Without modifications, the LIN_write function is called in the mmwDemo_TransmitProcessedOutputTask to send out the classifier output over LIN. Based on how you've set up LIN_write, this function checks for a valid Rx message and either takes in data or sends a response similar to the lin_process_frames function from the LIN external responder interrupts example. However, in the LIN external responder interrupts example, the function is called within the ISR (level0ISR). Therefore, have you set up an ISR for the LIN Level 0 interrupt? Otherwise, you are not properly servicing the interrupt you configured earlier.

Regards,

Kristien

Currently, the LIN BUS simulator is set to the master side, 0x10: master->slave 8 bytes; 0x11: slave->master 8 bytes.

linFrameProcessStruct_s linFrameDatabase[] = {
/* ID Response Type Length Response Frame (if Any) */
{ 0x10, LIN_RESPONSE_RX, 8 },
{ 0x11, LIN_RESPONSE_TX, 8, { 0x12, 0x34, 0x56, 0x78, 0x90, 0x12, 0x34, 0x56 }},
};

First, let me refer to the example
MMWAVE_L_SDK_05_05_00_02-lin_external_responder_interrupts
Only modify the above parts and LIN checksum type -> Checksum Enhanced, and the connection simulator will operate normally.

Then add this section to the example radar_toolbox_2_10_00_04-Kick_to_Open
When a problem occurs, ask whether the interrupt method cannot be used. As per your suggestion, I referred to radar_toolbox_2_10_00_04-LIN_Integration and changed it to polling mode.

Only the following parts are modified, and no other changes are made.

//======

typedef enum{
LIN_RESPONSE_RX,
LIN_RESPONSE_TX,
LIN_RESPONSE_IGNORE,
}linResponseType_t;

typedef struct{
uint16_t ID;
linResponseType_t responseType;
uint8_t datalength;
uint16_t transmitData[8];
}linFrameProcessStruct_s;

linFrameProcessStruct_s linFrameDatabase[] = {
/* ID Response Type Length Response Frame (if Any) */
{ 0x10, LIN_RESPONSE_RX, 8 },
{ 0x11, LIN_RESPONSE_TX, 8, { 0x12, 0x34, 0x56, 0x78, 0x90, 0x12, 0x34, 0x56 }},
};

void LIN_write(uint32_t baseAddr, uint16_t id, uint16_t *data, uint16_t length)
{
if(LIN_isRxMatch(APP_LIN_BASE_ADDR))
{
if((LIN_getRxIdentifier(APP_LIN_BASE_ADDR) & 0x3F) == 0x10)
{
LIN_setFrameLength(APP_LIN_BASE_ADDR, 8);
}
else if((LIN_getRxIdentifier(APP_LIN_BASE_ADDR) & 0x3F) == 0x11)
{
LIN_setFrameLength(APP_LIN_BASE_ADDR, 8);
/* Set the buffer from where the data is to be sent (of length sentFrameLength)*/
LIN_sendData(APP_LIN_BASE_ADDR, (uint16_t*)linFrameDatabase[1].transmitData);
/* Wait until Transmit buffer is empty and has completed transmission */
while(!LIN_isTxBufferEmpty(APP_LIN_BASE_ADDR));
}
}
}

void gesture_recognition(void *args)  and void power_LPDSresumehook(void)
{

.

.

.

/* Enter Software Reset State */
LIN_enterSoftwareReset(APP_LIN_BASE_ADDR);

/* Enable multi-buffer mode */
LIN_enableMultibufferMode(APP_LIN_BASE_ADDR);

/* Enable Fixed baud rate mode */
LIN_disableAutomaticBaudrate(APP_LIN_BASE_ADDR);

/* Reaching the Baud of 19200 */
LIN_setBaudRatePrescaler(APP_LIN_BASE_ADDR, 130U, 0U);

/* Enable the triggering of checksum compare on extended frames */
LIN_triggerChecksumCompare(APP_LIN_BASE_ADDR);

LIN_setChecksumType(APP_LIN_BASE_ADDR, LIN_CHECKSUM_ENHANCED);
LIN_setLINMode(APP_LIN_BASE_ADDR, LIN_MODE_LIN_RESPONDER);

/* Finally exit SW reset and enter LIN ready state */
LIN_exitSoftwareReset(APP_LIN_BASE_ADDR);

}

//======

If a while loop is used before sensor start, the LIN bus operates normally, indicating that the relevant settings of the LIN bus are correct.

Hey Johnny,

From my understanding, the behavior you've seen makes sense. In summary, you've configured the LIN transceiver to function in polling mode by constantly calling the LIN_write function which will check for an Rx match and based on ID, either store or respond to a message.

If you want to send and receive messages without polling, you will still need to set up the interrupt in SysConfig - see my first reply in this thread - and an ISR similar to the level0ISR in the LIN external responder interrupt example. In the level0ISR, you could substitute the lin_process_frames function directly with your LIN_write function.

Regards,

Kristien

I use the interrupt method and set hwiPrms.priority = 6;
The interrupt method cannot be used, because the continuous transmission of the LIN BUS master will cause the interrupt to occupy all system resources.
In addition, set hwiPrms.priority = 7; the system crashes after replying once.

In power_LPDSresumehook(void), resetting the LIN bus related settings does not seem to take effect.

If polling is used, the previous problem still occurs. This issue has been dealt with for a long time! Is there a more efficient way? Thanks!

In addition, I cannot use LIN_initModule() because it will cause the system to crash! I don’t know why?

Hey Johnny,

To avoid overloading the interrupt controller, you could try to reduce the types of interrupts that are triggered to solely the ID (0x04) and Rx (0x0B) interrupts in SysConfig and modify the ISR to only handle LIN_VECT_ID (0x04) and LIN_VECT_RX (0x0B).

Johnny Chou said:

In power_LPDSresumehook(void), resetting the LIN bus related settings does not seem to take effect.

What exactly is failing to take effect when resetting the LIN bus settings? For example, is the baud rate not 19200 bps? Is it using a classic checksum instead?

Johnny Chou said:

In addition, I cannot use LIN_initModule() because it will cause the system to crash! I don’t know why?

Where is it crashing in the code - i.e., what line of code is failing - and is an error vector reported out in the debugger - e.g., HwiP_hardFault, HwiP_memFault, HwiP_busFault? Based on the last screenshot, you should avoid continuously reinitializing the LIN_initModule. However, this may also depend on what the App_linbusPollingCheck and App_linbusIntInit functions do. Therefore, could you show the code for the App_linbusPollingCheck and App_linbusIntInit functions?

Regards,

Kristien

I've tried reducing the interrupt types in the SysConfig to only trigger the ID (0x04) and Rx (0x0B) interrupts, and modified the ISR to only handle LIN_VECT_ID (0x04) and LIN_VECT_RX (0x0B), but no improvement.

After the system executes power_LPDSresumehook(void), the LIN BUS interrupt no longer occurs, which means that the LIN BUS has not been successfully initialized.

Because the debug message cannot be easily left, there is no way to know where the crash occurred in the program code. All we can see is the stop screen as shown below.

I test LIN_initModule() in a loop. The main purpose is to simulate how to successfully reset the LIN BUS when the system resets all drive devices through low power mode.

The following is a code snippet:

//========================================

void App_linbusIntInit()
{
HwiP_Params hwiPrms;
int32_t status = SystemP_SUCCESS;

//LIN_initModule(CONFIG_LIN1_BASE_ADDR);

/* Register interrupt */
HwiP_Params_init(&hwiPrms);
hwiPrms.intNum = APP_LIN_INTR_NUM_0;
hwiPrms.callback = &level0ISR;
hwiPrms.priority = 5;
status = HwiP_construct(&gLinHwiObject_0, &hwiPrms);
DebugP_assert(status == SystemP_SUCCESS);

/* Enter Software Reset State */
LIN_enterSoftwareReset(APP_LIN_BASE_ADDR);

/* Enable multi-buffer mode */
LIN_enableMultibufferMode(APP_LIN_BASE_ADDR);

/* Enable Fixed baud rate mode */
LIN_disableAutomaticBaudrate(APP_LIN_BASE_ADDR);

/* Reaching the Baud of 19200 */
LIN_setBaudRatePrescaler(APP_LIN_BASE_ADDR, 130U, 0U);

/* Enable the triggering of checksum compare on extended frames */
LIN_triggerChecksumCompare(APP_LIN_BASE_ADDR);

LIN_setChecksumType(APP_LIN_BASE_ADDR, LIN_CHECKSUM_ENHANCED);
LIN_setLINMode(APP_LIN_BASE_ADDR, LIN_MODE_LIN_RESPONDER);

/* Finally exit SW reset and enter LIN ready state */
LIN_exitSoftwareReset(APP_LIN_BASE_ADDR);
}

void App_linbusInit()
{
//LIN_initModule(CONFIG_LIN1_BASE_ADDR);

/* Enter Software Reset State */
//LIN_enterSoftwareReset(APP_LIN_BASE_ADDR);

/* Enable multi-buffer mode */
//LIN_enableMultibufferMode(APP_LIN_BASE_ADDR);

/* Enable Fixed baud rate mode */
//LIN_disableAutomaticBaudrate(APP_LIN_BASE_ADDR);

/* Reaching the Baud of 19200 */
LIN_setBaudRatePrescaler(APP_LIN_BASE_ADDR, 130U, 0U);

/* Enable the triggering of checksum compare on extended frames */
//LIN_triggerChecksumCompare(APP_LIN_BASE_ADDR);

//LIN_setChecksumType(APP_LIN_BASE_ADDR, LIN_CHECKSUM_ENHANCED);
//LIN_setLINMode(APP_LIN_BASE_ADDR, LIN_MODE_LIN_RESPONDER);

/* Finally exit SW reset and enter LIN ready state */
//LIN_exitSoftwareReset(APP_LIN_BASE_ADDR);
}

void App_linbusPollingCheck()
{
/* Check if new data has been received */
if(rxReceivedID != INVALID_ID)
{
/* Read the received data in the receive buffers */
LIN_getData(APP_LIN_BASE_ADDR, rxDatas);

for (uint8_t dataIndex=0; dataIndex < sentFrameLength; dataIndex++)
{
}
/* Check if Sleep Frame ID was received */
if(SLEEP_FRAME_PID == rxReceivedID)
{
/* Check if sleep frame was received */
if(!memcmp((uint8_t*)rxDatas, (uint8_t*)lin_sleepFrame, 8))
{
/* Set Lin to powerdown or sleep mode */
LIN_enterSleep(APP_LIN_BASE_ADDR);
}
}
rxReceivedID = INVALID_ID;
}

/* Check if the response has been transmitted for the requested ID*/
if(txDoneID != INVALID_ID)
{
for (uint8_t dataIndex=0; dataIndex < sentFrameLength; dataIndex++)
{
}
txDoneID = INVALID_ID;
}

/* Check if an unknown id is received */
if(ignoreID != INVALID_ID)
{
}

/* Check if wakeup has occurred */
if(wakeupInterruptFlag)
{
wakeupInterruptFlag = 0;
}

/* Check if any errors were triggered */
if(linErrorFlag)
{
switch(linErrorFlag)
{
case LIN_VECT_ISFE :
break;
case LIN_VECT_PBE :
break;
case LIN_VECT_PE :
break;
case LIN_VECT_FE :
break;
case LIN_VECT_CE :
break;
case LIN_VECT_OE :
break;
case LIN_VECT_BE :
break;
case LIN_VECT_NRE :
break;
default:
break;
}
linErrorFlag = 0;
}
}

Hey Johnny,

To confirm, the application fails after the first frame, correct? If so, this could be a frame period issue. Gesture recognition and kick-to-open have tight timing constraints that can cause the application to crash out if there isn't sufficient time. I would recommend trying to increase the frame periodicity in your configuration file. 

If the end application does not matter for your LIN testing, I would also try to implement your existing LIN code into a different demo such as the mmWave demo or the Motion and Presence Detection demo since these two demos tend to be more lenient in timing.

Regards,

Kristien

Yes, the application fails after the first frame. I tried to modify the fifth parameter of "framecfg" in the configuration file,For example "frameCfg 2 0 200 128 170 0 \n\r", but the situation was the same.

In addition, I implemented part of the LIN BUS into the Motion and Presence Detection demo and it was normal.

Because we also need to implement the LIN BUS function in Gesture recognition and kick-to-open, we still have to solve this problem! Thanks!

Hey Johnny,

I will look into testing the code you've shared so far and check to see where there may be a timing issue.

Regards,

Kristien

Are there any new updates? Thanks!
Why doesn't polling solve the timing issue?
I tried using interrupts or polling in the motion and presence detection demo, both worked normal.

Hey Johnny,

Sorry for the delay. Please give me one more day to look into this. I will send out a response tomorrow.

Regards,

Kristien

Hey Johnny, 

I attempted to test this on my side, but I'm currently unable to transmit LIN messages to the radar device due to an instrumentation issue. I'm working on resolving that, so in the meantime, I'll answer your previous question.

Johnny Chou said:

Why doesn't polling solve the timing issue?

Based on what we've discussed so far, this could be for a number of things, such as entering and exiting low power mode or the restrictive timing of the gesture recognition demo. However, we've already discussed many of the solutions and workarounds to this - i.e., disabling or emulating low power mode by setting lowPowerCfg to 0 or 2 respectively and increasing frame periodicity. I still find it strange that increasing frame periodicity does not resolve this issue as this is typically the most common way of resolving timeout issue. 

Regards,

Kristien

We have no new ideas at the moment. Not sure how to proceed with this.

Hey Johnny,

Sorry for the delay here. I've identified the issue with my test setup and will have it resolved by Monday. I should be able to resume testing by then. One quick question in the meantime: are you attempting to run AWRL1432 projects on AWRL6432?

Thank you for your patience,

Kristien

I executed the AWRL1432 project on AWRL6432 and modified the definition.

Hey Johnny,

Just to confirm, have you changed the following:

• Under Project Properties -> Build -> Arm Compiler -> Include Options, change ${MCU_PLUS_SDK_PATH}/source/kernel/freertos/config/xwrL14xx/m4f to ${MCU_PLUS_SDK_PATH}/source/kernel/freertos/config/xwrL64xx/m4f
• Under Project Properties -> Build -> Arm Compiler -> Predefined Symbols, change SOC_XWRL14XX to SOC_XWRL64XX
• Under Project Properties -> Build -> Arm Linker -> File Search Path, change all .lib files from xwrL14xx to xwrL64xx

Regards,

Kristien

That's right! It is to modify these parts.

Hey Johnny,

Thank you for verifying this information. Could you update your LIN Integration project with the latest Radar Toolbox release, 2_20_00_05? This LIN project supports SDK 5.4 whereas the 2_10 release only supports SDK 5.3.4.1. This will also ensure that we are on the same version and eliminate any mismatch in project behavior on my side and your side due to a potential version difference.

Let me know if updating to the latest version helps or changes the behavior observed.

Regards,

Kristien

The situation is the same with Radar Toolbox version 2_20_00_05.

Are there any new updates? Thanks!

Hey Johnny,

I apologize for the delay in getting back to you. There may be an issue with the LIN integration example that I'm looking into and will fix by the next Radar Toolbox release which should be available by the end of this month. 

The issue appears to be related to which files the project is pulling in when importing into CCS which causes an error in configuring the device. This should lead to the application failing when attempting to start the sensor. As such, could you confirm that the application fails when attempting to start the sensor after configuring the device?

Regards,

Kristien

When I try to start the sensor after configuring the device, not even the first pen appears.

Hey Johnny,

Interesting, sounds like it may be related to the previously mention import issue for the project. Again, I'll be looking into this further and will attempt to fix this by the next Radar Toolbox release. For now, I would recommend confirming that the mmw_cli.c file imported into the LIN Integration project matches the mmw_cli.c file of the KTO project for SDK 5.4.

Also, I will be out next Monday, so I won't be able to reply until October 22nd.

Regards,

Kristien

When will the next version of Radar Toolbox be released?Thanks!

Hey Johnny,

The next Radar Toolbox release should be available by the end of next week. 

Regards,

Kristien

Is the next version of Radar Toolbox released? Thanks!

Hey Johnny,

The next version of the Radar Toolbox should be available next week. I will send out another message when its available.

Regards,

Kristien

Hey Johnny,

We will be releasing the Radar Toolbox by the end of this week. I apologize for the shifting deadline, but we are entering our final clean up before release.

Regards,

Kristien