There are a few JTAG connectors available, so it's hard to tell which one, and how the pins are positioned.
I suggest you take a magnifying glass and read the microcontroller model. With the model you will be able to find the datasheet on the Internet.
Take a look at the PIN out of the microcontroller, and see how many JTAG outputs it has. Some newer chips ...
JTAG was initially created to test/verify hardware devices. The process is called boundary scanning and JTAG was named after the working group: Joint Test Action Group, some time in the 1980s.
The idea was to define an interface that could be used to test hardware (micro controllers and connected peripherals after manufacturing). I.e. after development of ...
For figuring out JTAG pinout, there are many hits on google for "JTAG Finder". I also have my own implementation:
It's for mbed but I tried to make it easily portable (original version was for a Stellaris board).
Here's a quote from the comment which describes the basic approach:
The overall idea:
I created a video how I identified a possible JTAG connection with a multimeter. Here is a picture showing which pins are connected and it matches with a standard JTAG pinout for VCC and GND. This is an indication that it could be JTAG, though it doesn't have to be.
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 ...
The question is kinda vague but here's some approaches that might work:
Glitching (e.g. voltage dropping, clock slowdown, too short reset pulse). This could cause either a change in the sensed value of the fuse, or change in the code flow in case the check is implemented in software. For an example of this technique see Breaking Code Read Protection on the ...
Turns out openocd for ARM11 had a few bugs in it. I ended up making a few changes to get it working as per the arm spec:
Turning on the drain of the data aborts. The check should be:
if (!(dscr & DSCR_STICKY_ABORT_IMPRECISE))
Then added the following code before the C1 control register
/* Enable Debug Cache write back, and ...
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 ...
You have picked a particularly hard target to try and find JTAG on, if this is your first project.
There are no obvious JTAG ports on the board. The microcontroller looks to be in a BGA package, so you can't trace the pins from there. Same with the flash. It is almost certainly a multi-layer board as well.
So there are a number of options:
It may never ...
In order to boot from the image you'd need to figure out the hardware configuration of the device. That is what peripherals are mapped where, their operation and registers. Without a specification for both the SOC you're dealing with and the hardware board you're going to have to reverse engineer the firmware of the device. This will allow you to figure out ...
JTAG is one way, if you manage to find it on the board and figure out how to dump the firmware over it. However, there are often easier ways, e.g.
if the firmware is in a separate flash chip, dump it instead (sometimes it's even possible without desoldering)
if the manufacturer provides firmware updates, extract the firmware from the updater.
I am going to take a stab at answering my own question, and may update the answer in the future with additional details about OpenOCD.
There are some things that I did not understand about the Bus Blaster and there are some things that I did not understand about OpenOCD, and in both cases reading the documentation better would have helped. I ended up ...
I'm not familiar with that tool, so I don't have an answer for your specific question. But here are two pieces of advice:
1) there are many arduino simulators that you can use to single-step thru the code.
2) The Arduino is small and simple enough that you should be able to reverse engineer it using only the (dis)assembly and your brain. (Unlike the x86, ...
I have used the following devices successfully with OpenOCD:
https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD/ (only ARM)
The Bus Blaster is compatible with OpenOCD as it was a jtagkey and therefore I think it will satisfy your needs accordingly.
Have you seen the Bus Blaster? It is an FT2232 based board which has both ARM and MIPS eJTAG support. The Bus Pirate (also sold by Dangerous Prototypes) also has the ability to perform JTAG, but it runs much slower (like, 10 bits a minute or something ridiculous).
The firmware itself most likely is not a binary. Also usually when you run file it will tell you something like:
busybox: ELF 32-bit MSB executable, MIPS, MIPS32 version 1. My guess is that you haven't actually extracted any binaries yet. My advice would be to use something like binwalk to extract specific files and binaries from the firmware. ...
First, you will need to make a map of every pins on the PCB, you will find a good starter here.
Once done, what I propose is to use a JTAG discovery tool. You can find some like this one or this one . It just need an Arduino and cables.
These tools are usefull to find JTAG pinout, but be careful to use a 5V to 3.3V adaptor as most JTAG are 3.3V compliant, ...
In the second picture on the bottom there is an nonpupulated connector, whose pins are labeled RX and TX. Thats at least one of maybe more uart interfaces.
You should additionaly check the traces on the pcb between that connector and the main micro controller. It might be that the nonpopulated pads at R1 need to be shortened to have a connection.
No, TCK doesn’t have to match the CPU clock. In fact its usual speed is in kilohertz, not megahertz. However, you likely won’t see it in the oscilloscope or logic analyzer because it is driven by the JTAG probe and not the CPU. Discovering the JTAG pins requires active probing using something like JTAGulator, you are unlikely to find it via passive ...
There are two possible ways of programming flash over JTAG in such a circuit:
use JTAG boundary scan to directly bitbang flash chip pins connected to the CPU as if you connected programmer to it. This usually requires detailed mapping of chip pins to boundary scan register (e.g. BDSL file), knowledge of how the flash chip is connected to the CPU, and ...
Not aware of any similar software tools for SWD, but:
If you can see or infer the chip part number, look at the data sheet.
Look for test points (or connectors) that may be used in factory programming. They will likely be connected directly to the chip, but SWDIO pins may or may not also double as some other function. Unlike JTAG, SWD will not be daisy-...
At a guess, it is using NAND flash. This type of flash has good density and is reasonably cheap but it has one limitation: individual bits can be only toggled from 1 to 0 but not the other way around. If you need to set any bit to 1, you need to erase it, and NAND can only be erased in whole blocks (block size and layout is chip-specific). So, to write ...
I think it's important to differentiate security-oriented microcontrollers where advanced security measures are implemented on several levels including physical arrangement of the chip and general-purpose controllers, maybe with some basic security features. I'm going to answer mostly about the latter group.
When a technical reference manual mentions memory ...
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 ...
This isn't the cleanest solution, and I still don't know how to make gdb do it properly. My solution was to simply manually "call" the function by:
Save the current set of registers (info reg => log file).
Set up parameters by manually modifying registers, pushing things onto the stack, etc, being careful to make sure not to overwrite anything higher than ...
binnavi from google works well remotely with gdb, it does require a bit of setup though and also needs IDA to create the IDB which is then converted to navi database format.
Given that you want to single step you'll be halting the processor sooner or later, what keeps you from trying it now?
I'm trying to envision how the JTAG unit would be able to inspect the memory if the running program is keeping the bus(ses) in use? I expect the TAP can access some boundary cells while the processor is running as they're basically copied/...