J1708 Bus synchronisation

[JSB]

Has anyone ever tried synchronising to the J1708 bus using a hcs12 device? Any sample code to help me with bus synchronisation would help.

thanks

[GAVALAS]

Not at all. The right solution is this: You have to make a software trap  not allowing to the C code to receive j1708 messages till to find a time gap  where the bus state is at "1" for at least  1250 μsec . After it, the code is free to collect j1708 messages. It is easy to make a 2μsec time delay. The same logic is in use and  when you want to transmit j1708 messages.

j1708 is still in use at modern car and truck ECUs.

Exact details for free at :   gavalaselectronics@hotmail.com

Athens, Greece.

[RufusVS]

I guess the original poster handled this problem or changed his priorities.

 I only awakened this thread to warn people that J1708 is not simply RS485.  

And to "synchronize" to a J1708 bus, you need a separate interrupt (or status) to indicate bus idle, as there

is no "sync" character in J1708.  And  I know of no UART that will interrupt based on a line being unchanged.

So a typical scenario is to have a separate timer that resets on every received character, and if the timer times

out prior to the next character, then you've reached the end of the current "packet".

And it gets much tougher when you decide to be a transmitter:   You aren't going to be able to use standard

RS485 hardware.

Microchip has a nice little driver description and source code (I had a devil of a time finding) at:

http://ww1.microchip.com/downloads/en/AppNotes/01230A.pdf

http://ww1.microchip.com/downloads/en/AppNotes/J1708_library.zip

Share and Enjoy!

Rufus

[jrsimma]

Simma Software's ssJ1708 source code handles idle bus detection and 5.2.2.1 compliance for ECU's which need to transmit.  The Microchip assembly code isn't fully SAE J1708 compliant and should only be used for reference.

[RufusVS]

My point being:  To do J1708 may require certain specific hardware capability which is not available on all target platforms.

The microchip software has some "errors',  though I didn't dig deeply into the "priority" issue.

I would be interested to know why the microchip software is not compliant, other than the error I mentioned.

Rufus

[saim]

Hi,

I am trying to implement J1708 on MCF5253. I am facing a weird problem in collision detection at bus  load more than 12%(bus is loaded by sending dummy 1708 messages through another device).

I am detecting the collision by reading the each byte that is transmitted and comparing it with the actual data. If there is a collision detected controller will stop transmitting and wait for a random time and will re-transmit.  

So here is the problem - when there is a transmission of message and there is a collision on J1708 bus, controller doesn't see it as a collision and it transmits the complete message, and that leads to corrupted message on J1708 data link.

I am reading the J1708 data link using J-PRO tool connected on the bus.

I confirmed the baud rate and configuration. all are perfect.

What could be the reason for not detecting the collision by the controller?

Need suggestion/solution

Thanks in advance.

Sai

[RufusVS]

Are all the devices on the bus J1708 devices?    You really can't effectively test a J1708 bus with a non-J1708 device.

No device should even start transmitting if there is even one bit (literally) of activity on the bus (except of course the one currently transmitting)

Hence, the only collisions should occur in the first character of the transmission, when both devices

start transmitting within the same bit time.

As MIDs should be unique, the collision should occur on the first character.  The two (or more) transmitting devices

read back their first  transmitted character to verify  the transmission was correct.

If the read back character is not the one transmitted, transmission should cease.

If it is a match, transmission can continue. (the winner had only dominant bits where the bits transmitted differed).

If everyone got a mismatch they all back off.

If one of the transmitters was able to continue, they should be able to continue their message because what was intended was what was seen on the bus.

(N.B. even those devices which backed off should continue to receive the message, as it is valid.)

This bit-level control makes J1708 a non-trivial (and sometimes impossible) exercise on basic UART devices.

Rufus

[saim]

Thanks for responding,

Yes, all the devices on the bus are J1708 compliant. And the problem is with my device only.

I compared the message that has been transmitted (by checking the Tx buffer) and the message on the data link. Roughly one out of 15 messages, the MID sent by my device is corrupted which shows that there was a collision which other devices also detected and they stayed back but my device did not detect it and continued the data transmission till the end of message.

I tried by varying the idle time from 1millisec to 2millisec, which didn't show me any positive result. And I also tried to vary the baud rate around + or - 2% of 9600 baud.

I don't know why my device is not detecting the collision?

Sai

[jrsimma]

How are you detecting bus idle condition?  Are you checking the time since last receive interrupt?  If so, that could be your problem since you might be transmitting when another controller is.

[saim]

Yes I am checking the bus idle using a timer which reloads for every UART interrupt.

And also it waits for a random time if there is a collision detected.

[jrsimma]

I understand what you are doing.  Many people that are new to J1708 do exactly what you have done.  Having the UART RX interrupt clear the timer is 1040 microseconds too late.  You get 1040 us by multipling 10 bits, 1 start, 8 data, 1 stop, by 104.17 us.

Remember 5.2.2.1 specifies a bus access time of 50 microseconds.  What you are doing is exactly what Rufus said not to do.  Remember he said "bit", not "byte".

[jrsimma]

Saim, what Rufus is talking about is critical to understand.  If you do not comply with the 5.2.2.1 section of J1708, you can bring the entire network down.  Which results in the vehicle operator having to reboot his vehicle.  This then requires a recall on your part.   We know of three different companies had that experience.  In order to fix their problem, they bought our software and J1708/UART reference design.

If you are only looking at the receive byte interrupt to determine when the bus is idle, you have a bus access time of no less than 1042 microseconds.  The 5.2.2.1 section calls out 50 microseconds or less.

Our J1939/J1708 adapter, and our J1708 software, both have a bus access time of around 2 microseconds.

[jrsimma]

This J1708 Introduction covers bus access time.

[saim]

JR,

Thanks for your information.

I think the points that you suggested are to avoid collisions and to run the transmission smoothly.

But the problem here is my device is not detecting the collision when there is corrupted MID on the bus.  Is there any relation of not having a proper bus access time and not detecting the collision?

I think if there is improper access time then there should be more collisions on the bus and my device should show more retransmits which is not the scenario here.

Thanks and regards,

Sai

[RufusVS]

You can't simply pump out the message.

If you place more than one character in the typical UART transmit register, by the

time you read back the first character and verify it is what you sent, the next character 

is already in the shift register on its way out.

Conceivably, you could have hardware that "puts on the brake" by suspending the UART

or gating the bit stream outside your chip, but more likely you would have to:

a) Send the first character (MID)

b) Wait for the echo back.

c) Compare to transmitted MID

d)  if equal, transmit remainder of message.

e) if not equal, attempt receipt of message on the bus (from external source)

f) After appropriate idle time, retransmit or transmit next message, if any.

[saim]

JR,

I am making sure the byte is out of the FIFO buffer by checking the TXEMP flag in UART status register after placing the byte in Tx buffer.

MCF_UART1_UTB = J1708_Tx_Buffer[J1708_Tx_index];

 while(MCF_UART1_USR & MCF_UART_USR_TXEMP != 0x08 );

Immediate after  this the UART is converted to receive mode to read the byte that was transmitted and the collision detection sequence executes.

And rest of code is as you mentioned. Still my controller doesn't see the byte corrupted on bus

Following are the tests I did to confirm the peripheral working good.

1.  I  confirmed the currupted message that is transmitted is appearing on the RXD pin of controller by triggering the oscilloscope through another J1708 board which sets a GPIO on receiving corrupted message. Which proves that my RS485 is working fine.

2. I connected the RXD pin of UART1(J1708) to RXD pin of UART0 and implemented to get the copy of data at the time of  collision detection. I observed both the UART1 and 0 shows the same data when they check for collision.

3. I modified the code in 2 by using UART1 only for Tx and Rx and UART0 for collision detection. Again it shows the same behavior. 

Thanks

Sai

[RufusVS]

sai,

You said in your message: "Immediate after  this the UART is converted to receive mode" - what does that mean?

Your UART should always be receiving, even (or especially) during your transmit.

Is your receiver receiving the MID echo as uncorrupted (a match of what you transmitted), or not receiving it at all?

 If your receiver shift register isn't  monitoring the serial line when you are transmitting those bits out, you won't get anything at all.  Is that what's happening?

Rufus

[saim]

Hi Rufus,

Yes i was disabling Rx interrupt while transmitting. As MCF5253 has common interrupt source for Rx and Tx I assumed, that would not get a chance to transmit the byte on the bus at high bus load.

Now I removed the disabling of rx interrupt at the time of transmission and also changed the Tx and Rx ISR sequence which is running smoothly.

Thank you all for the info and sharing the thoughts.

Regards,

Sai

[jrsimma]

Early on you mentioned something about JPRO, so I'm confused on your setup.  Normally you have a micocontroller connected to a RS-485 transceiver, which is connected to the network.  So what is this JPRO device you mentioned and where does it set in your setup.

Maybe you are using it to analyze the network.

Thanks,

JR Simma

The J1939 and CAN Experts

[saim]

JPRO is a J1708 tracer software. It has an adapter which connects on the J1708 bus.

It is used for J1708 bus trace purpose.

Thanks

Sai

[jrsimma]

I understand your situation.  When there are multiple issues, it is more difficult to troubleshoot and diagnose.  I suggest you fix your known issue first.  Then your second issue will be easier to find.  Least that is what I would do.