Clear CANTXERR HCS12X

[IanM]

I capture the can error ISR and abort any pending transmissions, the issue is that I do not allow a new Tx if the CANRFLG >= 0x08, Is it possible to reset the CANTXERR counter to zero.  Currently the only way that I can do this is force a hard reset of the micro (HCS12X)

Thanks in advance

[kef]

CANRFLG >= 0x08 doesn't seem right. Could you explain what conditions you expect this expression return true?

You mention CAN error interrupt. But being more precise, there's no CAN error interrupt, but CAN status change interrupt, which is triggered both, when entering bad state and when leaving it. Also (just in case you didn't know) please note that RSTAT* and TSTAT* bits don't change while CSCIF flag is set. So tracking RSTAT* and/or TSTAT* bits you should always service CSCIF flag.

[IanM]

Kef thanks for the reply, I will try to explain in more detail.

Our customer as part of his acceptance test has dedcided to Tx on a none terminated bus.  This cause TX errors as expected and we capture the CSCIF interrupt and call the abort transmission.  We see the TSTAT to register a value of 0x08 indicating the Tx error condition.  When we then request a new CAN Tx we do not get a CSIF state change interrupt generated i.e. a move to bus off or leaving the TXErr state.  How do I recover from the TXERR state, once a transmission has failed, I have tried re-init the MSCAN but as indicated in the spec the TSTAT does not reset.  The only way I can get the TSTAT back to 0 is to perform a power cycle.

So what I have done in the code is to check the TSTAT before carying out a new Tx and if this is set at 0x80 do not allow a new Tx to be carried out.  I did this because the next Tx request after the Tx that caused the TxErr was not causing a state change and so no ISR was generated.

Hope this explains a little better.

[kef]

I see now. Your approach to inhibit transfers while transmitter is in warning or error state is not good. Transmit error counter and TSTAT* bits change only transfering something and it is not possible to manipulate TEC and TSTAT* bits.

I think, since your MCU should initiate transfer, you should probe the bus periodically. In case there are no other CAN nodes on the bus, periodical probing would be better (at least less noisy and less power hungry) than doing fast loop like this: unsuccessfull transfer - aborting Tx buffers - TEC reset - unsuccessful transfer etc.

[RubenCG]

Hi Kef and lanM,

I know this is an old question but I can't solve totally the problem with my CAN module, when I have a bus-off and I want to abort all the tx's... I only have to CAN0TARQ=0x07;

Is it all? Is it enough? I have to do any more action? Do you know any application note with CAN-error handler examples?

Thanks for your help, 

[kef]

RubenCG,

I don't know what is your problem. Is you controller unable to recover from busoff?

Are you using automatic busoff recovery or manual? Automatic busoff recovery doesn't require any action. Manual recovery is done clearing BOHOLD bit.

CAN error status change interrupt in both cases is optional. You can service CSCIF flag from foreground task or from CSCIF interrupt.

Everything else, aborting scheduled Tx messages, emptying Tx queue etc is up to you and your application requirements.

[RubenCG]

Hi Kef,

I'm using automatic busoff recovery but i want to abort the scheduled tx when busoff arrives. Setting "CAN0TARQ=0x07;" is enough? i want to know what is the standard process when busoff arrives: abort and stop tx? only abort? only stop tx? I can't find any code example.

Thanks for your attention.

[kef]

Yes, CAN0TARQ=0x07 is enough to abort scheduled messages. Of course it won't clear software Tx FIFO message queue your application may have.

I think behaviour on busoff is application specific. I ask myself what will happen if busoff takes a minute, an hour, more and then recovers? Of course all scheduled messages will be transferred. Can this be harmful? It depends:

1) slave scheduled answer to some query like "what is measured voltage" . Probably it won't break anything if master will get query answered even after long delay. Wrong or not depends on how fast queried parameter may change, is scheduled answer still correct or not.

2) master scheduled command like "make that big saw running". It has to be aborted, isn't it?

3) some big file transfer from slave was in progress and for some reasons slave can't resend any part of file. It may be better to not about such message.

... 

Robust high level protocol may fight above examples without requirement to abort any messages. Also application may have extra security measures. For example slave saw cantroller may require periodic confirmation from master that it is still OK to keep saw running.

[RubenCG]

I understand what you mean and I hope my decision will be right, at least enough for my boss .

The high level application is secure enough (I presume...), I only want to make the communications faster and efficient. The problem for me is what you said, busoff last 1 ns, 1ms... or 1 hour? During this Busoff-time do you think the Tx interrupt should be set? If you only abort Tx and not stop Tx interrupt you enter Tx ISR... ok! I'm in busoff....ok!Abort Tx!...and so on.

Thank you Kef, talking about the problem is easier to solve it. 

[kef]

Of course Tx interrupts should be disabled. But shouldn't every Tx ISR implementation disable specific TXEIEn interrupt when there's nothing to send? I think it should. If so, then Tx interrupts will get disabled naturally after you clear Tx queue.

[RubenCG]

Ok!! I completely agree with you, I think the question is clear. Let's test it! Crossing fingers!

Thanks again for your wise recommendations.