Little endian CAN passthrough troubleshooting

[KeithBoden]

I'm building a CAN bus device that is compatible with Tunerstudio's 29-bit CAN passthrough. So far, my controller properly handles MSG_CMD, MSG_REQ, MSG_BURN, MSG_XTND, MSG_PROT, and properly sends MSG_RSP and MSG_BURNACK messages. I can start TunerStudio MS with my CAN device hooked to the CAN bus off my MS3-Pro, and can see TunerStudio request the Signature, RevNum, Protocol and the 1 page of data I have (64 bytes). When this happens, I can see TunerStudio making 8 requests for the page, 8 bytes at a time as expected.

I am currently doing this with the .ini file for the device set as big endian. Data does get written to my device ram and eeprom on a burn, however, since my device is actually little endian, the data for multi-byte values doesn't go into my struct for the page correctly. Totally makes sense, TunerStudio is sending the data big endian as requested.

If I change the ini file to little, reload it in TunerStudio for the device, and then go online, here is what happens:

TunerStudio requests Signature and RevNum. Since these are character strings, endianness doesn't come into play and TunerStudio is happy.
TunerStudio requests the Protocol. I send [2, 0, 64, 0, 64]. I'm not 100% sure what these values do but I think since my page size is 64, they are ok. (I also tried [2, 64, 0, 64, 0] in case the blocking factor and write blocking factor are interpreted based on the endianness in the .ini file)
Then TunerStudio starts requesting the table data but it continues to request blocks of data after the 8 requests:
Req Table 4 Offset 0
Req Table 4 Offset 8
Req Table 4 Offset 16
...
Req Table 4 Offset 56
Req Table 4 Offset 64 <- This one doesn't happen when set to big endian

If I don't respond to the request, TunerStudio errors out stating that it didn't get a response (makes sense). If I respond with junk data, TunerStudio keeps requesting additonal data, 72, 80, 88... until a timeout occurs since it has taken too long to get the page.

Is it possible that TunerStudio is interpreting my pageSize, which has to at least be a 16 bit number, using the same endianness as the .ini file? In other words, my specified table size of 0x0040 is being interpreted as 0x4000 = 16384? Or is there something wrong in my .ini file or protocol response that is causing this behavior?

.ini file attached, and I can gladly send logs of anything you would like to see to help work this out!

[KeithBoden]

LT401Vette, you are probably the only one who can help - appreciate your time if you can spare a few minutes!

I'm working on this to help out another guy that wants to run a hydraulically controlled differential with his MS3. (http://www.msextra.com/forums/viewtopic ... 25&t=67471) I think the best way to do it is with an add on device and we'd love to be able to tune it through the CAN passthrough. Is it possible that the endianness issue is a small fix in TunerStudio? I'm running the paid version of TunerStudio and don't mind sending some Paypal to bump the priority up on this if it helps

[LT401Vette]

I will have a look and try to get a fix in the beta.
I don't have any little endian boxes around here that use a blocking factor

[LT401Vette]

Can you capture a Comm Debug log of this?

in my testing blocking seems to be working in little endian.

[Dron_Gus]

Sorry for necroposting.
Seems I hit the same bug while trying setup passthrough connection using MS3 as a master (big endian) and RusEFI dual Wideband controlled as a slave (little endian)
It seems to me that TS picks endian from Wideband ini file when constructing commands. But these commands actually go to (and decoded by) MS3, that converts it into CAM messages.
So I think endian of master should be used in this case.
Command I see when TS tries to read Wideband controller (CanId = 12 = 0x0c):

Code: Select all

x00 x07 x72 x0C x00 x00 x00 x10 x00 xDB x9B xCC x56                   ..r.........V

Page 0, offset 0, size 16 (couse blocking factor = 16): But instead of big endian for size (0x0010), little endiad is used (0x1000). MS3 read this values in big endian and get size = 4096 bytes. This cause a lot of CAN CMD_REQ commands with incorrect offset...

I can provide more debug info...

[LT401Vette]

Try adding this to your WB ini:
forceBigEndianProtocol = true