Flash Reading by JTAG

Question

I'm trying to read the flash memory of a microcontroller MPC5606B from Motorola. I saw his pins and saw that it uses jtag to perform debug, so I'm trying to use it JTAG interface to read its flash content.

I 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. I read about JTAG standard( JTAG_IEEE-Std-1149.1-2001 ), and some videos and explanations on the internet. I read about TAP controller state diagram and read about some instructions too.

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, however, the communication has almost 10s of duration. So, I filled the entire flash with zeros and read the memory, in this way, I was able identify the reading of memory using the osciloscope. However, although I can identify the reading of memory using the osciloscope, I can't determine yet the exact sequence of commands to perform the reading. The time of reading is too big, almost 10s.

So, before to go more deep, I would like to know if there is some kind of protection to access the flash memory. I tried to understand the beginning of the communication, I can identify the progress in the TAP controller's state machine, but I was not able to understand what this steps means and why it is done. So, I would like to know:

1) Can I determine if the communication has some kind of protection ? I really need to know it before to go further in the task because I need to know the task's complexity level before to go more deep

2) Although I read about the JTAG standard and the TAP controller state machine, I was not able to say what sequence of comands I need to read the flahs content.

Abaixo está a leitura do flash do MPC5606B realizada pela ferramenta com o auxílio do PC. The image is composed of a sequence of images. The first is the image of the communication in full, the second is the beginning of the communication, there is an arrow indicating where it was withdrawn.

This was my interpretation until now

FIGURE 1:

1.1 - (TMS = 1) Test-Logic-Resset

1.2 - (CLK wide pulse) I do not know why.

1.3 - (8 pulses of CLK, TMS = 1)

Since TMS did not came out to 1 I understand that it did not quit Test-logic-Reset

1.4 - (TMS = 0, 1 pulse clock) enters Run-Test-Idle

---

FIGURE 2:

2.1 - (TMS = 1, 2 clock pulses) Goes to the "Select IR-Scan" state

2.2 - (TMS = 0, 2 pulses of clock) Go to the state "Shif-IR"

2.3 - (TMS = 0, 4 clock pulses) Remains in "Shift-IR"

TDI: 1000 TDO: 1000 2.4 - (TMS = 1, 1 clock pulse) Goes to the "Exit1-IR"

2.5 - (TMS = 1, 1 clock pulse) Goes to the status "Update-IR"

2.6 - (TMS = 0, 1 clock pulse) Goes to the "Run-Test-Idle"

---

FIGURE 3:

3.1 - (TMS = 1, 1 clock pulse) goes to the "Select DR-Scan" state

3.2 - (TMS = 0, 2 clock pulses) Go to the status "Shif-DR"

3.3 - (TMS = 0, 31 clock pulses) Go to the "Shif-DR" state

The 32 clock cycles are equivalent to 4 bytes:

TDI: 0x00 0x00 0x00 0x00 TDO: 0xB8 0x0C 0x27 0x54 (10111000 00001100 00100111 01010100)

3.4 - (TMS = 1, 1 clock pulse) Goes to the "Exit1-DR"

3.5 - (TMS = 1, 1 clock pulse) Goes to the status "Update-DR"

3.6 - (TMS = 0, 1 clock pulse) Goes to the "Run-Test-Idle"

Answer 1

Interpreting JTAG transactions by hand can be pretty tiresome. If you can export your data to a more or less universal data format, like VCD or even a CSV file, you can use Sigrok and Pulseview to decode your data. This will decode the low-level JTAG data; if you know the specifics of the controller like TAP register layout and command set, you can extend Sigrok with a decoder that runs on top of the existing IEEE-1149 decoder.

Answer 2

Your interpretation looks pretty close to me. However, this is very low-level view, you need to bring it back to the higher level, at least IR/DR. For example, the whole exchange 1-3 can be summarized as:

Write IR=0b100 (8), read DR=0x2AE4301D

(DR bits are shifted in from the lowest one, so you need to swap the bit string)

This IR value is very close to the standard IDCODE(4), so I think there is an off-by-one in your interpretation and this exchange is reading the device ID. In fact, the value 0x2AE4301D matches the one for MPC5606BF I found in this document.

As for actual flash reading, I doubt it's done using raw JTAG commands. AFAIK the common ways of reading flash are the following:

1. using boundary scan, set and read the CPU pins connected to the flash chip; basically turning the CPU into a bit-bang flash programmer. This obviously only works with external flash so probably not your case
2. using custom chip-specific debugging commands, read and write the flash device I/O registers in the CPU memory space.
3. using custom chip-specific debugging commands, upload a small flasher program into the CPU's RAM and let it execute. The program would chunks of flash into a RAM area which can then be fetched via JTAG back to the host. by setting the register state before each execution, different parts of flash could be accessed.

I would recommend you to use a program like urJTAG or OpenOCD to perform high-level JTAG manipulations (like sending IR and reading DR) if you want to reproduce what the flasher program is doing. urJTAG also has a mode to brute-force possible IR values which may let you discover the vendor-specific commands.