PCM Hammer P12 development

[Gampy]

Tech2 did the first one, I did the second one ...

[darkman5001]

When and what took down the PCM? Also wondering is there an older version of tech2win that will use the pcmcia card files for flashing?

The first P12 was taken down by a corrupt flash from the tech2 which the tech2 received the flash from TIS2000 running on a virtual machine. Something must have went wrong with the virtual machine. I used that 1st P12 to dismantle for inspection and research into it's circuity and chips. Second P12 happened during some testing. I installed TIS2000 to a Toughbook, and was able to recover this second P12 with the Tech2.

The PCMCIA card bins are available to flash to the cards for the Tech2 but can also be used with tech2win, however it is my understanding that programming can not be done with tech2win, only a physical tech2.

[Gampy]

Is this a fair statement ...

With the P01/P59, it's upload a kernel, it takes completely over, obeys commands sent to it and responds accordingly ... When done the unit is Rebooted!

As we know so far with the P12, it's upload the tools and instructions how to handle the accompanying data, then leaves it to it's own devices!
Meaning it does the update, all we do is provide the tools, instructions and data to do so.

[kur4o]

Is this a fair statement ...

With the P01/P59, it's upload a kernel, it takes completely over, obeys commands sent to it and responds accordingly ... When done the unit is Rebooted!

As we know so far with the P12, it's upload the tools and instructions how to handle the accompanying data, then leaves it to it's own devices!
Meaning it does the update, all we do is provide the tools, instructions and data to do so.

If we are talking for factory reflash, that is correct.

If we use custom made tools for flashing, it doesn`t matter.
With gm flash the boot block 0-4000 stay constant and never updates during flash. It may be good but maybe not that good. In case you update a OS that have different application 2.4l vs later 4.2, hardware is the same, boot block differs. No way to update OS without boot block. Maybe we can start making library of p12 stock files.

[darkman5001]

I can say this, after I am on the computer in SPS, depending on what update the stand-alone PC software is at, there are a bunch of calibrations updates since previous updates, or I have the option to update these. In my experience with the software, I can also update the operating system as well. I know that different operating system versions can be used on a particular PCM. Actually I can reprogram any programmable module in the whole vehicle with this software. I can even reprogram a factory radio to work in Europe. These calibration options are available for each module as well as each module having its own operating system. Example: The P10 I am working on right now had 3 operating systems. There was 12577956 with a description "Operating System". Then the second is 12579357 with a description "New software to improve generic scan tool operation." Then the last and most current version is 12588012 with the description "New software to improve idle stability."

[antus]

@kur4o you are right. This is different from the P01 an P59 in how the factory do it. I guess they had their reasons but it seems more complicated and more error prone compared to how the earlier PCMs do it. I dont see any reason why we should try and emulate the P12 factory method. It'll be simpler and more reliable for us to port the P01/P59 code to the P12. Perhaps we need to add something to silence the slave cpu, but we dont need to make something overly complex like the factory tools.

[Tazzi]

Ok, do we know if the kernel is crashing when it’s trying to write? Or just comes back saying failed?

If the p12 kernel is able to go in an infinite loop without crashing… and it was also able to erase a section.. I would not think the slave Cpu is a problem with it all.

The fact it erased.. shows the correct commands and addressing was performed.
If the slave was interfering then I would expect it would get part way through writing before crashing or failing, but it hasn’t even attempted to write a single byte successfully.

Does there need to be a pause after unlocking, before writing?

[Gampy]

Yes kur4o, I was talking about factory technique ...

I personally have never even thought about trying to emulate the factory technique ... I have from the very first success, been on the same road as the P01/P59 technique!
I believe it is the way to go ... Take control, do it yourself!
And I believe it can be done this way.

If the p12 kernel is able to go in an infinite loop without crashing… and it was also able to erase a section.. I would not think the slave Cpu is a problem with it all.

Sounds like an echo, I have been screaming the same thing!
Why would they allow erase, but not write ... they wouldn't. I think we still have a bit flipped wrong!
The big question is: What bit!

If the slave was interfering then I would expect it would get part way through writing before crashing or failing, but it hasn’t even attempted to write a single byte successfully.

I completely agree!
I do keep having reads done purposely to ensure it's cleanly erased and not a partial write.

It's always clean ...

Does there need to be a pause after unlocking, before writing?

By the nature of the design there is a fair delay between the two already, I could add more just to verify very easily.
The PC sends Erase, when the PC receives Success, it then sends the Write, so there is a bit of a delay just in the technique.

The kernel code writes a word, then tries to read that word back and compare it to what was written, that is where it fails ...

Code: Select all

uint8_t Amd_WriteToFlash(unsigned int payloadLengthInBytes, unsigned int startAddress, unsigned char *payloadBytes, int testWrite)
{
	char errorCode = 0;
	unsigned short status;

	unsigned short* payloadArray = (unsigned short*) payloadBytes;
	unsigned short* flashArray = (unsigned short*) startAddress;

	for (unsigned index = 0; index < payloadLengthInBytes / 2; index++)
	{
		unsigned short volatile  *address = &(flashArray[index]);
		unsigned short value = payloadArray[index];

		if (!testWrite)
		{
+#if defined P12
+			SIM_CSOR0 |= 0x4;
+#else
			SIM_CSOR0 = 0x7060;
+#endif
			COMMAND_REG_AAA = 0xAAAA;
			COMMAND_REG_554 = 0x5555;
			COMMAND_REG_AAA = 0xA0A0;
			*address = value; // <-------------------------------------- Writes the word
		}

		char success = 0;
		for(int iterations = 0; iterations < 0x1000; iterations++)
		{
			ScratchWatchdog();

			uint16_t read = testWrite ? value : *address; // <------------ Reads the written word

			if (read == value) // <--------------------------------------- Compares the two words
			{
				success = 1;
				break;
			}
		}

		if (!success)
		{
			// Return flash to normal mode and return the error code.
			errorCode = 0xAA; // <--------------------------------------- Returned ERROR CODE!

			if (!testWrite)
			{
				*address = 0xF0F0;
				*address = 0xF0F0;
+#if defined P12
+				SIM_CSOR0 = 0xA332;
+#else
				SIM_CSOR0 = 0x1060;
+#endif
			}

			return errorCode;
		}
	}

	if (!testWrite)
	{
		// Return flash to normal mode.
		unsigned short* address = (unsigned short*)startAddress;
		*address = 0xF0F0;
		*address = 0xF0F0;
+#if defined P12
+	SIM_CSOR0 = 0xA332;
+#else
	SIM_CSOR0 = 0x1060;
+#endif
	}

	return 0;
}

The kernel is NOT crashing ... It is still alive after the failed write!

BTW, knowing we can recover is a HUGE relief to me ... So darkman5001 Thank you very much for getting that working!

[Tazzi]

Where it does this:
SIM_CSOR0 |= 0x4;

If this is related to control those pins, there will need to be a delay for it to take effect.

[Gampy]

I can definitely try that ...

Obviously the others haven't needed it, and erase works, it's the same way.