Hi everybody,

I am currently working on a testcase for a CAN microcontroller. The microcontroller is connected to a CAN analyzer (Vector Canalyzer pro).
Microcontroller: TC1766.

There are only two node (NODE0, NODE1) on the microcontroller and I want to send frames and see if they are displayed on the analyzer. All the frames sent by NODE0 are successfully transmitted and can be seen on the analyzer. The test is OK at this point.
Unfortunately when it comes to NODE1, the first frames is never sent, i get this error:

- Bit0 Error: During transmission, node tried to send a dominant level, but monitored value was recessive.

Nothing appears on the oscilloscope ( but i could see the frames for NODE0). I checked all the registers involved and i didn t see any issue (no obvious issue at least)

Have you already got this error ? Do you know what it can means precisely ?
If you Could you help me or at least give me a hint on where to look at, that would be great . I ve been looking for this problem for two weeks now, i m out of solutions...

Thanks

 

I haven't used CanAlyzer in some time but if I were to guess, its telling you that it detected the beginning of a dominant bus condition but during the bit cell time, it sampled a recessive. If that's the case, first be sure that NODE1 is wired correctly, that it can successfully emit dominant and recessive with solid logic levels (wiggle the port pins directly with a piece of test code). Make sure that your bus drivers are keeping up with the bit rate with fast, solid switching.
If the hardware is working, I would check the bit timing assignments on all nodes to ensure that everybody is on the same page. Maybe NODE1's dominant time is shorter than it should be and its back to recessive when the CA samples it.
If the propagation time setting is too short, or if there is excessive delay between the time that the node asserts dominant and the time it gets feedback, it can decide that something is not right on the bus and get off. Same if the sample time is not in the right place.

Double check the oscillator freq of NODE1 as well - that would throw things off.
I am not familiar with the TC1766 but it probably has error registers that might throw some light on things. Send a simple packet and read the regs.

Finally, see if the error is better described in the help files or shoot an email to Vector - they can tell you what specifically triggers it.

I don't currently have my CanAlyzer on a PC or I could poke around a bit for you. Sorry.

Good luck!

 

That is a quick and precise answer !

I will try these and tell you if it is finally working.
Thanks

 

Thank you JohnInTx. I used an other little piece of code and I found the problem. It comes from the Port configuration (as suspected):
When one NODE is transmitting on a port, the other NODE´s Tx configuration has to be "Open Drain" for the transmission to succeed.
So when the first NODE finished to transmit, its Tx configuration is switched to "Open Drain", and the next node is switched to "Push-Pull".

If I understand CAN well, it is a bit weird: We should be able to communicate with each node without having to change its Port configuration ?
Worst thing is that now i have a problem I can t solve:

I want to receive the frame from NODE0 to NODE1. But when I send a frame from NODE0, the NODE1 has to be on "Open Drain" for NODE0 to transmitt. BUT NODE1 can t receive the frame with "Open Drain" configuration...

I might misunderstand something about the CAN. Could you help me with theese port configurations for Tx and Rx ? I have to say i m not familiar with it !

 

All of the Microchip CAN stuff I have used requires an external bus transceiver (like the MCP2551) to drive the physical bus. A quick glance at the TC1766 datasheet implies that an external transceiver is necessary as well (from pp 41)

The bit timings for the CAN nodes are derived from the module timer clock (fCAN), and
are programmable up to a data rate of 1 Mbit/s. External bus transceivers are connected
to a CAN node via a pair of receive and transmit pins.

That's probably why you are having to bit-diddle the port directions to make it work. A CAN transceiver does all of that for you and uCs that expect a transceiver won't do the direction switching as part of normal CAN operation.

I think each TC1766 node needs one.
Good luck.

PS sorry for the late reply, was not where I could check this out for you.