S32K3 - FlexCAN_Ip_Send periodic function call

[ziomocci]

Hi all,

 When I use FlexCAN_Ip_Send API form RTD 2.0.0 "one shot", there is not any problem.

Anyway, it seems there are problems with periodic function calls.

I have installed a very simple PIT isr each 1msec and I call the FlexCAN_Ip_Send each 10 millisecond; the FlexCAN correctly sends only the first message, then it returns always FLEXCAN_MB_TX_BUSY.

Where is the problem? How could I send periodic CAN messages?

Thank you in advance,

B.R.

Andrea

[PetrS]

Hi,

how did you set tx_info.is_polling used in FlexCAN_Ip_Send? 
With tx_info.is_polling set and non blocking Send function you should call FlexCAN_Ip_MainFunctionWrite which checks MB flag and update internal driver variables so FlexCAN_Ip_GetTransferStatus can be used. For example like
while(FlexCAN_Ip_GetTransferStatus(INST_FLEXCAN_0, TX_MB_IDX) != FLEXCAN_STATUS_SUCCESS)
{ FlexCAN_Ip_MainFunctionWrite(INST_FLEXCAN_0, TX_MB_IDX); }

With tx_info.is_polling cleared, driver calls MB interrupt and internal driver variable will be updated. Then FlexCAN_Ip_GetTransferStatus can be used to know status of previous transfer.

BR, Petr

[ziomocci]

Hi @PetrS 

Thanks for the very fast reply.

I have applied following changes

        /* Get Message Buffer field values associated to nbuf input parameter */
        FlexCAN_GetMsgBuff(base,nbuf,&msgBuff);

        tx_info.data_length = msgBuff.dataLen;
        tx_info.msg_id_type = (Flexcan_Ip_MsgBuffIdType)((msgBuff.cs & (uint32_T)FLEXCAN_IP_CS_IDE_MASK)>>FLEXCAN_IP_CS_IDE_SHIFT);
        tx_info.is_polling = FALSE;
        tx_info.is_remote = FALSE;

        res = (int16_T)FlexCAN_Ip_SendBlocking(Channel,nbuf,&tx_info,msgBuff.msgId,pData,CAN_TIMEOUT_SEND_BLOCKING);

and, with a CAN_TIMEOUT_SEND_BLOCKING set to 5 msec I am able to send each 5/10/100 millisecond, as required by our application.

Is it correct my implementation or should be better to use the main interface write?

Thanks,

Andrea

[PetrS]

Hi,

if I understand driver properly for blocking function, tx_info.is_polling is don't care, I think. MB's interrupt is not enabled at all. Function returns after successful transmit or timeout and updates internal status variable accordingly.

Thus, if you do not mind a function is blocked until one of above happens then you can use it this way. 
For non-blocking function with with tx_info.is_polling cleared, it is enough to use FlexCAN_Ip_GetTransferStatus to know status of previous transfer. Or callback can be installed and use events inside to know when receive, transmit, etc was done. 

BR, Petr

[ziomocci]

Hi,

We have to measure the duration of the FlexCan_Ip_SendBlocking.

That is the configuration:

5 CAN messagges in reception, IRQ-driven (that is, polling disabled), sent with external tool (Vector CANoe IG) each 1/5/10/20/100 msec,

3 CAN messagges in transmission each 5/10/100 msec,

CAN Rx/Tx "scheduled" with 1 PIT counter (timeout 1msec, OS not installed)

When FlexCan_Ip_SendBlocking timeout is set to 1 msec, it returns FLEXCAN_TIMEOUT_ERROR (0x03) very often; with 2msec timeout performances increases, with 5msec timeout they are acceptable.

I will keep you informed.

B.R.

Andrea 

[PetrS]

Hi,

yes, it can happen, I think.
Assume length of the longest message on the bus, not sure what is sent from your CANoe.
For example for 500kbps, ext.ID and 8byte payload a single message is min 260us.
Then depending bus load and bus arbitration, your prepared message could not be sent within 1ms.

BR, Petr

[ziomocci]

Hi Petr,

Your proposal of the while loop

"while(FlexCAN_Ip_GetTransferStatus(INST_FLEXCAN_0, TX_MB_IDX) != FLEXCAN_STATUS_SUCCESS)
{ FlexCAN_Ip_MainFunctionWrite(INST_FLEXCAN_0, TX_MB_IDX); }"

with the not-blocking Send API is not applicable since the system remains inside the "while" until the CAN bus is off, and start running only with the CAN bus on (by CANoe or busmuster is the same).

For the moment we use the blocking Send API with 2msec of timeout.

We have to analyze the CAN load with the system fully operative (DSPI, LIN, EMIOS, Main control, etc etc).

Regards,

Andrea