MSS60 Research

[terra]

Can't find much in the way of documentation for the ESL/Windriver products.

And it's not clear that BDI2000 supports MPC5xx although it looks like BDI3000 does However, Abatron is out of business, their hardware probably needs the Abatron software, and those devices are not exactly cheap on Ebay.
Sigh.....

Maybe it's worth trying to achieve a higher level of authorization for full read/write access via OBDII, even if it hasn't been that useful for you with other DMEs? Either bypassing authentication or factoring the public keys, which as you've pointed out, is computationally feasible.
.

So I started going down a rabbit hole of archived internet pages and now-dead projects, and this seems interesting:
https://web.archive.org/web/20110914...ftware/mpcbdm/

That project is built for the MPC8xx, but given the 5xx uses the same protocol, that might be fine. Might just have to edit the source a bit to look for the 5xx PVRs and whatnot.
And they have this diagram for a parallel port interface, which I think I could build without too much difficulty:
https://web.archive.org/web/20051025...pcbdm/VDB2.gif

Might be sufficient to run that uncensor s19 file..

[dpaul]

So I started going down a rabbit hole of archived internet pages and now-dead projects, and this seems interesting:
https://web.archive.org/web/20110914...ftware/mpcbdm/

That project is built for the MPC8xx, but given the 5xx uses the same protocol, that might be fine. Might just have to edit the source a bit to look for the 5xx PVRs and whatnot.
And they have this diagram for a parallel port interface, which I think I could build without too much difficulty:
https://web.archive.org/web/20051025...pcbdm/VDB2.gif

Might be sufficient to run that uncensor s19 file..

That was a deep dive!

I think the MPC5xx is a direct descendent of the MPC8xx so this approach seems promising. The hardware seems pretty simple. So it probably comes down to the software these guys wrote. I wish I could help but I don't have a pile of components to draw on for the hardware and have neither a linux installation nor much experience so getting set up would be a big learning project..

I hope you are able to go forward with this!

[terra]

Yeah I can't say I have a huge amount of experience there nor do I have the hardware on hand (unless they are relatively common things that can be salvaged from other ancient electronics).

Last time I messed with anything similar was for the parallel port BDM interface for the MSS54. Which looks similar on the surface, but seems to be fairly different. For that, I ended up getting a PCI-expresses parallel port card and then using Windows 95 in a virtual machine to do what I needed to do. I imagine I could do a similar thing with Linux... but setting up Linux crap in 2002 was even more painful than the modern iterations

[terra]

Okay so I figured out how to modify the DME program to allow me to dump all the CPU registers (rather than the select few BMW allowed). That might be useful in the event that we unlock the CPU and have to rewrite registers (minus the censor values).

In any case, on my MSS65, this is the UC3FMCR register:

41 FF 00 FF
or in binary:

01000001 11111111 00000000 11111111)

Here's the bit definitions:



And these are the definitions for the censor registers speciically:



So going back to the registers I dumped (01000001 11111111 00000000 11111111)

So according to that, the MSS65 is set to
ACCESS = 0
FIC = 0
CENSOR[0:1] = 01

Put together that's no censorship, which is consistent with behavior that we see.

So when my (probably locked) MSS60 arrives, I will do the same mod to it and read the registers. If that shows the censor bits as being set, then that tells us that is most likely what the issue is and should be fixable with the right debugger

Per that NXP GM driver document:



So while it sounds like we'd have to go to 00 and then to 01/10 (if it's not already 00), it sounds like it is indeed possible.

[dpaul]

Excuse this likely stupid question but are you sure you are reading shadow memory, where this register is supposed to be? I thought that normal array is accessed when the SIE register bit in the UC3FMCR = 0. To read the shadow memory, SIE is supposed to be set to =1.

EDIT: I see, you read from the MSS65, not the MSS60. Sorry!

EDIT 2: OK, I guess this is a very confusing issue for me - how to actually read shadow memory

[terra]

Locked MSS60 came in. Flashed my RSA delete to it along with the patch to read registers.

Injection UC3FMCR is: 43 FF 00 FF (01000011 11111111 00000000 11111111)
Ignition UC3FMCR is: 41 FF 00 FF (same as both CPUs on MSS65 and equivalent to factory state)

That Injection register translates to
ACCESS = 0
FIC = 0
CENSOR[0:1] = 11

So that confirms it, the BDM lock is indeed exerted through censored mode.

This should be fixable.

BTW this DME was built in April 2008, part number is 7841981 / 5WK9588 My unlocked dump was from a 7841364 / 5WK9586. 7841102 / 5WK9584 is likely also unlocked.

7840872 is unknown. I assume that's 5WK9587, though I can't actually find a pic of a DME with that part number.

Everything else will almost certainly be locked.

[dpaul]

So that confirms it, the BDM lock is indeed exerted through censored mode.

This should be fixable.

.

Awesome

[tdott]

Locked MSS60 came in.

BTW this DME was built in April 2008.

if its an 08, I thought they weren't locked until later years?

[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).

[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]

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]

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]

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]

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]

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#/