topic Re: J1708 Bus synchronization in S12 / MagniV Microcontrollers

J1708 Bus synchronisation

JSB — Fri, 25 Jan 2008 11:03:22 GMT

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

Re: J1708 Bus synchronisation

jrsimma — Sun, 10 Feb 2008 08:10:32 GMT

J1708 isn't a simple interface. Simma Software, Inc. sells a J1708 device driver that does what you need.

http://www.simmasoftware.com/j1708.html

Re: J1708 Bus synchronisation

JimDon — Mon, 11 Feb 2008 00:23:48 GMT

Jr,
I think that your suggestion, in most cases in the best idea from a business perspective.

Developers don't usually ever see the true cost and fail to realize how much it can lower the over coast to buy certain components.

However I wish you would add a price. It is ok to qualify the price with possible modification charges and so forth, but it is much easier to sell something like this to our managers if we have at least a ballpark price.

Re: J1708 Bus synchronisation

jrsimma — Mon, 11 Feb 2008 01:25:11 GMT

Jim:

Thanks for the response and suggestion.

I don't mind supplying a price, but I would prefer to continue this discussion over e-mail or the phone. Please send me an e-mail or give me a call on Monday. You can find my contact info at the above mentioned website.

Thanks,

Re: J1708 Bus synchronisation

JimDon — Mon, 11 Feb 2008 02:18:15 GMT

Jr,
I am not currently in the market for this type of product, I am just stating that it would be a benefit if you gave the developer a ballpark to work with. I realize there can be many factors that can affect a price, and as I said you can hedge the given price with many qualifiers, but managers want to know - under 1000? 5000? 10000?. 100000? At the same time you could and should given estimated coding/debug time so managers can make an informed decision.

I will tell you right now, I have had my employers purchase 5 figure packages. They did it with out batting an eye because they knew that we needed the technology and that the cost of development was way more that the initial coding, and that the true cost is in maintenance (i.e. bug fixing). Not to mention the cost of lost customers while you get it all working.

I do know this, 2500 would be a bargain, and even 5000 would be a good deal. I'll bet it is less that this. Even if it is more figure this:
Take what you make per week, multiply by at least 1.25 to 1.5 (true cost of you to your company) and divide that into the cost. Can you honestly say you will have a mature J1780 driver in that many weeks? Mean while, the rest of the project is not being worked on, so consider that cost as well.

I am a very experienced developer, but I can't be expert in all the many technologies that come to play in a project these days. Maybe J1708 seems to be not that hard, but the real problem is in testing. Presumably you will be talking to a wide variety of devices, and others may have interpreted the spec slightly different that you did. Even if the device has been "certified" it still may not work with your code. Trust me, you will spend many long hard hours trying to figure out what the **** Ford did on model xyz.It sounds like JR has already done that, and can deliver that hard won experience at a fraction of the cost. (I don't know JR and have no connection with him, for all I know he could be full of it, but he sounds on the up and up - check his references for yourself, and let the business guy negotiate the contract).

If you think this will put out of a job, the truth is quite the opposite. There is still the application to do, and this is just one small aspect. If you want put your self out of a job, spend the next month(s), year(s) getting this code 100% right. No, it will make you the hero. If the product gets to market sooner and better, your company will make more money. This has to be good for your job.

But, since I can't even seem to convince others to use Processor Expert, I doubt that this advice will be taken to heart, so don't hold your breath JR :smileyhappy:.

Re: J1708 Bus synchronisation

jrsimma — Mon, 11 Feb 2008 12:15:50 GMT

Jim:

You're very insightful. I just had a conversation with a potential customer a few weeks back. They were trying to do their own J1708 interface and were 3 months behind schedule and had something that was completely broken. The project got so bad they flew in 4 engineers to try and help, but couldn't. Needless to say, their end customer wasn't happy and they were over budget. I'm sure several people at that company now have a tarnished reputation.

Nice job. You seem to get the big picture.

Thanks,

Re: J1708 Bus synchronisation

RufusVS — Thu, 25 Nov 2010 03:27:07 GMT

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

Re: J1708 Bus synchronisation

jrsimma — Thu, 25 Nov 2010 04:39:37 GMT

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.

Re: J1708 Bus synchronization

RufusVS — Fri, 26 Nov 2010 16:35:09 GMT

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

Re: J1708 Bus synchronization

saim — Mon, 28 Mar 2011 07:28:36 GMT

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

Re: J1708 Bus synchronization

RufusVS — Mon, 28 Mar 2011 11:54:05 GMT

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

Re: J1708 Bus synchronization

jrsimma — Mon, 28 Mar 2011 20:49:55 GMT

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.

Re: J1708 Bus synchronization

saim — Mon, 28 Mar 2011 22:11:43 GMT

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

Re: J1708 Bus synchronization

jrsimma — Mon, 28 Mar 2011 23:07:35 GMT

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.

Re: J1708 Bus synchronization

saim — Tue, 29 Mar 2011 00:21:05 GMT

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.

Re: J1708 Bus synchronization

jrsimma — Tue, 29 Mar 2011 07:38:35 GMT

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".

Re: J1708 Bus synchronization

jrsimma — Tue, 29 Mar 2011 07:41:38 GMT

This J1708 Introduction covers bus access time.

Re: J1708 Bus synchronization

saim — Tue, 29 Mar 2011 20:30:02 GMT

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

Re: J1708 Bus synchronization

jrsimma — Tue, 29 Mar 2011 20:37:39 GMT

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.

Re: J1708 Bus synchronization

RufusVS — Thu, 31 Mar 2011 20:02:20 GMT

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.