Little endian CAN passthrough troubleshooting
Posted: Sun Nov 19, 2017 9:43 am
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!
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!