Forum Rule: Always post complete source code & details to reproduce any issue!

# Thread: Another fork of FlexCAN

1. Well Ive changed my approach slightly. I enlisted the help of my Arduino UNO. I Know the UNO can send and receive CAN because ive connected it to my cars OBD2 port and successfully pulled data.

I set up the Arduino to send ONE message into the bus. Its only coded to write ONE time.

The issue i am getting, is the Teensy 3.6, will read the same message infinitely every time CANbus0.read(rxmsg) is run.

It continues to read the same single message even if the CanH and CanL lines are disconnected from the teensy.

My only conclusion is that it seems the message received by the Teensy, is being stored in a buffer, and not being cleared. So every time read() is run, it continues to pick up the same message.

Is there a function that clears the buffer that i am not aware of? OR Should the read() function clear the buffer on its own?

2. Originally Posted by TurboStreetCar
Well Ive changed my approach slightly. I enlisted the help of my Arduino UNO. I Know the UNO can send and receive CAN because ive connected it to my cars OBD2 port and successfully pulled data.

I set up the Arduino to send ONE message into the bus. Its only coded to write ONE time.

The issue i am getting, is the Teensy 3.6, will read the same message infinitely every time CANbus0.read(rxmsg) is run.

It continues to read the same single message even if the CanH and CanL lines are disconnected from the teensy.

My only conclusion is that it seems the message received by the Teensy, is being stored in a buffer, and not being cleared. So every time read() is run, it continues to pick up the same message.

Is there a function that clears the buffer that i am not aware of? OR Should the read() function clear the buffer on its own?
The read function is supposed to clear the buffer. If it had stopped when you pulled CANH and/or CANL then I would have guessed that you were in listen only mode somehow. On a CAN bus a frame gets sent and some other node on the bus is supposed to set an ACK bit if they successfully received the message. This tells the sender that everything worked and it assumes that all is OK. If the ACK bit is not set by anyone then the sender could be configured to retry. If you are in listen only mode then you won't set ACK and if no one else does you can get an infinite loop where the sender tries forever to send and nobody ACK's so it never stops. But, this should quit as soon as you pull the H/L lines as no more traffic is happening.

So, if it keeps happening when the bus is disconnected then it seems it'd be a local problem not a bus problem. I don't remember anyone else having trouble with the pawelsky library in this way. You could try my version but you'll need to look at the examples to see how to initialize things - it's a little different.

3. Well i believe the tranceiver boards i sourced put the chip into "slope control mode" with a pull down resistor on the RS pin.

Is there anything in the code that specifies listening mode?

It seems im having issues on both ends of the canbus.

On the Arduino side with sparkfun shield, there are three transmit buffers built into the MCP chip. I can send three messages before i dont receive any new messages from the arduino. SO on the arduino side it seems that the messages are loaded into the transmit buffer, and are never cleared.

Then on the Teensy3.6 side, every time the read function is run, it reads the same message from the receive buffer, seemingly never clearing it from the buffer.

The lack of an ACK....SEEMS..... to make sense as it would cause a infinite loop of sending from the arduino seeking an ACK, and likely causing the messages to not be cleared from the transmit buffer because they dont know they have been sucessfully sent.

Though on the Teensy side, the ACK doesnt make complete sense because even with the CanH and CanL lines disconnected it still reads the same message from the buffer.

Is there anything i can do in the code to force a SINGLE transmission from the arduino? Would also like a piece of code to either force clear the recieve buffers, OR send an ACK.

Is that possible?

4. [QUOTE=TurboStreetCar;127935]Well i believe the tranceiver boards i sourced put the chip into "slope control mode" with a pull down resistor on the RS pin.

Is there anything in the code that specifies listening mode? [quote]

The pawelsky library has no means of setting listen only mode so I don't see any reason it should be on. There is a way to set it on the chip but the library doesn't do it. So, it would be very bazaar if it were set.

It seems im having issues on both ends of the canbus.

On the Arduino side with sparkfun shield, there are three transmit buffers built into the MCP chip. I can send three messages before i dont receive any new messages from the arduino. SO on the arduino side it seems that the messages are loaded into the transmit buffer, and are never cleared.
That's consistent with a bus where frames are not being acknowledged. Quite quickly any sending node is going to run out of buffers.

Then on the Teensy3.6 side, every time the read function is run, it reads the same message from the receive buffer, seemingly never clearing it from the buffer.

The lack of an ACK....SEEMS..... to make sense as it would cause a infinite loop of sending from the arduino seeking an ACK, and likely causing the messages to not be cleared from the transmit buffer because they dont know they have been sucessfully sent.

Though on the Teensy side, the ACK doesnt make complete sense because even with the CanH and CanL lines disconnected it still reads the same message from the buffer.

Is there anything i can do in the code to force a SINGLE transmission from the arduino? Would also like a piece of code to either force clear the recieve buffers, OR send an ACK.

Is that possible?
There is almost always a way to set the hardware to attempt a frame transmission only once. There is also generally a means to cancel a transmission upon request. As in, you could let it try and if it doesn't happen in X milliseconds then you abort it. But, I have no idea whether the library you are using on the Arduino supports that or not. On the Teensy side, the pawelsky library does set a bit to indicate it has received the message. This should clear things out. It also isn't in listen only mode so it should be setting ACK on frames. Thus, I'm at a loss as to why it would be doing what it is doing. You can still try my library as initialization is done a little differently and reception is almost completely different. If there is some quirk in the library you're using then maybe it isn't in mine.... though it still could be. It might be worth a try anyway.

5. the library here that works on teensy 3.5 didnt work for me, but the one included in teensyduino did even tho the sketch had labeled 3.1 in the top *shrug* anyways i wasnt using it for sending, just reading to a mega2560 with a sparkfun canbus shield attached which was doing the sending, but, even without a transceiver, they seem to make good slaves of a canbus network

6. This thread started with CollinK saying he created a new FlexCAN library. I had some beginners issues understanding how to use it. But, I got past that.

Then TurboStreetCar had a code that did not seem to work with FlexCAN. Today I took TrboStreetCar's code and made the modifications required to work with CollinK's version of FlexCAN. It works just fine for me. The modified code is attached.

The transceiver modules I used look the same as the ones TruboStreetCar showed in his post. Mine use a Ti VP230 chip.

I think that I can recommend using CollinK's library.

The pawelsky library has no means of setting listen only mode so I don't see any reason it should be on. There is a way to set it on the chip but the library doesn't do it. So, it would be very bazaar if it were set.

That's consistent with a bus where frames are not being acknowledged. Quite quickly any sending node is going to run out of buffers.

There is almost always a way to set the hardware to attempt a frame transmission only once. There is also generally a means to cancel a transmission upon request. As in, you could let it try and if it doesn't happen in X milliseconds then you abort it. But, I have no idea whether the library you are using on the Arduino supports that or not. On the Teensy side, the pawelsky library does set a bit to indicate it has received the message. This should clear things out. It also isn't in listen only mode so it should be setting ACK on frames. Thus, I'm at a loss as to why it would be doing what it is doing. You can still try my library as initialization is done a little differently and reception is almost completely different. If there is some quirk in the library you're using then maybe it isn't in mine.... though it still could be. It might be worth a try anyway.
Yea i dont know whats going on, im leaning towards a hardware issue with the transceiver boards i got. Possibly faulty chips or something. It would explain why the working Arduino/Sparkfun Shield combo doesnt work properly with the Teensy/Ebay Boards. What CAN Transceivers do you use? Or is there a known reliable source that is commonly used be people here?

Originally Posted by FredA
This thread started with CollinK saying he created a new FlexCAN library. I had some beginners issues understanding how to use it. But, I got past that.

Then TurboStreetCar had a code that did not seem to work with FlexCAN. Today I took TrboStreetCar's code and made the modifications required to work with CollinK's version of FlexCAN. It works just fine for me. The modified code is attached.

The transceiver modules I used look the same as the ones TruboStreetCar showed in his post. Mine use a Ti VP230 chip.

I think that I can recommend using CollinK's library.
Much appreciated the sample code! I just tried it and no luck. I think im going to have to try some different transceiver boards because i have no other logical option then these ones are faulty.

8. I, too, have switched to Collin's library. Service routines are great! Thanks Collin!

9. Originally Posted by TurboStreetCar
I think im going to have to try some different transceiver boards because i have no other logical option then these ones are faulty.
I used that board no problem, I know this is mentioned before, but the jumper is to terminate (or not) the CAN bus. Anyway have you tried to contact the seller? Maybe swap it out?

10. Well the pair were about 5\$ if I recall correctly. Not a big loss, prolly a Chinese knock off Ti chip.

The two pin header is electrically identical to the screw terminals. There is a 120ohm. Surface Mount resistor on the board for termination.

11. I had to dig mine out, but you're right. I do not remember where I got the jumper to terminate bus idea. Anyway like you said they are cheap, just as easy to buy another one.

12. I just committed a new version of the library. There are two new things.

Now listen only mode is supported if you want to use it. But, it's not something I'd recommend you use unless you know what you're doing as I've previously in this thread covered the sort of trouble you can get into if you do testing with just two nodes and one is in listen only mode.

Probably of more use, it should now be possible to set any baud rate you want to. Well, within reason. You can set anything that could feasibly be generated by the hardware. This includes weird baud rates like 100000, 33333, and 47619. The previously libraries all had hard coded baud rates that would be supported. No more hard coding. But, watch for falling rocks. I've tested it at some baud rates but I'm still testing every baud rate. If you run into trouble with a certain baud rate then let me know. But, so far it looks like it is generating good configurations for common baud rates.

13. Originally Posted by Raymond_B
I had to dig mine out, but you're right. I do not remember where I got the jumper to terminate bus idea. Anyway like you said they are cheap, just as easy to buy another one.
Yea, the board is very simple. It's just the TI chip and two resistors. If they offered the chip in threw hole, I would buy just the chip. I'm sure there are knock off chips out there and I'm thinking that I got a bad batch.

14. Is there a known good supplier of these can chips? It seems the bare chips from TI are about 4 times the cost of the breakout boards commonly available.

15. I saw those, seems the waveshare ones have good reviews too. The picture i posted is not actually the board i received, its a picture of the waveshare, and i received some other board that is of same design. I think im going to try either those, or the actual waveshare ones.

I've been using your new version of FlexCAN and in particular interested in the receive routine. I see you have implemented your own buffer, this would be very useful in application where the CAN data comes in quickly and need to be buffered before it can be processed.

I've tried to increase the buffer size to 512 (#define SIZE_RX_BUFFER 512) but it then started to loose frames. Looking at the FlexCAN.cpp and in the function FlexCAN::message_isr(void) I've notice the temp variable is only a uint8_t so it probably overflowed. I've changed it uint16_t this seems to solve the problem.

skpang.co.uk

17. Ok did a little more experimentation to confirm whats going on with my CAN hardware. i know, broken record, but im really trying to wrap my head around it.

I hooked up the teensy to the arduino again, arduino running a single write function into the bus.

Message is received by the teensy, Available() returns 31, read() returns 1 and the message is printed.

Next line, available() again returns 31, read again returns 1, and the message is printed perfectly.

While letting that loop of reads run, if i hit the reset button on the arduino, effectively powering it off. Available() will then count down with each line, when it gets down to 1, it prints the final message remaining in buffer and the loop stops. It stops because there are no more available messages to read.

Based upon that, the reception of messages by the Teensy and TI chip seem to function properly as far as reading and clearing the bufffer. The transmission of messages by the arduino seems to "work" yet the message transmissions fail to cease when received, typical of a lack of ACK by the receiving node. Im unsure if the ACK isnt being sent by the Teensy, OR if the ACK isnt received by the Arduino.

i set up the same experiment, but attempt to send from Teensy and receive on arduino.

Without touching a single wire, or other piece of hardware, i write a simple sketch for each device , teensy to send and arduino to receive.

I never receive a single message on the arduino from the teensy.

On the teensy, the write() function will return a 1, for 17 cycles threw the loop, it then returns a zero, assumingly due to the TX buffers being full of un-transmitted messages.

This leads me to believe that the problem is an issue with transmission from Teensy. Not only cant it not transmit messages, BUT there is also the issue with a lack of ACK on received messages. This leads me to believe the Teensy, for an unknown reason, Is incapable of sending ANYTHING including messages and ACK's.

Im not sure its an issue with the chips, or code, but either way, the Teensy will not send signals of any kind.

As far as The ACK on received messages, is that handled by the TI chip automatically? Or is it handled by the FlexCan within the teensy?

18. I'm putting Collin's FlexCAN into the next installer. Hope that's ok?

I *still* don't have CAN hardware set up here for testing, so I'm really depending on feedback about which version ought to be in the installer.

19. your car can make a good candidate

20. Originally Posted by tonton81
your car can make a good candidate
It's 16 years ago, no CAN bus.

21. If a junior member could make a suggestion.

I ended up with three copies of FlexCAN on my Mac and it became confusing as to which one was being used by the IDE. Then I noticed that DallasTemperature.h and a line as below which allowed the version number to be printed in the setup function.

#define DALLASTEMPLIBVERSION "3.7.7"

That seemed like a good idea to me and I would recommend that for the various libraries that are being changed frequently.

I ended up putting a similar line in my three copies of FlexCAN.h just to be sure. I then deleted the ones that were not being used.

22. Not the best example - but with verbose on the IDE in the output window - thanks to Paul will put out lines like this:

Using library TFlasher in folder: C:\tCode\libraries\TFlasher (legacy)
When there are multiples seen it will show them as not used.

23. I can see that the IDE output window shows the directory the library is in. But, I don't see any reference to a version in the output window or the library files themselves.

Since I am new to this I may not know where to look. But, in a case like FlexCAN where there are 6 contributors and multiple releases from each of them, I would think that some indication of the version in one of the library files would be a good idea.

24. This is an issue with the Arduino IDE.

I use Visual Studio.NET and the visualMicro plugin to do all my work that requires the Arduino IDE. When I include a library, I use
Code:
#include "Absolute\path\to\library"
I have had to turn off deep search indexing, but it's working so well. As I am using my teensy boards for nearly exclusively CAN communication, I have multiple libraries installed as well. It does get quite confusing.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•