FlexCAN in MAC7111 transmits continuously

[kwiatuszek]

Hi all,

I am implementing CAN bus on the MAC7111. My problem is, that the controler sends now can frames continuously - sending one frame causes bus load over 90%, because the same data are sent all the time...

The funny thing is, that yet 2 weeks ago the software worked fine. Now with exactly the same software, it does not work... No hardware change was made.

Help!

[TomE]

CAN transmitters will send continuously if the packet isn't being acknowleged by something else on the bus.

So the first thing to check would be that there is at least one other CAN device that can answer the message. The second thing to check would be that the transmitted packets might be in error. Possibly the baud-rate is wrong due to a clocking change somewhere?

Tom

[kwiatuszek]

Hi, thank you! You are right, I normally receive all data using USB CAN adapter from National Instruments. But I tried also another receiver and there was abosolutely no problem. Then I checked if current NI settings are ok, changed them to correct ones. But somehow this NI-CAN adapter won't work without errors now - no idea what happend. I cannot succesfully adjust all those Time Quotas etc.

[TomE]

Time Quanta (no, not our airline :smileyhappy:, not Quotas.

Download a bunch of different Data Sheets and App Notes from different CAN chip manufacturers and read through their chapters on how to set this up. After the third or fourth it'll start making more sense. Try Microchip's AN754.

The tricky part about setting the CAN time segments is that the proper selection of the parameters should be done by someone who knows everything about your CAN network. The length of the cable, the speed, the delays and everything should be considered in order to get an optimal set of numbers. It even depends on the maximum clock variation between all of the devices on the network. If eveything is using crystals this doesn't matter, but if some cheap devices are using resonators with a large error margin, then some of the parameters may have to be set "just so". You can either have a long bus with accurate oscillators or a short bus with inaccurate ones.

But unless you're pushing it (speed, length and clock variation) then almost anything will work most of the time.

If you're building something to go into an existing system then you should match whatever the system designer requires. For instance if you're making something to connect to a GM Vehicle you have to match GM's specifications.

Take your bit rate (33k, 500k) and multiply it by 16 or 20. Set the clock divider to generate that. Either will do, but some may be easier/possible to achieve with whatever master clock your CAN controller is running. This has to be exact - "within a few percent" isn't good enough here.

Divide those 16 quanta into Sync, Prop, PS1 and PS2. Sync is fixed at "1" and the others have a maximum value of "8". There's also the "SJW" which has a maximum value of the PS2 value. The first easy mistake is getting this sum wrong.

The specifications we're required to meet are Prop=8, PS1=4, PS2=3, SJW=3 for 500kHz and Prop=8, PS1=5, PS2=2, SJW=2 for 33kHz. The most important thing is that "1 + Prop + PS1 + PS2 = 16" (or 20 or whatever your divider is).

Watch out as most if not all registers used to program these things have "1" added to them, so "8:4:3:3" is programmed into the registers as "7:3:2:2".

Tom