topic Problem from LIN_Driver_4.5.1 to LIN_Driver_4.5.9 in CodeWarrior for MCU

Problem from LIN_Driver_4.5.1 to LIN_Driver_4.5.9

simonliu — Mon, 13 May 2019 10:05:25 GMT

The driver package in the FSL_LIN_2.X_STACK.zip downloaded from the official website has been updated to FSL_LIN_2.x_STACK_4.5.9.exe.

Compared with the code generated by ncf_tool, it is true that the bit_offset has been updated and that there have been changes in the diagnostic section.

Compared to the driver source code, a lot of MCU macros have been added, the "{" position has been changed, and the diagnostic section has been modified a lot, as well as other changes. However, I did not see the relevant instructions for the specific change of curriculum vitae.

At present, there are the following problems:

Question 1:

The LIN_Driver is replaced by 4.5.1 with 4.5.9 and lin_cfg.c lin_cfg.h is also replaced, which does not affect the signal reading and writing of unconditional frames, but the 3C diagnostic read service is unable to respond.

Here is the diagnostic code for reading multiple frames on our side: please take a look at how to modify the code when using LIN_Driver_4.5.9.

const byte sw_number_date_identifier[4] = {0x20, 0x19, 0x03,0x16};

const byte software_version[3] = {'V', '0', '1'};

#define ECU_SW_NUMBER_DATE_IDENTIFIER 0xf188U

#define DATA_ID_SOFTWARE_VERSION 0xf212U

if(diag_get_flag(DIAGSRV_READ_DATA_BY_IDENTIFIER_ORDER) != FALSE)

{

diag_clear_flag(DIAGSRV_READ_DATA_BY_IDENTIFIER_ORDER);

ld_receive_message(&pdu_length, receive_message_buf);

data_id = ((l_u16)receive_message_buf[1] << 8) | receive_message_buf[2];

switch(data_id)

{

case ECU_SW_NUMBER_DATE_IDENTIFIER:

buf_size = sizeof(sw_number_date_identifier);

send_message_buf[0] = 0x62U;

send_message_buf[1] = data_id >> 8;

send_message_buf[2] = (uint8_t)data_id;

memory_copys(&send_message_buf[3],&sw_number_date_identifier[0],buf_size);

ld_send_message((3+buf_size), send_message_buf);

break;

case DATA_ID_SOFTWARE_VERSION:

buf_size = sizeof(software_version);

send_message_buf[0] = 0x62U;

send_message_buf[1] = data_id >> 8;

send_message_buf[2] = (uint8_t)data_id;

memory_copys(&send_message_buf[3],&software_version[0],buf_size);

ld_send_message((3+buf_size), send_message_buf);

break;

}

Question 2:

The test found that drivers 4.5.1 and 4.5.9 had the same problems:

When a signal is defined, the start bit and the stop bit span two bytes, l_u8_read () comes out correctly. For example, there is a signal TCU3_St_DriveMode, with a starting bit of 23 and a total of four bit,. I can only take out the relevant four bits from the two bytes of the lin_pFrameBuf myself to get it.

//LIN_TCU3_St_DriveMode = (u8)l_u8_rd(TCU3_St_DriveMode); /*由于跨字节了，读不正确，4.5.9与4.5.1都不正确*/

data1 = lin_pFrameBuf[5];

data2 = lin_pFrameBuf[6];

LIN_TCU3_St_DriveMode = ((data1 >>7&0x01)|((data2&0x07)<<1));

There is a signal definition for a project for the time being, which is why the problem has been discovered.

Question 3:

There is now a project that needs to be configured into a two-way LIN slave node mode. You can generate code through the ncf configuration tool, and you can see in the lin_cfg file that there is a definition defined as _ SLAVE_. in the MASTER_MODE,lin_ifc_configuration Then there is no problem with the use of the two LIN and the reading and writing of unconditional frames. But I now need to do LIN slave node conformance testing.

When testing and debug from the node consistency test script provided by the CANoe, the single-chip microcomputer will prompt the "No source available" as long as any one is executed,

Then I also tried, only using IG to simulate sending is also No source available.

I've tried with both 4.5.1 and 4.5.9 drivers, and LIN, configured to two slave nodes is No source available, but there is no No source available problem with LIN, configured all the way from the node. And CANoe can pass most of the test cases in the conformance test script of the node.

The problem will be more serious because the single-chip microcomputer had an unexpected "crash" and finally was reset by the watchdog to resume normal unconditional frame communication.

So when you recognize the configuration of the two-way slave node LIN, are these slave node conformance testing related diagnostic services already supported?

Re: Problem from LIN_Driver_4.5.1 to LIN_Driver_4.5.9

FelipeGarcia — Wed, 15 May 2019 20:31:28 GMT

Hello!

Thanks a lot for your comments!

There is actually a new version of the LIN stack. Could you please try using v4.6.1?

Here is the link: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=SW-LIN2X-J2602-D

Best regards,

Felipe

Re: Problem from LIN_Driver_4.5.1 to LIN_Driver_4.5.9

simonliu — Fri, 17 May 2019 02:03:58 GMT

Hi Felipe,

I use the new version of the LIN stack and have sloved some of the problems.

But for the question3, I need config 2ch LIN slave for application. I try to use NCF config the driver and there is no problem with the use of the two LIN and the reading and writing of unconditional frames.But I cannot pass the

Conformance Test of LIN.

Here is my config for diagnostic service:

/****************************Support SID Initialization ***********************/

const l_u8 KX11_IHU_lin_diag_services_supported[_KX11_IHU_DIAG_NUMBER_OF_SERVICES_] = {0xB2,0xB7,0x22,0x2E,0xB3,0xB0,0xB4,0xB6};

l_u8 KX11_IHU_lin_diag_services_flag[_KX11_IHU_DIAG_NUMBER_OF_SERVICES_] = {0,0,0,0,0,0,0,0};

const l_u8 KX11_CCM_lin_diag_services_supported[_KX11_CCM_DIAG_NUMBER_OF_SERVICES_] = {0xB2,0xB7,0x22,0x2E,0xB3,0xB6,0xB4,0xB0};

l_u8 KX11_CCM_lin_diag_services_flag[_KX11_CCM_DIAG_NUMBER_OF_SERVICES_] = {0,0,0,0,0,0,0,0};

The 0x22 service can get response bue the 0xB2/0xB7 can not get response.

I want to know the new version of the lin stack for 4.6.1 can support config 2ch LIN salve at same project and the diagnostic service can work for conformance test of LIN.

Re: Problem from LIN_Driver_4.5.1 to LIN_Driver_4.5.9

FelipeGarcia — Tue, 21 May 2019 16:22:06 GMT

Hi,

The LIN Stack package is compliant to LIN 2.0 and LIN 2.1 / 2.2a specifications. You can find this statement on the release notes.

Also, I known limitation is that conformance test coverage 99.06%.

Best regards,

Felipe

Re: Problem from LIN_Driver_4.5.1 to LIN_Driver_4.5.9

simonliu — Tue, 09 Mar 2021 06:04:17 GMT

Hi Felipe，

In the course of use, we found a problem with the protocol stack.

typedef union {
l_u8 byte; /**< a data byte refer to 8 data bits follow */
struct
{
/* LIN 2.1 */
l_u8 successful_transfer:1; /**< Transfer flag LIN 2.1*/
l_u8 error_in_response:1; /**< Error response LIN 2.1*/
l_u8 bus_activity; /**< Bus activity timeout LIN 2.1*/
/* J2602 */
l_u8 framing_error:1; /**< frame error flag J2602*/
l_u8 checksum_error:1; /**< checksum error flag */
l_u8 readback_error:1; /**< readback error in J2602 to be called Data Error */
l_u8 parity_error:1; /**< frame error flag */
l_u8 reset:1; /**< reset flag (not implemented) */
} bit;
} lin_status;

the bus_activity define is error.

It shuold be：

l_u8 bus_activity ：1;

/* Lin status bit mask */
#define LIN_STA_SUCC_TRANSFER 1 /**< LIN status bit mask: success transfer */
#define LIN_STA_ERROR_RESP 2 /**< LIN status bit mask: error in response */
#define LIN_STA_BUS_ACTIVITY 4 /**< LIN status bit mask: bus activity */
#define LIN_STA_FRAME_ERR 8 /**< LIN status bit mask: frame error */
#define LIN_STA_CHECKSUM_ERR 16 /**< LIN status bit mask: checksum error */
#define LIN_STA_READBACK_ERR 32 /**< LIN status bit mask: readback error */
#define LIN_STA_PARITY_ERR 64 /**< LIN status bit mask: parity error */
#define LIN_STA_RESET 128 /**< LIN status bit mask: reset */