Printable View
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
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.
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
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.
Use with care on code that reduce stack for the return address. It might crash as well.
What, you no like pop? <<<<< code humor :happy:
Found one other Hmmmm in the code, this one doesn't matter at all, just a point of interest...
I am not sure what the point of mode 5 is. What ever you send, it just replies 'AA' and does nothing else. Probably just completes a sequence for the tester or ??
Thing I found is, in the programming code, the checksum is never tested. It needs to be there but the value isn't tested. So:
$F4 $56 $05 $55 works just as well as
$F4 $56 $05 $B1 with correct checksum.
OK, so I am now through the code and starting changes needed for functioning code under bootstrap. When you enter bootstrap, no chip selects are defined thus FLASH and PRU are not in the memory map. There is a pesky rom to remove from the memory map. I intend to up the baud rate to reduce time and need a workable way to make the change. Qs for you all: do you have a feel for what baud to use? Faster is better VS. reliable comms. I need to turn off the Tside ALDL driver (not connected right now but later...) and a few other house keeping things.
Do you feel that these setup things are better done in a subroutine? This permits NOT messing with the '95 programming code but has a downside of making the procedure of baud rate change more cumbersome. My current thinking is to start bootstrap in low speed. This is because bootstrap starts the SCI up in wire_or_mode. I don't want to hang too much of a pull-up resistor off the port, so starting at 1889baud makes sense to me. Once the housekeeping routine is run the rate can be upped because port D can now be driven. Thoughts?
One other consideration, since bootstrap has no chip-selects enabled, the internal ram is all that is available. It may be unavoidable to modify the standard code just because I need the space.
-Tom
Give all that, programming in the standard rate is slow in human terms. Speeding it 4X if possible makes it much better, perhaps I should aim at around 32-64Kbps??
-Tom
yeah, completing a sequence for the tester is pretty much why it's there. before sending any mode 6 requests, the tester is supposed to send a mode 5 request, and the ECM either replies 05 AA or with a 0D if mode 5 is locked out. having mode 5 reply just satisfies that requirement so someone uploading code doesn't have to worry about whether they're executing from rom or ram and follow the same procedure. in my software i've changed the AA response byte to that command to something else, so we can branch on the condition that the kernel is loaded or not loaded (so we don't try to load a kernel over itself, which is a crashy thing to do)Quote:
Originally Posted by Tom H
your end goal here is just for recovering bricked ECMs, right? nobody will mind waiting for that, so i wouldn't focus too much on how fast it is. even if you can get it near 9600 baud or something it will serve its purpose wellQuote:
Qs for you all: do you have a feel for what baud to use? Faster is better VS. reliable comms. I need to turn off the Tside ALDL driver (not connected right now but later...) and a few other house keeping things
Right. So the options are:Quote:
Originally Posted by steveo
118, 236, 384, 473, 512, 768, 945, 1024, 1536, 1890, 2048, 3072, 3781, 4096, 6144, 7562 --> all slower than the 8192 GM selected. 1890 is the default bootstrap speed in my config. I need to change gears before unbrick runs.
8192 --> Tried and true
12288, 15124, 16384, 24576, 32768 --> a bit faster but still within reason
49152, 65536, 98304, 196608 --> Much faster but I don't know if my PC and serial cable can keep up. Not planning to test.
I will try 32,768 and fall back to 16384 if it isn't solid enough. I expect it is OK though because GM doesn't use wire-or mode.
-Tom
I vote for the slowest most reliable option for recovery. $400 bytes of ram is plenty enough. Anyway the original code is set to use 0-1ff as comm loop 300-on as buffer for write message and 200-2ff for code buffer. Each routine is sent on demand. You send erase routine at $200, it is executed and you got positive response, Than send write routine at $200 and overwrite the write buffer.
That way you can make small chunks of code that are send on demand to save ram.
The change of speed can be handled that way. You send some code that change the baud with some wait time after that, for the tool to switch speed.
Hi,
I need a little help understanding the various configurations GM turned out for LT1 SFI. My overall is to help with s/w that un-bricks modules. One of the things I need is to parse binary files and turn them into aldl messages. I would like to understand how you identify the code sets. There are a bunch of questions that pop up...
The computer used for the car is
16188051 1994/5 LT1 OBD1
16181333 1994/5 LT1 OBD1.5
16214399 1996 LT1 OBD2
16242921 1997 LT1 OBD2
Correct?
I see the term $EE and $EEB used for the code. I also see BCC and other terms. Is this explained somwhere? What code are the later 96/7 given.
Once found, I plan to write some small code to extract/separate the Eside and Tside binary, producing files broken up into ALDL messages to drive my bootstrap code.
If all this is explained somewhere, please send me a link.
-Tom
All 94-95 files and pcms are interchangeable. On the average bin you want to parse, first part is tside and second part is eside. there is also ram 0-2000 area in the files. You can cut these and parse 2000-ffff as tside and 12000-1ffff as eside.
96 and 97 files are slightly different but have common structure. Not quite sure if 96 bin will work on 97 pcm.
All 96 files are interchangeable for 96 pcm and all 97 files are interchangeable for 97 pcm.
96-97 files are 0-56 kb tside bank0. 56-88kb bank1 tside. 88-144kb eside.
Plan to go ahead with 1890 baud as you suggest.Quote:
Originally Posted by kur4o
I have completed a few tasks to get closer to the UnBrick software. The 94/5 file format parsing is complete. My routine (posted below) takes the standard bin file as input and produces four files. Two are just the split of the binary into Tside and Eside. The first $2000 bytes are truncated because we do not program those. The second pair of files contain an array of ALDL messages that will drive the 68HC11 code. I have now tested the ALDL messages and they seem to work. Just a bunch more testing to be sure all is correct before moving to test. First focus will be on the Eside of 94/5. Get that going and the rest will follow quickly.
One problem I am running into is with the hardware I use to download with. I have one of those $2 cables for serial. I have tried a bunch of drivers and so on but the noise flag on the 68HC11 sci keeps being set. To get past this, I have eliminated the noise flag from my routine BUT there is something going on & it bugs me I don't know what it is. The noise flag is generated by oversampling the start and stop bits. While I don't see any troubles on the scope, my equipment is hobby quality. The other issue might be level, but I see at least a 3.2V high and a 0.5V low. I wonder about the time base for these USB-->serial ttl cables. Perhaps the bit times wander around?? In any case my workaround of removing the noise flag seems OK. Parity matches every test, so I think it is OK. I would go out and get another cable but it will probably take till fall to get it out of China... Any help or ideas on this (ps I tried a 150pf cap on the tx: no change)
Not quite sure what files to post, I have given the C++ source and the x64 executable. I tested with BSYX_EE.bin which is posted on this site.
-Tom
Would like to post code, but I get "invalid file" do I need to make them all .txt??
Files with extension changed (?)