CAN PAL Usage Issues with the S32K142 MCU

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

CAN PAL Usage Issues with the S32K142 MCU

Jump to solution
1,171 Views
ykd
Contributor II

When using the code generated by CAN PAL to receive messages, all information of the first received message is displayed as 0 (the corresponding message is refreshed after exiting the interrupt). The data in the second receive interrupt works normally. Thank you for your help!

CAN_Init(&can_pal2_instance, &can_pal2_Config0);
CAN_InstallEventCallback(&can_pal2_instance, &CAN2_RXTXMsgHandle, (void*)0);

CAN_ConfigRxBuff(&can_pal2_instance, gs_CANRxIDMsgInfo.buffIdx, &gs_CANRxIDMsgInfo.config, 0x02160000);
CAN_SetRxFilter(&can_pal2_instance,CAN_MSG_ID_EXT,0,0x1fffe200);
CAN_Receive(&can_pal2_instance, 0, &gs_RXCANMsg);

void CAN2_RXTXMsgHandle(uint32_t instance,
can_event_t eventType,
uint32_t objIdx,
void *driverState)
{

    switch(eventType)
    {
 
    case CAN_EVENT_RX_COMPLETE:
    //CAN_Receive(&can_pal2_instance, 0, &gs_RXCANMsg);
    id_can_rx[id_count++] = gs_RXCANMsg.id;
        
//When powered on, the breakpoint here shows all zeros for the first time.
//CAN_Receive(&can_pal1_instance, RX_MAILBOX, &gs_RXCANMsg);
#if 1
CAN_Receive(&can_pal2_instance, 0, &gs_RXCANMsg);
CAN_Receive(&can_pal2_instance, 4, &gs_RXCANMsg);
//CAN_Receive(&can_pal1_instance, gs_CANRxPhyIDMsgInfo.buffIdx, &gs_RXCANMsg);
#endif
        break;
 
    case CAN_EVENT_TX_COMPLETE:
        //TP_DoTxMsgSuccesfulCallback();
        break;
 
    default:
        break;
    }
 
 
}
0 Kudos
Reply
1 Solution
1,089 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi,

when moving CAN2_RXTXMsgHandle into main.c makes the problem disappear, the most likely cause is a linkage / multiple-definition issue for your RX buffer or related globals, not the CAN PAL itself.
Be sure all shared RX/TX buffers declared once in a .c file, use extern in headers.
 
BR, Petr

View solution in original post

0 Kudos
Reply
2 Replies
1,102 Views
ykd
Contributor II

At present, the issue is resolved when CAN2_RXTXMsgHandle is placed in the main.c file. Previously, this problem occurred when it was defined in maclcom_can.c (located in the subfolder macl_can under the mcal folder). Why does this happen?

0 Kudos
Reply
1,090 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi,

when moving CAN2_RXTXMsgHandle into main.c makes the problem disappear, the most likely cause is a linkage / multiple-definition issue for your RX buffer or related globals, not the CAN PAL itself.
Be sure all shared RX/TX buffers declared once in a .c file, use extern in headers.
 
BR, Petr
0 Kudos
Reply
%3CLINGO-SUB%20id%3D%22lingo-sub-2288811%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3ECAN%20PAL%20Usage%20Issues%20with%20the%20S32K142%20MCU%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2288811%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EWhen%20using%20the%20code%20generated%20by%20%3CSTRONG%3ECAN%20PAL%3C%2FSTRONG%3E%20to%20receive%20messages%2C%20all%20information%20of%20the%20%3CSTRONG%3Efirst%20received%20message%20is%20displayed%20as%200%3C%2FSTRONG%3E%20(the%20corresponding%20message%20is%20refreshed%20after%20exiting%20the%20interrupt).%20The%20data%20in%20the%20%3CSTRONG%3Esecond%20receive%20interrupt%20works%20normally%3C%2FSTRONG%3E.%20Thank%20you%20for%20your%20help!%3C%2FP%3E%3CP%3ECAN_Init(%26amp%3Bcan_pal2_instance%2C%20%26amp%3Bcan_pal2_Config0)%3B%3CBR%20%2F%3ECAN_InstallEventCallback(%26amp%3Bcan_pal2_instance%2C%20%26amp%3BCAN2_RXTXMsgHandle%2C%20(void*)0)%3B%3C%2FP%3E%3CP%3ECAN_ConfigRxBuff(%26amp%3Bcan_pal2_instance%2C%20gs_CANRxIDMsgInfo.buffIdx%2C%20%26amp%3Bgs_CANRxIDMsgInfo.config%2C%200x02160000)%3B%3CBR%20%2F%3ECAN_SetRxFilter(%26amp%3Bcan_pal2_instance%2CCAN_MSG_ID_EXT%2C0%2C0x1fffe200)%3B%3CBR%20%2F%3ECAN_Receive(%26amp%3Bcan_pal2_instance%2C%200%2C%20%26amp%3Bgs_RXCANMsg)%3B%3C%2FP%3E%3CP%3Evoid%20CAN2_RXTXMsgHandle(uint32_t%20instance%2C%3CBR%20%2F%3Ecan_event_t%20eventType%2C%3CBR%20%2F%3Euint32_t%20objIdx%2C%3CBR%20%2F%3Evoid%20*driverState)%3CBR%20%2F%3E%7B%3C%2FP%3E%3CDIV%3E%26nbsp%3B%20%26nbsp%3B%20switch(eventType)%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%20%26nbsp%3B%20%7B%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3E%26nbsp%3B%20%26nbsp%3B%20case%20CAN_EVENT_RX_COMPLETE%3A%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3E%26nbsp%3B%20%26nbsp%3B%20%2F%2FCAN_Receive(%26amp%3Bcan_pal2_instance%2C%200%2C%20%26amp%3Bgs_RXCANMsg)%3B%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3E%26nbsp%3B%20%26nbsp%3B%20id_can_rx%5Bid_count%2B%2B%5D%20%3D%20gs_RXCANMsg.id%3B%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%26nbsp%3B%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CDIV%3E%2F%2FWhen%20powered%20on%2C%20the%20breakpoint%20here%20shows%20all%20zeros%20for%20the%20first%20time.%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3E%2F%2FCAN_Receive(%26amp%3Bcan_pal1_instance%2C%20RX_MAILBOX%2C%20%26amp%3Bgs_RXCANMsg)%3B%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%23if%201%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3ECAN_Receive(%26amp%3Bcan_pal2_instance%2C%200%2C%20%26amp%3Bgs_RXCANMsg)%3B%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3ECAN_Receive(%26amp%3Bcan_pal2_instance%2C%204%2C%20%26amp%3Bgs_RXCANMsg)%3B%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3E%2F%2FCAN_Receive(%26amp%3Bcan_pal1_instance%2C%20gs_CANRxPhyIDMsgInfo.buffIdx%2C%20%26amp%3Bgs_RXCANMsg)%3B%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%23endif%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20break%3B%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3E%26nbsp%3B%20%26nbsp%3B%20case%20CAN_EVENT_TX_COMPLETE%3A%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%2F%2FTP_DoTxMsgSuccesfulCallback()%3B%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20break%3B%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3E%26nbsp%3B%20%26nbsp%3B%20default%3A%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%3CSPAN%3E%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20%26nbsp%3B%20break%3B%3C%2FSPAN%3E%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%20%26nbsp%3B%20%7D%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%3CDIV%3E%7D%3C%2FDIV%3E%3C%2FDIV%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2289306%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3E%E5%9B%9E%E5%A4%8D%EF%BC%9A%20CAN%20PAL%20Usage%20Issues%20with%20the%20S32K142%20MCU%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2289306%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHi%2C%3C%2FP%3E%0A%3CDIV%3Ewhen%20moving%20CAN2_RXTXMsgHandle%20into%20main.c%20makes%20the%20problem%20disappear%2C%20the%20most%20likely%20cause%20is%20a%20linkage%20%2F%20multiple-definition%20issue%20for%20your%20RX%20buffer%20or%20related%20globals%2C%20not%20the%20CAN%20PAL%20itself.%3CBR%20%2F%3EBe%20sure%20all%20shared%20RX%2FTX%20buffers%20declared%20once%20in%20a%20.c%20file%2C%20use%26nbsp%3Bextern%20in%20headers.%3C%2FDIV%3E%0A%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3EBR%2C%20Petr%3C%2FDIV%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2289082%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3E%E5%9B%9E%E5%A4%8D%EF%BC%9A%20CAN%20PAL%20Usage%20Issues%20with%20the%20S32K142%20MCU%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2289082%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EAt%20present%2C%20the%20issue%20is%20resolved%20when%20CAN2_RXTXMsgHandle%20is%20placed%20in%20the%20main.c%20file.%20Previously%2C%20this%20problem%20occurred%20when%20it%20was%20defined%20in%20maclcom_can.c%20(located%20in%20the%20subfolder%20macl_can%20under%20the%20mcal%20folder).%20Why%20does%20this%20happen%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E