Some devices are unable to transmit large blocks of data

[eventsb]

When programming a module such as a PCM, data is sent in blocks of 0xFE0 at a time. I've noticed that J2534-Sharp is unhappy with blocks of these size, and throws an exception.

If I use a Drewtech MongoosePro, the message does get sent successfully but an exception is thrown anyway:

"Only sent 0 of 1 messages"
   at SAE.J2534.API.CheckResult(ResultCode Result)
   at SAE.J2534.Channel.SendMessages(HeapMessageArray hJ2534MessageArray_Local)
   at SAE.J2534.Channel.SendMessage(Message Message)

I've been able to get around this by just swallowing the exception for now, but I wanted to document this as it is still unwanted behavior.

If I use a Tactrix OpenPort 2.0, the error I get is:

"GetLastError failed with result: TIMEOUT"
   at SAE.J2534.API.CheckResult(ResultCode Result)
   at SAE.J2534.Channel.SendMessages(HeapMessageArray hJ2534MessageArray_Local)
   at SAE.J2534.Channel.SendMessage(Message Message)

And the message never gets sent at all. If I reduce the block size down to 0xa00 then it works for the OpenPort without errors, but programming time is significantly increased due to the smaller block size.

Also, when receiving large blocks of data using the Tactrix OpenPort, I need to put a small delay before calling GetMessages() otherwise the buffer remains empty.

[BrianHumlicek]

I believe I have used blocks of 0xA00 in size successfully (Ford 6.4 Diesel PCM) before. The current message size limit is 4152 bytes and 200 messages per block. Because this is under that limit and you say it sends the message, it doesn't sound like J2534Sharp is having any trouble.

Fortunately, you have a Drewtech device which supports API logging, so, I would advise turning that on and capturing what it says about the situation. To turn on the logging, there is a folder somewhere that you put a file called DebugMongooseEnable.txt, and then it will start dropping logs into that folder. You will have to consult with Drewtech docs for more details than that though. I'd be curious to see what it says about the situation.

As for the Tactrix device issues, those are problems with their driver, not with J2534Sharp. J2534Sharp will wait until the driver says a message is ready, and then read it. It sounds like the driver is saying a message is ready, but it really isn't quite yet.

Let me know if you get more detailed logging info and I'll see if it something I can help with.

Brian

[eventsb]

I believe I have used blocks of 0xA00 in size successfully

For clarification, for the Tactrix device, 0xA00 sized blocks work fine, but anything larger than that does not work and throws the above exception. Ideally we should be able to program using the full 0xFE0 block size.

Fortunately, you have a Drewtech device which supports API logging, so, I would advise turning that on and capturing what it says about the situation. To turn on the logging, there is a folder somewhere that you put a file called DebugMongooseEnable.txt, and then it will start dropping logs into that folder. You will have to consult with Drewtech docs for more details than that though.

Here is the output of the Drewtech API log when trying to send a data block of 0xFFE bytes. Again, when using the Drewtech device, the message does in fact get sent, but an exception is thrown for some reason. The last line says ERR_TIMEOUT, perhaps this can shed a clue.

[BrianHumlicek]

Did this ever get a resolution?

[eventsb]

No

We are just swallowing the J2534Exception to get around it in our application.

[BrianHumlicek]

Looking at the log, you are transmitting that large message with a 100ms timeout. Try increasing that to something like 2000 just to see if that lets it complete.

I have updated the library so it might give a more helpful message in the case of the Tactrix device.

Brian

[prj]

This is exactly what the issue is. If the ISO-TP layer takes longer than 100ms, you will get an error message. In case STMIN_TX accepted by target device is large, then you can hit this issue with much smaller message lengths.

[BrianHumlicek]

This sounds like a device configuration issue then, correct?

[prj]

Yes, a layer 8 problem. There is no problem with your library, it works fine for any block size. P.S. It would be nice if it would be possible to pass a timeout to the SendMessage call without having to set it on the channel each time.

e.g. SendMessage(args, timeout = -1) and if timeout is -1 then use the default value from the Channel. This seems to be discouraged in the new J2534 spec though, as it states that the call should return immediately and the transmit message status should be gathered by reading TX_INDICATION messages instead... but this is not what 99% of the J2534 DLL's implement at the moment.

[BrianHumlicek]

I don't see an issue with adding an overload to SendMessages that takes a timeout value. I will work on getting that done.

Thanks,

Brian