AnsweredAssumed Answered

explanation of simple blocking FSL_FLEXCAN api:

Question asked by CRAIG CAMPBELL on Jan 4, 2016
Latest reply on Jan 14, 2016 by CRAIG CAMPBELL

The SDK 1.2 FSL_FlexCAN is confusing me for simple blocking send/receive calls.

I have a simple model where I send a command and wait for a response.

Send works fine:

 

while(FLEXCAN_DRV_GetTransmitStatus(FSL_CANCOM1) == kStatus_FLEXCAN_TxBusy);

FLEXCAN_DRV_ConfigTxMb(FSL_CANCOM1, TX_mailbox_num, &data_info, destination_id);

result = FLEXCAN_DRV_SendBlocking(FSL_CANCOM1, TX_mailbox_num, &data_info, destination_id, (uint8_t*) message->data, CAN_TX_TIMEOUT);

 

I would think receive would be similar:

 

FLEXCAN_DRV_ConfigRxMb(FSL_CANCOM1, RX_mailbox_num, &rx_info, MAIN_MODULE_ID);

flexcan_status_t status = FLEXCAN_DRV_RxMessageBufferBlocking(FSL_CANCOM1, RX_mailbox_num, &rx_buf, CAN_RX_TIMEOUT);

 

The problem is that the RxMessageBufferBlocking call does not block waiting on the received packet. The comment indicates that it blocks after a receive interrupt. I don't get what the proper sequence here is for a simple send/receive.

 

FWIW, when the above code is run odd things happen, the most disturbing thing is invalid faults to random un-handled processor exceptions, usually in FLEXCAN_DRV_IRQHandler at the last line, FLEXCAN_HAL_ClearErrIntStatusFlag(base);

This seems to be a hardware issue with the K64 as far as I can tell, as a random fault like this should never occur. I have seen others have had similar problems, but the resolution of them was not documented.

 

I have looked at the simple flexcan demo code, but it does not do blocking.

 

Best Regards...

Outcomes