Halting Kernel freezes PCM w/J2534 VCI only

[Gampy]

Hi all,

Working with Antus's code here: viewtopic.php?f=42&t=6604&start=10#p96929 and find a weird issue that I cannot wrap my pea brain around, thought I would ask if anyone has seen this before, or knows whats up ...

Halting the kernel (6C 10 F0 20) freezes the PCM only when using a J2534 VCI. Tested with a GM MDI Clone and Genuine Bosch Mastertech II.
And I do mean FREEZES, it's hard, disconnect battery hard!

However, it works perfect with non J2534 VCI's, for example, a SparkFun, Allpro and a Generic ELM all work perfect.

Here is the real odd part ... If I change the command to something other than 20, for example changing it to 30, it works perfect even with a J2534 VCI.
And while the kernel is changed to use other then 20, sending 20 still freezes the PCM!

At this point the PCM/kernel has no clue what 20 is ... It should just ignore it and continue.

Any ideas ??

Thanks
-Enjoy

[kur4o Profile]

Just random ideas.

Watchdog is disabled and pcm goes into infinite loop. pcm DataLinkController errors and stop working.
Pcm crashes and watchdog don`t reboot it.

It is very hard to crash the pcm and it doen`t recover. It needs watchdog reset in infinite loop.

Is this x4 and x1 mode related. It may leave the pcm in x4 mode while vci returns to x1 mode. Need to trace in disassembly what goes in custom code with mode 20. Usually mode 20 resets some stuff and leave watchdog reboot the code. It is maybe related to how pcm exits flash routine.

[antus]

It sounds like its crashing the DLC. If its the bitstream not the kernel I'd put a scope on the wire and look for minor electrical differences in the actual VPW signal. VPW isnt the best electrical standard, for example NSFW was unable to get his allpro to talk to his PCM, unless he hung a double adapter off the side of the cable connection. Nothing on it, it just made enough of a difference electrically, probably timing changes from the capacitance, that it then worked.

It could also be similar to the as yet unexplainable crash that only happens on my p04 pcm with pcmhammer with a particular bin, and always at the same place due to the data.

The fix might be guess work - changing the timing just a fraction somewhere while driving the the DLC.

I am glad someone is using that code

[MudDuck514 Profile]

Have you modified THAT code to run on something other than an AVT cable?
If NOT, could that be your problem.

Just a thought.

Mike

[Gampy]

Hi all,

It appears that simply sending '6c 10 f0 20' causes the issue, if one adds additional bytes it seems to solve the issue, example: '6c 10 f0 20 54 32 10'.
I have not changed PCM Hammer's halt statement, however I have done in the neighborhood of 200 reads within the last couple days using this assembly kernel and it has not once locked up/crashed the PCM!

Anyhow, as stated in the first post I have been thinning my hair with Antus's "test.asm", here are some results.

I am no assembly programmer, I just hack my way through errors by trial, it's a slow tedious process ... But the results are enticing!

P01

PcmHammer_debugLog_20230320@013101.txt

(1.54 MiB) Downloaded 38 times

P04 AMD, no Intel P04 to test.

PcmHammer_debugLog_20230320@013515.txt

(1.54 MiB) Downloaded 35 times

P10

PcmHammer_debugLog_20230320@013941.txt

(1.54 MiB) Downloaded 34 times

P12

PcmHammer_debugLog_20230320@014535.txt

(3.08 MiB) Downloaded 33 times

P12b

PcmHammer_debugLog_20230320@015616.txt

(6.15 MiB) Downloaded 32 times

P59 Intel

PcmHammer_debugLog_20230320@020216.txt

(3.08 MiB) Downloaded 32 times

P59 AMD

PcmHammer_debugLog_20230320@020755.txt

(3.08 MiB) Downloaded 32 times

E54 (older 2002)

PcmHammer_debugLog_20230320@021638.txt

(1.54 MiB) Downloaded 33 times

Now that it's stable, I will work on writes, CRC is going to be tough, likely tougher then I, I do not know how to calculate a CRC in the first place, plus I am an absolute math dummy, but I'll look at a disassembly of PCMHammers kernel and see if I can muddle my way through.
Regardless it's not going to happen overnight, or possibly even before I run out of time, but I'll plug along as long as I can!

Sure wish I knew an assembly coder, I would entice them with green hard cash ...

If anyone knows of any CRC code in assembly could you please point me to it, architecture does not matter, however m68k would be nice.

-Enjoy

[antus]

Nice work!

For the CRC the C version is here: https://github.com/LegacyNsfw/PcmHacks/ ... nels/crc.c

Being that its not going to be so timing critical as the parts of the code that drive the hardware, you might be able to compile it with heavy optimisation and then decompile it to get a tight asm example which you could also compare to the source to try and follow the code.

You could run a compiled version with any level of optimisation, and any asm code you write in http://www.easy68k.com/ as you wont need anything hardware specific. This will make your development cycles quicker and allow you to confirm its stable and functionally equivalent before you attempt to put it in in the kernel.

The biggest gotcha I hit with 68k was that certain operations dont clear the register, only update part of it. So you can write code and believe a register will be empty after a certain opcode, only to find that its crashing because its not. An emulator should make this visible in a way you wont be able to see on the pcm.

[In-Tech Profile]

Hiya,
I've only done assy on 8 and a small amount of 16bit, never any '332 stuff. I would bet it still trickles 8 bit stuff, just a guess though. It will take a bit of work but I can alter my assembler with new opcodes

[Gampy]

For the CRC the C version is here: https://github.com/LegacyNsfw/PcmHacks/ ... nels/crc.c

And the original works of that CRC code is here: Barr Group

-Enjoy

[In-Tech Profile]

For the CRC the C version is here: https://github.com/LegacyNsfw/PcmHacks/ ... nels/crc.c

And the original works of that CRC code is here: Barr Group

-Enjoy

Hiya, and yes, another complication of CRC because of a new complicated version of assemblies, focking ridiculous. Anyhoosit,