[dil6222]

Updated from 5,5,1 to 5,5,5. All passed without problems, authorization is all green ...
But with the verification of the problem. I tried on mc9s12xeq384mag 3M25J when erasing it, I specify the entire region (corresponding to d-flash = 0) - the process passes without errors, then I write it to the industry with a few verification errors (errors every time) and when reading the Partition corruption error, I suggest manually selecting partition.
The processor is in the FRM block, 4 points are connected in-circuit. Now I can not understand, or the processor went out of order, or in xprog's case .

This is my exact experience with xprog box 5.5.5. FRM3 MCU signature ID is correctly recognized only 1 out of 10 times, or less.
Does not read/write correctly. There are hundreds of verify errors.

I downgraded to 5.5.1 (bricked 2 atmega64 in the process), and same result.

I upgraded to 5.7.4, and when verifying certificates, it eventually killed my last atmega64 as well. Atmega64 are only $4 USD each, but this clone tool is a nightmare.



I give up. What do you all use for FRM3?

Hello enabled your atmegas are not fried just configured incorrectly please check my thread
here https://cartechnology.co.uk/showthread.php?tid=39496 you will be able to.unlock your atmega and reprogram

I saw that wonderful thread, and have bookmarked it earlier today.
I need to find an oscillator somewhere, and I will recover them. I can try to recover 3 of them.


But I am afraid that the Xprog box still will not work correctly with MC9S12XEQ384.

V5.5.5 was hopeless, and so was the 5.5.1.




MCU ID was different 9 out of 10 times.



I am not sure if the 5.7.4 method found online even gets past the certificate verification.

 
Hello it won,t make any difference with reading the chip you want just stops you buying new atmega every time you program     also can use upa for clock signal if you have it 

Also you reading that chip onboard or offboard ?