Flash reading by JTAG in MPC5606B

Question

I'm using MPC5606B and I would like to know what kind of issues I would have, concerning protection\encryption if I tried to read its flash content by JTAG using an external device.

I was able to read the MPC's flash content using a tool (UPA) and a PC, however, I want to do it by my own, using my own embedded hardware without the PC's tool. So, I studied about JTAG standard( JTAG_IEEE-Std-1149.1-2001 ), and about TAP controller state diagram. In order to better understand the JTAG reading, I Used the PC's tool to read the MCP's flash and an osciloscope to see how the communication is performed between the tool and MCP5606B.

I could see that it enters in the TAP controller state machine, The tool writes IR ( 0b00011 )and after that reads DR ( 0x2AE4301D ) and there is a lot of more communication that I didn't recognize yet, but, I know that, according to this document in section 4.4 page 10, the readed value 0x2AE4301D is the IDCODE of JTAG's MCP5606BF.

After to study Chapter five of MPC5606's reference manual, I expected that the tool would send a 64-bits password, but I didn't found it in communication yet ( the time of communication is too big, almost 10s ).

So I was wondering, how is performed the reading of the flash memory content, and how it is related to Censorship at bootloader?

Answer 1

After to study Chapter five of MPC5606's reference manual, I expected that the tool would send a 64-bits password, but I didn't found it in communication yet ( the time of communication is too big, almost 10s ).

Since we don't have your log, we can't tell if the password is present. Quite possibly your specific device does not have security option enabled or there is some way around it (e.g. the default password). In any case, you'll likely need to decode the whole log first to make any further assumptions. (John Doe made some suggestions on how to do it)

So I was wondering, how is performed the reading of the flash memory content, and how it is related to Censorship at bootloader?

Same answer; decode the communication to see how it's performed. I made some hypotheses in my previous answer, but only by examining the actual process you can know for sure how it works (unless you have documentation, which does not seem to be available here).