PCM Hammer P12 development

[kur4o]

Gm flash routine is executed on request, never takes full control. Pcm have full control on communication loop.
You sent first block. Pcm code receive and stores it to ram, jump to uploaded code, erase, than program. Than return to pcm code. upload next block and so on.

[darkman5001]

darkman5001,

you are trying to flash pcm with corrupted file. Last part of bin is FFs while there is some data in non corrupted file. The tech2 exits when Os is done, but checks that is good are not passed and it fails when you start caldata write.

It is either corrupted file are loaded to tech2 or the tech2 bugs out for some reason.

You can try using tech2 as passthrough and flash from tis2000 utility, or try reuploading flash files to tech2.

I used a virtual machine with TIS2000 and the tech2, but I am starting to wonder if something is wrong with the files on the virtual machine. I am going to install the TIS2000 software on an actual computer and see if I have better results.

[Gampy]

It's not a multi threaded os, what ever code is executing is in control ...

[kur4o]

I used a virtual machine with TIS2000 and the tech2, but I am starting to wonder if something is wrong with the files on the virtual machine. I am going to install the TIS2000 software on an actual computer and see if I have better results.

You need very solid connection between PC and T2. Real COM port or high quality converter. I doubt the files can get screwed inside a database.
You can also use T2 as a pass through j-device or mdi and flash from tis2000 program.

[kur4o]

It's not a multi threaded os, what ever code is executing is in control ...

I think we are on different pages.

Take it a like that.

Communication is executed from ROM, program and erase routines are executed from RAM. Slave routine is at ffff6000, maybe that is a shared memory with slave cpu.

[Gampy]

Take it a like that.

Communication is executed from ROM, program and erase routines are executed from RAM. Slave routine is at ffff6000, maybe that is a shared memory with slave cpu.

We have control over communication, we have control over flash chip, we work directly with the hardware, well as directly as one can get through the SIM.
Slave, I don't know about, I suspect it is just an ignorant fly by wire slave, I cannot imagine it is a babysitter ... I could be wrong.

The one thing I know for sure ... I do not have the time into the disassembles that you do!

[Tazzi]

Yeah I understand what hes saying.

GM's kernel gets uploaded to RAM (FF2000), but it is not executed.
The code uploaded is used by the operating system to update the flash.

Right at the top of GMs kernel, (from FF2020), you can see all the main calls for flash commands for AMD processors.
At FF2096, we see the FFFA7E register being changed, and below what has the FA7E and also FA7C.

[antus]

I agree we need to get a good confirmed write with factory tools as a starting point. We may be chasing our tails and we may have a working solution already. We got the same result as the tech2 and that should be a working solution. Whatever broke the tech2 flash might be external and breaking our possibly otherwise working tests too.

Ive pulled the slave kernel out of the tech2 log. I havnt looked in to what its doing yet, but it does look like its doing something. Something required? Dont know....

One question for Kur4o, are you sure this code is executing on the slave? Or could it be called by code on the main CPU?

[kur4o]

I think code at ffff6000 writes slave for sure, Main processor likely execute it, but not confirmed yet how it is done.

The T2 flash fails on checksum error. After OS write is completed it checks for integrity. And last messages contains FFs instead of data. so something with T2 parsing data or the files that are loaded in T2 are corrupted.

[antus]

I think the fail fail on checksum error is more than a minor fault. Here is the read from a good pcm with pcmhammer compared to the read after the bad tech2 flash read by lifting the chip. The whole cal segment 20000-40000 is FF. So Its a genuine flash write fail to the whole segment after a successful erase, not just a bad sum and minor data error. The same as the result as pcmhammer got.