HELP!!! PCM cooked?

[antus]

Im on my phone so its hard to read the debug log but it looks like it was a test write from the start of it? If it was a test write, nothing will be broken and you can restart it. If it was a real write and if it was an os write, you need to be careful. If it was real and calibration only you will at worst case be able to do a recovery flash.

[Gampy]

A Test Write was performed followed by a Write OS and Calibration.
He needs to be careful ...

I believe this to be the important part of the log plus a bit of prior ...

[06:34:20:584] RX: 6D F0 10 76
[06:34:20:585] Found response, Success
[06:34:20:585] Sending 'test device present' notification.
[06:34:20:586] TX: STPX H:8CFEF0, R:0, D:3F
[06:34:20:601] Empty response to STPX with data. That's OK
[06:34:20:605] Sending payload with offset 0x1000, start address 0x041000, length 0x0400.
[06:34:20:606] 0x041000 26% 06:57
[06:34:20:668] Sending 'test device present' notification.
[06:34:20:672] TX: STPX H:8CFEF0, R:0, D:3F
[06:34:20:687] Empty response to STPX with data. That's OK
[06:34:20:688] TX: STPX H:6D10F0, R:1, L:1033
[06:34:20:698] TX: 360004000410007AE10C83000000FF6304163C00FF11C38C27247C00FF926C528A08D2000670374EB90003F44A31C88C2231F8A8B48C9411C18C254EB900041DF24EB900041E404EB900041E7C4A389FE2670A4A389FE06704760160024203B6388C33674E4A389FE2670A4A389FE067047601600242034A03670E247C00FF9268568A08D20006600C247C00FF9268568A08920006702A4EB90003F44A4A389FE2670A4A389FE0670476016002420311C38C333D788CA0FFFC3038A8B4906EFFFCB0790001D2CA650E70544EB90003F44A31F8A8B48CA01C390001D0E6B4066600008C42033D788C9EFFFC3238A8B4926EFFFCB2790001D2C66500013A12388C4B663CB2388C57661430388B5890788CB264024440B0790001D2C8653436388B58C6FC000D86FC010511C39248247C00FF926C0892000231F88B588CB26010B2388C57670C247C00FF926C08D2000276014A03670000E070044EB90003F44A31F8A8B48C9E11C18C57600000CA42871E06CEFC000A4A3079B00001D08C671636388B58C6FC000D86FC010511C38CD116388C4B601436389F3CC6FC000D86FC010511C38CD116388C4C14388CD1200211C092483D788C9EFFFC3038A8B4906EFFFCB0790001D2C6656C10388CD242871E00428112029247C3FC02FB83FC00264A416C0244414A0356C34403B2790001D2C86412B6388CD0660C18388CD9B4046234B00463304A03670C247C00FF926C08D20002600A247C00FF926C0892000211C38CD011C28CD270044EB90003F44A31F8A8B48C9E7408B40666064EB900041F224A3900016A0E660001163D788CA4FFFC3638A8B4966EFFFCB6790001D2CE650000BA4243163897A90C430006623C247035B00007E8164ED27E0160027E0211C78C67602A11FC00048C67602211C28C67601C11FC00108C67601411FC00408C67600C11FC00808C67600442388C6712388C5C670442388C674A01663EB2388C58660A16388C68B6388C67672E247C00FF926C0892000716388C6711C38C6611C38C6811C3924E70034EB90003F44A31F8A8B48CA411C18C5860204A01671CB2388C58660A16388C68B6388C67670C247C00FF926C08D2000760BC163897B57201B20357C04400B0388C4D6732B203660E247C00FF9268548A08D20005600C247C00FF9268548A0892000570214EB90003F44AB23897B557C3440311C38C4D0C060002660004AC4EB900041F22600004A24EB9000418D44A390001D0EE6600049211F88B0C8C6216388C63B6388C62671411F88C62926470014EB90003F44A11F88C628C634A38A8D6660004664A388C0A6700045E70024EB90003F44A16389BC842389BC811C38C0A600004464EB900042122363C19C0C6F88BD4E08BE08BE68B0C83000000FF6304163C00FF11C3925A3D788C86FFFC3038A8B4906EFFFCB0790001D2906514806A
[06:34:21:619] RX: 6C F0 10 60 CC 00 94 AB
[06:34:21:620] Ignoring message: UnexpectedResponse
[06:34:22:900] Timeout during receive.

The range in process ...

[06:34:14:882] Processing range 040000-05FFFF
[06:34:14:923] Erasing.
[06:34:14:964] TX: STPX H:6C10F0, R:1, D:3D05040000
[06:34:15:922] RX: 6C F0 10 7D 05 00 00
[06:34:15:923] Writing...

[Gampy]

Whew, glad you got it to recover ...

Corvette info (year, engine, trans)??

You need no stackers, spliters ...

Sounds like you need a good tuner, I'm not it!

Obviously the time of year makes responses from those that know a bit slow, hang in there.

[antus]

Yeah, compare the tunes, look for differences, youll need to copy one or more of the settings over. Dont change the OSID without a reason because of the risk re-writing the boot sector.

[NSFW]

This message is what the flash kernel sends after the app requests a reboot:

RX: 6C F0 10 60 CC 00 94 AB

However the app clearly didn't send a reboot request.

So I'm guessing that the write request got corrupted and the PCM received it in two chunks. The 2nd chunk, containing payload data, was misinterpreted as a reboot request.

Right now the app only looks as the mode byte to decide whether a message is a reboot request, so there's a 1-in-256 chance of a garbage message causing a reboot... which is kind of dumb in retrospect. It really should check the first three bytes as well (6C, 10, F0) and that would made the odds about 1 in 4.29 billion. Much better.

It'll be a couple days before I have time to make the change and re-test, but this is definitely worth doing.

[antus]

That sounds unlikely, because a split packet wont have the right start of frame SOF timing and the VPW transceiver in the PCM or the hard or software interface will reject it. If that is what happened 2 requests would have had to have gone to the interface for it to initiate two packets. Unless its a bug in the interface firmware, but that seems very unlikely as it'd have to be the perfect storm to a) happen at all and b) happen rarely enough its not been found or reported yet.

[NSFW]

In that case I'll revise my guess to another module on the VPW bus sending a message with mode byte of 0x20. The result would be the same, and the fix would also be the same.

[Tazzi]

In that case I'll revise my guess to another module on the VPW bus sending a message with mode byte of 0x20. The result would be the same, and the fix would also be the same.

I think you might still be onto something with your last thought NSFW.

What does the kernel default to if it doesnt understand the frame received?? Could that be the problem?

[antus]

The Mode 20 is actually a return to normal speed message, so its possible that another module did miss a 3F test tool present, switch back to 1x and send the mode 20. The PCM should switch back to 1x, which it does on a reboot, but perhaps we should not reboot the kernel on a mode 20, and instead program the vpw chip recever to 1x where it could wait for another flash attempt from hammerer. It'd mean we need to add something else for reboot pcm, and we'd need to handle the speed change logic in the kernel instead of leaving it to the OS for 1x and 4x.

Of course if the bus was in 1x then this doesnt explain why another module would have sent that message but its food for thought.

[NSFW]

I think you might still be onto something with your last thought NSFW.

What does the kernel default to if it doesnt understand the frame received?? Could that be the problem?

It basically ignores anything it doesn't understand, but it will send a response message in some cases, to help with troubleshooting.

If it gets a message that starts with 6C 10 F0 3D and an unknown sub-mode it will send a tool-present message with 3D and the unknown submode.

If it gets a message that starts with 6C 10 F0 and any other mode, it will send a tool-present message with AA and the unknown mode and submode.

If it gets a message start starts with anything other than 6C 10 F0, it will just silently ignore it. Unless of course that message has a mode byte of 20... because the code that checks for reboot messages was mistakenly put before the code that checks for 6C 10 F0.