pcmhacking.net

I had issues with something similar previously, trying to perform commands before pins had completely initiated. So maybe same thing for the P12. Worth a shot regardless!

Did we get the success message back from the erase, or a fail? It only takes under about 10 cpu instructions to trigger the erase, then the erase is run in hardware on the flash chip. so I can see that we could have time to trigger the erase process then the slave interferes before the erase is complete yet it still completes successfully in the chip. Having said that the factory tool failed too I am not assuming the slave is the problem. Just a possibility as we continue to test.

Tazzi wrote:I had issues with something similar previously, trying to perform commands before pins had completely initiated. So maybe same thing for the P12. Worth a shot regardless!

Yup it is, it's in the queue ...

antus wrote:Did we get the success message back from the erase, or a fail? It only takes under about 10 cpu instructions to trigger the erase, then the erase is run in hardware on the flash chip. so I can see that we could have time to trigger the erase process then the slave interferes before the erase is complete yet it still completes successfully in the chip. Having said that the factory tool failed too I am not assuming the slave is the problem. Just a possibility as we continue to test.

The erase process reads the erased to verify it's not the same ...
Yes, we get a success from the erase.

Gampy wrote:

Tazzi wrote:I had issues with something similar previously, trying to perform commands before pins had completely initiated. So maybe same thing for the P12. Worth a shot regardless!

Yup it is, it's in the queue ...

Impatiently taps foot....

Yea, me too.

Unfortunately I seem to have lost the ability to Id the flash ... Doesn't make sense, same exact code!
If I cannot Id the flash, I don't expect anything else to work.

Obviously I'm missing something, somewhere ...

It was working perfect until I hardwired it to ensure it was not influencing the flash write failure.

Gampy wrote:Yea, me too.

Unfortunately I seem to have lost the ability to Id the flash ... Doesn't make sense, same exact code!
If I cannot Id the flash, I don't expect anything else to work.

Obviously I'm missing something, somewhere ...

It was working perfect until I hardwired it to ensure it was not influencing the flash write failure.

What have you changed? Have you kept a log of changes?

For instance, I lose the ability to ID the P01/P59 if removing the "HARDWARE_IO |= 0x0001;" when unlocking. Where HARDWARE_IO is 0xFFFFE2FA.
So whatever the equivalent was in P12 was.

Yea, with my oxygen deprived brain, I definitely keep records as well as the code!
My build system Zips up the code ...

diff doesn't disclose the issue ... I don't know what's up yet!

Pretty sure I found my mistake ... Ultimately diff did disclose it, I missed it in the diff.

Test is out with Tazzi's recommended delay, I used 4 nop's.

Well, the delay didn't help ...

There is another test out.

Gampy,

Can you copy in here exactly what you are changing/setting before you attempt to use the amd write command?
Just so we can verify if its missing anything in comparison to the gm kernel?