MSS60 Research

[dpaul]

Sigh, I guess my basement is not very hospitable to old electronics. My old CPU/mobo combos won't post.

There's a few PEMicro Cyclone Maxes on eBay for not crazy money. And with the Cyclones, it sounds like the programming software is free (you can download it right from PEMicro's website). Maybe I should just buy one of those.

What concerns me t hough is the user manual doesn't actually mention anything about clearing the censor for the MPC5xx / 8xx.

Nothing in the manual but there is a routine in the "Algorithms for MPC5xx/8xx, internal flash" download for enabling the shadow memory where the UC3F control block is located. Even a warning about losing the contents of the internal flash.

Seems like it should be able to change the UC3FMCR register. But at $200, it would be greatly disappointing if it didn't work.

[terra]

Sigh, I guess my basement is not very hospitable to old electronics. My old CPU/mobo combos won't post.

There's a few PEMicro Cyclone Maxes on eBay for not crazy money. And with the Cyclones, it sounds like the programming software is free (you can download it right from PEMicro's website). Maybe I should just buy one of those.

What concerns me t hough is the user manual doesn't actually mention anything about clearing the censor for the MPC5xx / 8xx.

[dpaul]

I got an older version of OCDCommander via archive.org and got a little farther. The program will now actually be able to tell if the CPU is on / off, and it will read at least a few registers correctly before returning junk data. I wonder if it's something as simple as the clock speed being too damn high.

Try loading the ediabslib dll itself as a resource.

thanks - I did get the binary - all is good. Would think it should compile tho.

[terra]

That is frustrating - could be a hardware problem with the wiggler or a problem with the virtual machine - I guess finding/setting up an old computer is the only way to know.

Can I ask an unrelated question? I promise I will not bother you further with random coding questions. I've been unable to compile EdiabasLib. I downloaded it today and am using Visual Studio 2019. Using the make file EdiabasLib.sln, I am getting the following errors:





EDIT: Nevermind. I'll get the binaries.

I got an older version of OCDCommander via archive.org and got a little farther. The program will now actually be able to tell if the CPU is on / off, and it will read at least a few registers correctly before returning junk data. I wonder if it's something as simple as the clock speed being too damn high.

Try loading the ediabslib dll itself as a resource.

[dpaul]

That is frustrating - could be a hardware problem with the wiggler or a problem with the virtual machine - I guess finding/setting up an old computer is the only way to know.

Can I ask an unrelated question? I promise I will not bother you further with random coding questions. I've been unable to compile EdiabasLib. I downloaded it today and am using Visual Studio 2019. Using the make file EdiabasLib.sln, I am getting the following errors:





EDIT: Nevermind. I'll get the binaries.

[terra]

So I got my wiggler in, but I'm not sure it's working right. Setup a new XP virtual machine and ran macraigor's OCD Commander to see if I could get some basic info out of the CPU - http://www.macraigor.com/ocd_cmd.htm

Getting pretty much junk data though. It works enough that it can tell when the device isn't connected to the parallel port, but otherwise I get junk data out of it whether or not I'm hooked up to the BDM header. Messing with the ECP/EPP settings within the VM bios didn't make a difference. Not sure if there's anything I could mess with at the host side to help.

I'm half tempted to pull one of my old motherboards/processors with a native parallel port out of storage.. but that sounds painful frankly.

[terra]

Wrong thread?

Yep, fixed now.

[heinzboehmer]

New version.

Changes:
Moved the RSA bypass to the "Advanced" menu, and added a slow and fast version. Slow is probably technically safer, but IMO the risk with fast is negligible if you're using a good cable.
I now verify the binary being flashed for an RSA bypass is a stock file and matches the program version you are currently on. If those conditions are not met, the program will refuse to let you go do the RSA bypass.
Now before tune and program writes, I check if the tune / program is stock and whether or not you have an RSA bypass. If the tune (MSS60 only) or program (both) are not stock and you don't have an RSA bypass, you'll get a warning saying the flash might fail. But you won't be forced to stop the flash in case you have an RSA bypass that I can't easily detect.
I put my money where my mouth is and did several flashes on my (currently) locked MSS60. No issues whatsoever so far.

Same link as before will work to download the latest version (someone let me know if it does not). I think I will be releasing shortly, after which point the latest version will be hosted here on the first post.

Wrong thread?

[terra]

You're right and NXP isn't making anything easy. Incredibly annoying that the actual model number is only put on the box - the number on the device itself is something meaningful but not listed in the documentation anywhere. There are a lot of CWH-UTP-PPCC-HEs (900-75115, PQII/III) around but PPCD (900-75094, maybe) is hard to find.

Yep, exactly what I found as well. You can still buy it direct from NXP... but at $500, what's the point? https://www.nxp.com/part/CWH-UTP-PPCD-HE#/

[dpaul]

I thought about the USB TAP, but it seems like they sold a few different versions that are compatible with different processors. It might just be a matter of opening it up and using the right cable unlike the PEMicro, but I didn't want to take that risk. The one for the MPC5xx/8xx is apparently the CWH-UTP-PPCD-HE

https://community.nxp.com/thread/386294

You're right and NXP isn't making anything easy. Incredibly annoying that the actual model number is only put on the box - the number on the device itself is something meaningful but not listed in the documentation anywhere. There are a lot of CWH-UTP-PPCC-HEs (900-75115, PQII/III) around but PPCD (900-75094, maybe) is hard to find.

[terra]

Good score on the Wiggler!

If that doesn't work, the Freescale USB TAP should - a little more money but not much. If my MSS65 wasn't dead, I'd get a USB TAP and see if I could censor and uncensor the DME. Can't find a cheap enough MSS65 tho and almost can't believe you found an MSS60 for $65. Another good score.

https://www.ebay.com/itm/Freescale-CodeWarrior-USB-TAP-900-75115-Rev-D-JTAG/373019425267?hash=item56d9b0b9f3:g:tvsAAOSwIlBek5lw

Plus it's USB and it should be compatible with the current Code Warrior for MPC5xx 8.7

I thought about the USB TAP, but it seems like they sold a few different versions that are compatible with different processors. It might just be a matter of opening it up and using the right cable unlike the PEMicro, but I didn't want to take that risk. The one for the MPC5xx/8xx is apparently the CWH-UTP-PPCD-HE

https://community.nxp.com/thread/386294

[dpaul]

Good score on the Wiggler!

If that doesn't work, the Freescale USB TAP should - a little more money but not much. If my MSS65 wasn't dead, I'd get a USB TAP and see if I could censor and uncensor the DME. Can't find a cheap enough MSS65 tho and almost can't believe you found an MSS60 for $65. Another good score.

https://www.ebay.com/itm/Freescale-CodeWarrior-USB-TAP-900-75115-Rev-D-JTAG/373019425267?hash=item56d9b0b9f3:g:tvsAAOSwIlBek5lw

Plus it's USB and it should be compatible with the current Code Warrior for MPC5xx 8.7

[terra]

This from a Freescale customer errata sheet:

CDR_AR_1057 Customer Erratum C3FARRAY_A.512KCDR3_03_0
UC3F: censorship can be overridden in certain cases
DESCRIPTION: It is possible that Censorship can be overwritten under certain conditions. These conditions will not be documented.
WORKAROUND: Program RCW[IWS] to 0 when censorship is enabled. This will provide an additional layer of protection by preventing access to the array except when executing from the array

So there is an undocumented method of clearing censorship without losing the contents of the array! Not that this is so important at this point as the SK is readily obtained. But still....


EDIT: something to be concerned about

CDR_AR_1011 Customer Erratum C3FBIU.CDR3UBUS_02_0
UC3FBIU: CENSOR bits cannot be cleared even if UC3FCFIG[IWS] is 0
DESCRIPTION: The UC3FCFIG[IWS] bit may get cleared inadvertently at the deassertion of system reset. This means that only a write to a valid array location will serve as the erase interlock write for clearing CENSOR bits. If the array is already censored then it is not possible to clear the CENSOR bits at all.
WORKAROUND: Do not censor the array (CENSOR=11) before production, as it may not be possible to clear the CENSOR bits if the array is censored.

Yeah that second one concerns me. I hope that that erratum was fixed by the time the MSS60 went into production

In any case, I bought one of these: https://www.ebay.com/itm/274331062216

Older versions of codewarrior seem to have support for a wiggler interface, and some way or another I can probably get it to work with GDB. At ~$32 with shipping, it's not a tremendous loss of money if I can't do anything with it.

The one thing we don't have is the actual shadow memory, but if the MSS65 is anything to by, there isn't anything notable in here. First 4 bytes are set to 00, and the rest is blank.

Edit: This should be the errata sheet that applies to the MPC563 in our DMEs (revision B): https://www.nxp.com/docs/en/errata/MPC563BCE.pdf

That second bug isn't noted.

Even newer variants could possibly have revision C, which seems to have fixed the ability to read contents without clearing censorship... but like you said, big deal.

[dpaul]

This from a Freescale customer errata sheet:

CDR_AR_1057 Customer Erratum C3FARRAY_A.512KCDR3_03_0
UC3F: censorship can be overridden in certain cases
DESCRIPTION: It is possible that Censorship can be overwritten under certain conditions. These conditions will not be documented.
WORKAROUND: Program RCW[IWS] to 0 when censorship is enabled. This will provide an additional layer of protection by preventing access to the array except when executing from the array

So there is an undocumented method of clearing censorship without losing the contents of the array! Not that this is so important at this point as the SK is readily obtained. But still....


EDIT: something to be concerned about

CDR_AR_1011 Customer Erratum C3FBIU.CDR3UBUS_02_0
UC3FBIU: CENSOR bits cannot be cleared even if UC3FCFIG[IWS] is 0
DESCRIPTION: The UC3FCFIG[IWS] bit may get cleared inadvertently at the deassertion of system reset. This means that only a write to a valid array location will serve as the erase interlock write for clearing CENSOR bits. If the array is already censored then it is not possible to clear the CENSOR bits at all.
WORKAROUND: Do not censor the array (CENSOR=11) before production, as it may not be possible to clear the CENSOR bits if the array is censored.

[terra]

Yeah seems like there's a lot of misinformation about that. Typical industry guys obfuscating information I guess.

It seems to be only early 08 models (really ~2007 builds) that are unlocked. There's also all sorts of claims that BMW introduced the lock through an update and the lock could be cleared by flashing an older update. None of that appears to be true. If the DME was unlocked from the factory it stays unlocked, if the DME was locked from the factory, it stays locked (until we figure out how to send that clear censorship code to it anyway).