Cannot reset 16 bit CAN timer

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to the AT90CAN64 documentation:

"This timer starts counting from 0x0000 when the CAN controller is enabled (ENFG bit)."

And this timer is used to stamp the CAN frames.

"The capture of the timer value is done in the MOb which receives or sends the frame. All managed
MOb are stamped, the stamping of a received (sent) frame occurs on RxOk (TXOK)."

In my code, after I received a few CAN frames, I disable the CAN interface, then to receive another few CAN frames, I enable it. So, I would expect the timer to be reset. But the time stamps of the frames appear to just increase, and eventually overrun.

Please, see the code attached. The subroutine is sending a single frame OBD command, and stores the response in OBD_BUFFER. It also sends flow control frame in case of multiframe OBD responses, according to ISO15765-2.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I understand it, when you set the CANGCON.ENASTB bit the CAN will perform its CAN bus synchronization and then automatically set the CANGSTA.ENFG bit. Setting the ENFG bit starts the read only CANTIML and CANTIMH counter.

Data Sheet wrote:
19.6.2 16-bit Timer
This timer starts counting from 0x0000 when the CAN controller is enabled (ENFG bit). When the timer rolls over from 0xFFFF to 0x0000, an interrupt is generated (OVRTIM).
The misleading part is the ENFG description enable is assumed to be after the CAN hardware reset, therefore the read only CANTIML and CANTIMH registers have been cleared by the CAN hardware reset.

What I believe you have found is that disabling the CAN by clearing the CANGCON.ENASTB bit, then re-enabling the CAN by setting the CANGCON.ENASTB bit does not clear the read only CANTIML and CANTIMH registers. This requires a hardware reset to the entire AVR or using the CANGCON.SWRES reset.

Data Sheet wrote:
19.10.1 CAN General Control Register - CANGCON
• Bit 1 – ENA/STB: Enable / Standby Mode
Because this bit is a command and is not immediately effective, the ENFG bit in CANGSTA register gives the true state of the chosen mode.
– 0 - standby mode: The on-going transmission (if exists) is normally terminated and the CAN channel is frozen (the CONMOB bits of every MOb do not change). The transmitter constantly provides a recessive level. In this mode, the receiver is not enabled but all the registers and mailbox remain accessible from CPU.
Note:
A standby mode applied during a reception may corrupt the on-going reception or set the controller in a wrong state. The controller will restart correctly from this state if a software reset (SWRES) is applied. If no reset is considered, a possible solution is to wait for a lake of a receiver busy (RXBSY) before to enter in stand-by mode. The best solution is first to apply an abort request command (ABRQ) and then wait for the lake of the receiver busy (RXBSY) before to enter in stand-by mode. In any cases, this standby mode behavior has no effect on the CAN bus integrity.
– 1 - enable mode: The CAN channel enters in enable mode once 11 recessive bits has been read.
Normally terminated means the ongoing CAN transmission is allowed to complete first, before the CAN accepts the ENASTB disable.

I do not see any code that deals with the Note above.

Keep in mind since the CAN hardware is a state machine, if the CAN MOb is busy with CAN bus traffic when you send a disable command (setting CANCDMOB command bits = 0) the CAN hardware will temporarily ignore the disable command until the CAN hardware is finished using the CAN bus for that MOb. This is called ongoing communication. If you are depending on the CANCDMOB disable write to take care of the above Note, there could possibly be cases where this will fail. This could create an unpredictable response type of bug. You are trying to predict the behavior of a hardware state machine, where depending on your prediction is not really needed in the first place.

Unless you use the ABORT and monitor RXBSY as described, or you had better use the SWRES and software reinitialize the entire CAN before setting ENASTB for the re-enable.

I do not see any advantage to disabling your CAN unless you are going to sleep the AVR or manually sleep the external CAN interface chip (some CAN interface chips automatically sleep and wake up). If you are going to sleep, then there is a different sequence for controlling the CAN hardware.

There are several methods to extend the resolution of the CAN time stamp. A beginning is to look at the minimum time stamp resolution. Your CANTCON divider may be set such that each timer tick will always be shorter than the quickest RXOK/TXOK response. You may also set your timer tick interval to match a human friendly fraction of a second value. Then the CANGIT.OVRTIM may use software to extend the resolution to the desired number of bits. It is possible to create software extended time stamp values that take over 100 years to overflow and repeat another non-unique value.