PCM Hammer P12 development

[antus]

a2 00 sounds like erase succeeded, reprogram new data failed. the cal segment or os segment will be blank, like the first pcm. good progress, just gotta get it recovering and programming now.

having said that perhaps the wait loop for erase didnt detect erase successful and it failed there even though erase completed.

[Gampy]

Failing a sector check does not mean a successful erase ...

Has something happened, heck yea, I obviously didn't get it right and soft bricked a volunteers unit!

So, we cannot get PCMHammer to load a kernel with these pesky A2 00 pings interfering, so I adjusted PCMHammer accordingly.

What I did was rearrange the connection sequence order to Recovery mode check, Live Kernel check and then Normal ... So far so slick, we'll see if we can get a kernel on board now, I just sent a test.

We'll see if we can recover it, we really can't do it more harm.

[Tazzi]

Reading it back out would probably be the next best thing to confirm where its erased or what its done exactly.

[darkman5001]

Gampy, check your inbox. I have an idea...

[kur4o]

This pcm should be fully recoverable. The boot block should handle it.

You need to send mode 27 only to check connection. It will response with mode 0000 as seed, means you can communicate and go straight to code upload, no mode 34 needed.
Timing is critical so you need good interface to count responses and inject at the right time. Usually you get 5-6 messages than slight pause, since pcm resets. SOme idle log will help too.

[darkman5001]

I changed the kernel file in PCM Hammer to use an earlier test kernel that Gampy made that was the last version used and getting good PCM responses even though soft bricked. Now I am getting those responses back again. What I want to do is force PCM Hammer to write the flash to the PCM. Currently the built in safeties in PCM Hammer are saying that the write can not happen because it will damage the PCM. We need to turn that safety off.

[darkman5001]

Here are three logs and all I did was use Gampy's last known good test kernel to get good responses back. Pay close attention to the time of the log so you are seeing in the correct order.

[antus]

Can you please remind us what happened to the first pcm? That ended up soft bricked like this, but with a 3rd party tool? If thats the case, do you know there is no issue with the power supply on your bench? Perhaps pcmhammer is fine and the failure is something external to both tools.

[darkman5001]

Can you please remind us what happened to the first pcm? That ended up soft bricked like this, but with a 3rd party tool? If thats the case, do you know there is no issue with the power supply on your bench? Perhaps pcmhammer is fine and the failure is something external to both tools.

The first PCM got soft bricked while trying to program with a tech 2. I am still unaware what caused the bad flash from the tech2. There are no problems with the power supply at all.

[kur4o]

log2 and log3 clearly shows you can upload and execute to ram in that recovery state.
Why not try to read the pcm, so we can see what went wrong at the first place.