Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
nsyed
Level 5
Level 5
5 likes given 100 sign-ins 50 sign-ins

Hello I am using TC377TP on my control board and I have configured Tx Interrupts.

 

I am observing that one of the Extended CAN message  on CAN0 Node 2 drops communication and does not recover when CAN bus load is > 50%. Rest of other CAN messages are ok on this same node, and other messages which have low priority when compared to failed messages communicate normally

 

Any thoughts on what might be going on ? Is there any errata which I am missing ?

 

This problem does not occur when I use the polling method, instead of interrupts

0 Likes
10 Replies
Di_W
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 100 likes received

Hi User19903,

What you found is "drops communication and does not recover", for debugging it's better to start 1 tx transaction first, and then 1 frame/second, and then increase the speed.

PPT and Application Note is for your reference.

https://www-blue.infineon.com/dgdl/Infineon-AURIX_MCMCAN_1_KIT_TC334_LK-Training-v01_00-EN.pdf?fileI...

AP32363_MCMCAN_GettingStarted_v2.2.pdf  (which is from myICP)

 

dw

0 Likes
nsyed
Level 5
Level 5
5 likes given 100 sign-ins 50 sign-ins

Hello DW, 

I already passed that stage and I don't have any problem with transmitting 1 frame/second. 

I am at a much advanced stage of debugging. Please note that this issue does not happen all the time and only in some specific conditions and right now I am not sure what to look for. 

 

Any thoughts ?

 

0 Likes
nsyed
Level 5
Level 5
5 likes given 100 sign-ins 50 sign-ins

And , I am using Infineon's MCAL and not iLLD

0 Likes
Di_W
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 100 likes received

Hi User19903,

Is it reproduced under MCAL demo as below? To check any error on the bus please refer to  related register ISREGi ECRi PSRi IRi TXFQSi TXBTOi TXBCFi TXBTIEi TXEFSi TXEFAi 

dw_0-1646185360278.png

dw

0 Likes
nsyed
Level 5
Level 5
5 likes given 100 sign-ins 50 sign-ins

Hello,

I am observing the buffer status is always reported as busy from MCAL due to which the message is getting blocked

Any thoughts ?

I am using below version of MCAL . Is there any errata or fix for this issue ?


** FILENAME : Can_17_McmCan.c **
** VERSION : 1.40.0_38.0.0 **
** DATE : 2020-04-16 **

 

User19903_0-1646254597380.png

 

0 Likes
lock attach
Attachments are accessible only for community members.
nsyed
Level 5
Level 5
5 likes given 100 sign-ins 50 sign-ins

Also attached is my register configuration during this busy status. 

 

Any MCAL experts who can help on this topic ?

0 Likes
Di_W
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 100 likes received

Hi nsyed, 

Early you said CAN0 Node 2 lost bus, however I found the reg_status.zip is only for CAN0 Node 0, and I checked CAN0_PSR0  LEC Last Error Code = No Error  ACT= Idle BO= Not Bus Off  DLEC= No error EP=Error_Active 

Could you please verify CAN 0 NODE 0 is Bus Busy?

 

0 Likes
nsyed
Level 5
Level 5
5 likes given 100 sign-ins 50 sign-ins

Hello dw, 

Sorry for the confusion. Initially I thought this issue is only on CAN 0 Node2, but today after further testing I can reproduce it on all nodes. 

Yes the CAN 0 NODE 0 is showing as Bus Busy. 

I am doing further deep dive and troubleshooting on this issue and observed that since I am using MCAL interrupts, a missing interrupt can cause this type of problem. 

This MCAL buffer status is locked when the message is copied to the Tx Buffer and unlocked after the Tx is successful (Interrupt service routine).

If the Tx Interrupt is not raised for some reason, then we potentially end up where the buffer status shows always as “BUSY”.

I am not sure at this point why I would miss an interrupt. Any thoughts ?

0 Likes
nsyed
Level 5
Level 5
5 likes given 100 sign-ins 50 sign-ins

Dear Community members,

Any thoughts or suggestions on this topic ?

0 Likes
Di_W
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 100 likes received

Hi,

I checked CAN0_IR0 , EW PEA EP TC interrupt flag is set,  and CAN0_IE0 TEFNE DRXE is enabled.

As IE0 is not enabled for EW PEA EP TC, it's not known when the interrupt happen.

So, if you can capture all the error before BUS_BUSY, then we can know how to handle.

It's an idea to log all the IR0 in normal status, and log the BUS_BUSY IR0 flags for comparison.

 

0 Likes