S32K144 BUSOFF,The first time it enter busoff, then I close the busoff interrupt, but the can controller try to send message again after the interrupt happened about 5.6ms

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

S32K144 BUSOFF,The first time it enter busoff, then I close the busoff interrupt, but the can controller try to send message again after the interrupt happened about 5.6ms

1,493 次查看
hongjianzhang
Contributor III

1. The question is: When my s32k144 to run into busoff,  I closed the busoff interrupt, but after this about 5.6ms, the s32k144 try to send message again. and this happened only once.

the baut rat of the bus is 250k, that is bit time is 4us

5.6ms is about 128 * 11 bit *4us  time, I thought after the controller went into busoff  the controller detected 128 occurrences of 11 consecutive recessive bits on the CAN bus, and the went into "Bus Active mode", But my question is why the controller send message again? Does this meet the busoff recover standard.  and if not Can I close this feature?

2. How to know the busoff has really recovered?

ps: our requirement document require that we should recover can bus system according to follow items:

when busoff happened, we should recover the bus every 100ms, if after repeat 10 times, the bus don't recover, the controller should recover the busoff every 1s forever;

And My plan is: when the controller busoff interrupt happened, I close the interrupt mask, and start a timer of 100ms, when the timer elapsed,I open BOFFREC mask bit to recover the system and enable the busoff  interrupt mask again to prevent the chip busoff again,If the bus recover normally I will close the BOFFREC bit to forbit the auto recover. And if the busoff interrupt happen again, I will close interrupt an then start the 100ms counter again. Does the control flow right?

标记 (3)
0 项奖励
1 回复

1,256 次查看
PetrS
NXP TechSupport
NXP TechSupport

Hi,

1. yes, this is correct behavior as per standard, automatic bus off recovery that happens after 128 occurrences of 11 recessive bits was detected. Moreover the message is resent again as it is still waiting in the SMB. You can use Abort to stop message transmitting.

2. You can check the SYNC bit to know module is active and synced to bus. There is also BOFFDONEINT bit indicating 128 occurrences of 11 recessive bits was detected and module is ready to leave bus off.

I do not understand wording well but if using manual bus off recovery you can control the time when the module is going to sync to bus, so probably it can work for you.

BR, Petr 

0 项奖励