• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 889 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CAN ACK pulse discrepancy with SN65HVD232

Jacques
Prodigy 90 points
Other Parts Discussed in Thread: SN65HVD232

Hi
Ok. Details. I have a working 5v project running 40MHz, 250kbit/s. I am now making an upgraded 3v3 64MHz 250kbit/s version and it is not working correctly as it generates packet read errors, and the ACK it generates often looks like it is either holding for too long or doing something odd. I have adjusted the Baud rate to match.
I have a CAN packet generator using an MCP2551 to spew out an automated loop of data. Using my existing project with a PIC18F4585 and an MCP2551 (both 5V devices), they talk just fine.

Using my new project with a PIC18F66K80 and a TI SN65HVD232 (same firmware, but running 3v3), I find the CAN packet generator keeps spewing the same packet out as it never receives the ACK back from me. Their grounds are both common and connected. Investigating the CAN signal, I see that with the micro powered down, the CAN bus signal is correct and just waiting for a response. With the micro powered up, I see the CAN bus signal showing the correct offset differential of the 3v3 SN65HVD232 as it tries to ACK, however sometimes there is another signal on top which looks squif.

When I look at the TX coming from the Micro into the CAN controller, i.e. on pin1, "D", I see that there is almost a double bounce on the ack. It drives low for 1x Tbit (4us), releases for 1xTbit, and then drives low again for 6xTbit. During that second time low, the CAN_H/L side of the controller shows a very weird offset voltage shift. In my inexperience with CAN, it looks like 2 devices are trying to drive a zero and between the 5V and the 3v3, it's producing a different voltage level to when the 5V or the 3v3 are driving the line independently.

The more I look at this, the more I think it is likely to be a function of the Microcontroller and not the CAN controller, in which case this should be on the Microchip forums. However, I've already typed it up so the more advise the merrier.

I can't seem to post multiple pictures so will have to reply each time with a picture to show what I mean.

This picture attached shows CH2 (blue) on top as the TX from the Micro into the CAN Controller (Pin1 "D") and CH1 (yellow) on the bottom out the CAN Controller (Pin6 "CANL"). The cursor shows CH2 (blue) driving low for 4us, releasing for 4us, then driving again for 24us. What is it doing but more importantly, why does the CAN line (CH1 (yellow)) go to an intermediate voltage? Is it also trying to drive?

Any ideas would be very welcome.

  • 0
    Prodigy 90 points

    Ok. So I have done some more research and discovered that the ACK bit is just a bit. So at my data-rate, it should only be 4us, which it visibly is. Then after the recessive ACK delimitter, another bit later, the CAN master starts writing the end of frame section (7bits = 28us). During that time period however, my Micro is trying to talk for 6 bits. 

    Why then is my Micro trying to write a dominant bit during that end of frame, for 24us = 6bits?

  • 0 in reply to Jacques
    Prodigy 90 points

    Problem solved finally.

    The 6 bits are the error frame being set because after the ACK bit, there is meant to be ACK delimeter which is recessive. But the rise time of the ACK is too slow and so it is still below the threshold of the low / dominant level, seeing it as another "0 bit". The ACK error is set and the error frame is asserted.

    This explains why I get valid data, but why the error is still set and the message never moves on.

    Solved it by putting a 10k pullup on pin#1 "D", input to the SN65HVD232. 

  • 0 in reply to Jacques
    TI__Mastermind 21811 points

    Hi Jacques,

    Thanks for posting your solution! Sorry we were not able to get a response to you quicker, our team was out of the office on holiday.

    The ACK / ACK Delimiter bit is a very common error that can be cause by high capacitance on the bus, or like you found if the processor has a weak pull-up on the D-pin, this can also cause problems as faster speeds.

    Please let us know if you have any other questions.

    Thanks,

    John