pcmhacking.net

I didn't think I would figure it out, but the last couple days I found a some things that were really messing everything up.

There is only 7 bytes because I was trying to make it compliant with ISO 15765-2 which defines how to split long messages into CAN packets. With that standard (which is what the OS code is programmed to parse) the max number of bytes a single CAN frame can transmit is 7 bytes. There are probably other ways to do it since I'm in fully control, but I think going that route makes the most sense.

I'm not sure what my next milestone should be, but I guess probably start working on implementing the code to handle full ISO 15765-2 Tx and Rx. There is some clean up work to be done, but that should be a sufficient amount of work to keep be busy.

bubba2533 wrote:I didn't think I would figure it out, but the last couple days I found a some things that were really messing everything up.

There is only 7 bytes because I was trying to make it compliant with ISO 15765-2 which defines how to split long messages into CAN packets. With that standard (which is what the OS code is programmed to parse) the max number of bytes a single CAN frame can transmit is 7 bytes. There are probably other ways to do it since I'm in fully control, but I think going that route makes the most sense.

I'm not sure what my next milestone should be, but I guess probably start working on implementing the code to handle full ISO 15765-2 Tx and Rx. There is some clean up work to be done, but that should be a sufficient amount of work to keep be busy.

Spot on

A simple example for the ISO standard:
7E0 01 20 AA AA AA AA AA AA
7E8 01 60 AA AA AA AA AA AA

Where 01 is the length byte indicating 1 byte to follow. Note that most ecus will pad the rest of the CAN packet with AA,55,00 or somethings random bytes.

Once able to read in frames based off a single byte length, then can look at the flow control messages which look a little like:
7E0 10 XX 11 22 33 44 55 66
7E8 30 00 00 00 00 00 00 00
7E0 21 77 88 99 blah blah
7E0 22 blah blah

Where the first 0x10 indicated multi frame packet incoming, the ecu responds with 0x30 which is the flow control message, and finally the rest of the message follows. Theres a little more to it but thats the basic gist.

Got my splitter in and it's pretty awesome to be able to be able to write frames with one tool via ISO 15765 protocol and standard CAN with another tool.

I've made pretty good progress on upgrading the test kernel to be ISO 15765-2 compliant, but there is still a little more work to be done.

The code looks a little ugly and it's become quite large... but it's working!! I actually transmitted the entire kernel (0xD60 Bytes) in one payload on the OBDX Pro GT.

Here is part of the raw CAN log (using the Tactrix cable). The arrow points to the beginning of the echo from the kernel. I need to do a bit of code clean up and do some more testing before moving onto anything else. If I'm feeling ambitious I might try to reduce the kernel size because it looked like there was a lot of room for improvement when looking at it disassembled.

Impressive work Bubba. Do you have a background in computer science or software development? Just curious as I've followed your work and applaud your efforts at modifying code on these controllers and your boost OS shows what can be done inside of a functioning OS.

bubba2533 wrote:The code looks a little ugly and it's become quite large... but it's working!! I actually transmitted the entire kernel (0xD60 Bytes) in one payload on the OBDX Pro GT.

Here is part of the raw CAN log (using the Tactrix cable). The arrow points to the beginning of the echo from the kernel.

Multi-Frame_Message.JPG

I need to do a bit of code clean up and do some more testing before moving onto anything else. If I'm feeling ambitious I might try to reduce the kernel size because it looked like there was a lot of room for improvement when looking at it disassembled.

Nice!!!

If you set all variables as volatile and then enable optimizations in the compiler, it should reduce the size significantly.
I suggest making items volatile as I found the compiler will just removal important parts that it thinks may be irrelevant such as a nop loop, or looping over a register to check for a change.

Cincinnatus wrote:Impressive work Bubba. Do you have a background in computer science or software development? Just curious as I've followed your work and applaud your efforts at modifying code on these controllers and your boost OS shows what can be done inside of a functioning OS.

I don't, I'm a mechanical guy from my schooling. I've been all self taught on programming and disassembly. I've taken a few Udemy courses for C and C++ over the past 6 months since my work offers free access.

Tazzi wrote: Nice!!!

If you set all variables as volatile and then enable optimizations in the compiler, it should reduce the size significantly.
I suggest making items volatile as I found the compiler will just removal important parts that it thinks may be irrelevant such as a nop loop, or looping over a register to check for a change. :lol:

Thanks for the tip!

Hiya,
Something to add for your files. 2018 E92a Camaro so you have a reference to newer stuff. I am pretty sure I have a supercharged version from a couple years ago too. This T87a is pissing me off

Might have to pick one up. How would I identify it from a standard E92? Probably look on eBay for one.

In-Tech wrote:Hiya,
Something to add for your files. 2018 E92a Camaro so you have a reference to newer stuff. I am pretty sure I have a supercharged version from a couple years ago too. This T87a is pissing me off :comp:

2018_Camaro.zip

Edit: looks like these are more expensive if I’m looking at the right one.

I found this part number 12716901 but it has E93 on the tag.

Here's the one I am working with. Transplant into an early Chevelle, BTW does anyone know if I can use a 2015/2016 8 speed T87 and just swappy? I've heard warnings that it will kill the trans