MPC 5517G JTAG's Device Identification Register

[LeGhimp]

Hi everyone i stucked at an annoying problem .

I am trying to interogate the "Device Identification Register" through JTAG on a  MPC5517G .

And i am recieving a different Number than datasheets says.

According  to Datasheet i shopuld recieve this :

"* * * * 1 0 0 0 0 0 0 1 0 0 0 1 0 1 1 0 0 0 0 0 0 0 0 1 1 1 0 1

Device Identification Register

Field Description

0–3

Part Revision Number. Contains the revision number of the device. This field changes with each revision of the device

 or module.

4–9

Design Center. Indicates the Freescale design center. For the MPC5510 family this value is 0x20.

10–19

Part Identification Number. Contains the part number of the device. For the MPC5510 family, this value is 0x116. 

20–30

Manufacturer Identity Code. Contains the reduced Joint Electron Device Engineering Council (JEDEC) ID for

Freescale, 0xE.

31

Allways 1"

I am recieving another 32 bits word.

Something like:

1100 0000 0010 0000 0000 0100 0000 0000 0000

Is there any chance this Identification number may vary from what datasheet gives us?

[AROK]

Hi,

You can find deviation to reference manual  into your component errata sheet. The MPC551x family is stable product, JTAG identification shall not change ( we are using 5553,5566; 5567, 5568G , and 5516/5517 on our ECUs)

[cpan]

Good day everyone,

I'm working with LeGhimp  on a JTAG flasher for our Diploma Project, we fixed the DID problem (it was in fact a TCK slew rate missunderstanding) and we're now facing another problem. Do the MPC551x chips with just one core (the ones with no z0 - S suffix) have the NPC Read/Write Memory Access controller fully enabled? What are the steps to gain access to the NPC registers?

the AUX_TAP_..NPC followed by NEXUS_ENABLE gives us access to the DID but not to the Memory related registers. What's up?

We succeded reading the memory by entering ONCE_z0 then moving to the Nexus3Access and doing the RWA/RWCS/RWD z0core_RM steps, but writing memory doesnt work this way (the ERR | DIV bits point to <write succeded>). Note that the target has no z0 - we think there is a hardware routing happening. What are we misstepping? Is this routing consistent across all the S devices?

Thanks in advance