OBD2 LT1 XDF $EE EEX creation

[Tom H]

I need some confirmation....

Message format over aldl is [DEVICE ID] [LENGTH] [MODE] [MESSAGE …] [CHECKSUM]

for mode $06 and message $55, does this mean command in progress, not completed yet?

THX -Tom

[steveo]

yep, or in other words just to tell the tester 'wait until next message'

in practice, the only code that seems to use it is the erase routine (being the only code that could potentially run long enough to need it)

[Tom H]

Some small progress to tell you about...

This morning I was able to download all the flash routines while in bootstrap mode. UnBrick is not yet alive, but showing signs of life. So far, just the ESide... still waiting for parts from china to get to the TSide, w a i t i n g & w a i t i n g
-Tom

[Tom H]

Question regarding mode 6, I happened on an unusual fail. I wanted to execute code without download. That is, a transfer of 0 data, execute at the location. Please confirm if you agree or don't...

Consider a download & execute message of $F4 $57 $06 $00 $00 $AE

$F4 passes the test for valid device
$58 passes the length test (>$56)
$06 mode 6
$00 address h
$00 address l
$AE checksum

The routine assumes the download isn't 0 and writes the checksum as if it were data. Then decrements the count which will underflow. The next 256 characters sent will over-write. The 257th byte it gets will be interpreted as checksum and will likely fail and return to the main loop IF it has not been overwritten. Also possible that the 256 writes disturb ram used by this code and crash.
I think: All code that permits download should also include a test for this and prevent it.

Do I have this right?
-Tom

[steveo]

i do agree and observed it crashes although it's nice to have a theory why

in practice sending a 7E jump only incurs 3 extra bytes of overhead, so that's what i ended up doing in flashhack

thanks for reminding me of this, as some of my code doesn't check for empty mode 6 data payloads, it'd be nice to trap that error if i ever make a mistake somewhere

[kur4o]

Mode 6 is always download and execute.

In that case

$F4 $57 $06 $00 $00 $AE is

download at $0000 address zero bytes and execute at $0000 address.

I suspect that aldl chip verifies checksum and never sends checksum byte to PCM` cpu and also truncates the message if the checksum doesn`t match. If you are sending this straight to cpu without using aldl chip as a buffer you actually write AE at addess $0000 and than execute it as code. So opcode $ae is a crash for cpu.

IN bootstrap mode some form of checksum should be implemented in the message receive loop, in case it doesn`t match than skip the jsr to download address.

[kur4o]

I figured why it crashes.

You need at least $58 message length to save the jump buffer. Otherwise the code enters loops expecting more bytes that are never send.

It is also unavoidable to write at least one bytes of data before jumping. There isn`t any length specified to skip on zero length and the code assumes there is at least 1 byte to write.

So the best way to execute only is to overwrite the first byte of the jump location.

$F4 $58 $06 $00 $00 $XX $YY

[steveo]

oh, yeah! that's a good point! in my case while running the kernel, i always know what that first byte of a routine or subroutine is since i uploaded all of them. i can easily abuse this to save 2 bytes of bandwidth in a lot of cases. i'll give it a shot tonight.