CAN getting a correct response

[glstill]

Hi,

I am working with the Frame API for CAN communication.  I have a 2 port pcmia high speed CAN card.  I am also using Intronix's Logic Port tool to monitor the traffic on the CAN bus.

I am talking to a freescale microcontroller which is programmed to respond to messages that I send it.  I have noticed that I have to transmit a frame several (4 or 5) times in order to get the microcontroller to respond correctly.  I am sending a data frame with arb ID = 0x55, data length = 1 byte, and the 1 byte of data is simply the ascii character X (0x58).  The micrcontroller should respond with arbID = 0x66, datalength = 3 bytes, and the data should be x(0x78) followed by the device ID which is A9 or (0x41 followed by 0x39).

Both the micro and the labview app are setup to accept all arbitration IDs.  When i click the button to send the X cmd I see the frame sent correctly, but i get either invalid data as a response from the micro or no response. If i send the cmd a few more times, it finally responds with the correct value.  This issue is occurring for every command that I send.

I also see a bit stuffing error on the CAN Lo line whenever there is traffic. 

Attached is a printscreen of the trace in Logic Port.  If anyone has any suggestions or thoughts please let me know.

Thanks,

Gary 

[Song_M]

Hey glstill!

Were you able to use one of the example Frame API send/receive VIs that came with LabVIEW in the example finder?  If not, I highly recommend trying to use the example VIs for basic read and writes.  Now, if you are still having problems, please us NI-SPY to take a spy log:

http://digital.ni.com/public.nsf/allkb/8D890EC09B15C05A86256E6F007E3E86?OpenDocument

Lastly, you can use the 2nd port as a bus monitor if you would like 🙂  Have a great day glstill tell me if you can't get the two things listed above working! 

[glstill]

Thank you for the response.  I began talking to a device using an example I found in the Labview Frame API examples.  I was seeing the same problem before.  I am now almost certain the problem has to be with the microcontroller.  I never even knew about NI SPY, but I found it very usefull.  I watched the trace in NI SPY and all of my write commands look good with the right parameters.  The responses I get back from the reads are not correct until I repeatedly send the same command.

This makes me think that there is something going on with the microcontrollers MSCAN RX buffers.  The firmware people used a Freescale Bean to setup the CAN bus communication, and maybe a flag isn't getting cleared when a valid frame is received by the micro. The microcontroller is the Freescale MC9S08DZ60.  It communicates with an external transceiver that is on the device.  The transceiver is a Phillips TJA1040.  The transceiver in the NI pcmia CAN card that I am using is the Phillips TJA1041.

If anyone has any suggestions please let me know.

Thanks,

Gary

[Song_M]

Hey glstill!

Can you post a screenshot of the ni spy log or the logs them selves?  Thank you and have a great weekend! 

[glstill]

Hi,

I figured out the problem I was having.  It had nothing to do with the CAN hardware I am using or the Labview application.  Apparently Freescale's MSCAN has 5 RX buffers for received messages and 4 of these registers are in the background and are not addressable by the microcontroller.  When a new message is received, it is put into the back of the buffer and it has to make its way up in order to get executed.  Upon power up, the first 4 valid received messages fill up the buffer and junk is processed each time until the buffer is full of valid messages.

To work around this I set up a state machine for each command I must send to send the message 5 times before parsing out the response. This method is working for me everytime.  Hopefully this may help anyone who has had or may have the same problem in the future.

Gary

[Song_M]

Hey gstill!

Great to hear that everything is working!  Have a great day and don't hesitate to ask any additional questions!