Live data from Hacker News

Using JTAG to dump parallel NOR flash

zetier.com

11–20 of 20 posts

Re: Using JTAG to dump parallel NOR flash

#11
post #4

This is a rather convoluted way to do this. Once you have the socket, just connect with wires to a pi pico and dump it over serial.

Oh yes it is convoluted. This is for parallel nor flash though, not serial. I suppose a pi could work I am just confused how you would dump it over serial. You need to connect: D0-D15 A0-A15 CE (STATIC) OE (STATIC) WE (STATIC) WP (STATIC) RST (STATIC) GND (STATIC) 3.3 (STATIC) The pi would have to request an address over the address bus to the flash chip using A0-A15 and then the data would come over on D0-D15 and yo…

connect parallel pins to gpios, data out over usb-serial. i've done this a few times using the very same socket depicted in TFA

Re: Using JTAG to dump parallel NOR flash

#12

Earlier quoted context omitted.

Oh yes it is convoluted. This is for parallel nor flash though, not serial. I suppose a pi could work I am just confused how you would dump it over serial. You need to connect: D0-D15 A0-A15 CE (STATIC) OE (STATIC) WE (STATIC) WP (STATIC) RST (STATIC) GND (STATIC) 3.3 (STATIC) The pi would have to request an address over the address bus to the flash chip using A0-A15 and then the data would come over on D0-D15 and yo…

connect parallel pins to gpios, data out over usb-serial. i've done this a few times using the very same socket depicted in TFA

Updated. Curious about how you wound up tying all 30+ pins on the pico (26 gpio)

Re: Using JTAG to dump parallel NOR flash

#13

Earlier quoted context omitted.

connect parallel pins to gpios, data out over usb-serial. i've done this a few times using the very same socket depicted in TFA

Updated. Curious about how you wound up tying all 30+ pins on the pico (26 gpio)

You can put that nor flash into byte mode, saving you 8 data lines in exchange for an extra address line.

You can also throw a shift register in to increase the number of GPIOs.

Re: Using JTAG to dump parallel NOR flash

#14
post #6

Earlier quoted context omitted.

Yeah, about the only way this would make sense is if they used the boundary scan of the original board's SoC so they didn't have to desolder anything.

This also does work. Some devices do not have the ability to connect to a part though (no bsdl, no jtag header)

Given that the top bit of every 16bit word looks to be set, I'm not sure that it does work.

Re: Using JTAG to dump parallel NOR flash

#15

Earlier quoted context omitted.

Oh yes it is convoluted. This is for parallel nor flash though, not serial. I suppose a pi could work I am just confused how you would dump it over serial. You need to connect: D0-D15 A0-A15 CE (STATIC) OE (STATIC) WE (STATIC) WP (STATIC) RST (STATIC) GND (STATIC) 3.3 (STATIC) The pi would have to request an address over the address bus to the flash chip using A0-A15 and then the data would come over on D0-D15 and yo…

connect parallel pins to gpios, data out over usb-serial. i've done this a few times using the very same socket depicted in TFA

Or hook up a counter (reset + clock signal, that's 2 gpio's), and feed counter output to address lines.

If you're really short on gpio's, you could do the same with the data outputs (use some parallel in, serial out shift register, or a multiplexer that selects which data bit(s) to read).

Re: Using JTAG to dump parallel NOR flash

#16

Earlier quoted context omitted.

This also does work. Some devices do not have the ability to connect to a part though (no bsdl, no jtag header)

Given that the top bit of every 16bit word looks to be set, I'm not sure that it does work.

This would work. And I have done this. You need a jtag port and the flash needs to be directly connected to the SOC/MCU/FPGA. This is similar to how EJTAG works but without ejtag, you need to specify the pins themselves. As long as all 16 data and addr pins are connected, this is possible.

Re: Using JTAG to dump parallel NOR flash

#17

Earlier quoted context omitted.

Updated. Curious about how you wound up tying all 30+ pins on the pico (26 gpio)

You can put that nor flash into byte mode, saving you 8 data lines in exchange for an extra address line. You can also throw a shift register in to increase the number of GPIOs.

Yes, I suppose this would be a functional way to do this. It would take much longer (double or quadruple depending on data bus size). But none the less, it could work.

Re: Using JTAG to dump parallel NOR flash

#18

Earlier quoted context omitted.

You can put that nor flash into byte mode, saving you 8 data lines in exchange for an extra address line. You can also throw a shift register in to increase the number of GPIOs.

Yes, I suppose this would be a functional way to do this. It would take much longer (double or quadruple depending on data bus size). But none the less, it could work.

I think you'll find that even that is much quicker than twiddling lines via boundary scan. At best, JTAG boundary scan is basically one giant shift register generally hundreds to thousands of bits long. Every cycle you'd need to shift out the whole thing even if you change the state of one signal.

Re: Using JTAG to dump parallel NOR flash

#19

Earlier quoted context omitted.

Given that the top bit of every 16bit word looks to be set, I'm not sure that it does work.

This would work. And I have done this. You need a jtag port and the flash needs to be directly connected to the SOC/MCU/FPGA. This is similar to how EJTAG works but without ejtag, you need to specify the pins themselves. As long as all 16 data and addr pins are connected, this is possible.

I know it can be done. NOR boot flashes like this were typically written and verified via boundary scan at manufacturing time. That's probably how this flash was initially written.

I question whether you successfully performed that operation.

Re: Using JTAG to dump parallel NOR flash

#20
Some questions I recvd (author) :

1) Is there a process by which you can do the same in-circuit, similar to the SOP8 footprints that most people are familiar with? Answer: 1) YES! You totally can. In fact this is a preferred method because of its ease if there is ejtag or a jtag header and the flash is connected.Here are a few ways: A) connecting to a target MCU/FPGA to dump over a preexisting bus. B) using a large clip or soldering leads. Not recommended. May backfeed.

2) Are there any hidden gotchas (similar to NAND flash) that people should know about where reading or writing may not result in a 1:1 copy (which can be used later to revert to a known good working state, if the chip is not write protected)? Answer: 2) Not really reliable with this method. Urjtag is software written in 2006 … so it is kinda dated. Topjtag is also quite dated and both are slightly unreliable. It is up to an engineer to really understand what they are doing and the dangers associated with dumping flash memory. Programmers are fairly inexpensive now so this method is more or less a last resort in most cases (wanted to share after trying this). However can be successful if the engineer does this correctly and takes their time. The first time I tried this i grounded the wrong pin. Power cut through the flash chip and destroyed it and took all the data with it.

3) How do you handle these chips when there are no markings, or the chips themselves have incomplete publicly available specifications? Some parallel memory chips I've run into seem to have fuses built-in to the silicon so if you pass voltage or hook up the wrong pin, the entire chip ceases functioning. Answer: 3) A) Start with a logic analyzer https://www.ebay.com/itm/225946293211?chn=ps&norover=1&mkevt... and look at the package size. More than likely if I look at all 24 pins on one side of the chip with a logic analyzer I can collect enough data to start looking for the pins that are data and map them to a datasheet. For example I see data on pins 1-x and x+2-23 and x+1 is vcc and 24 is vss. Then map that so a package like tsop48 and narrow it down. Incomplete public… that is more difficult. Id use the logic analyzer and see how the MCU is taking to it and see if a protocol exists for it and mimic a read if a protocol exists with pins I find. If not… ill cross that hill when I get to it.

B) Oh I wish I had a FIB to edit silicon with. I have not had this issue … ever … so far. Im sure that will change. But ive heard of cracking the lid on a die with a laser and then using a fib to bridge the fuse. Very expensive. Ive also heard of only reading a byte or some small amount of data at a time on powerup, powering down and cycling until full flash is read. I guess it would really depend on the size of the fuse, gap size, and how you can get to it easiest or bypass it. Here is a link to a FIB: https://www.thermofisher.com/us/en/home/electron-microscopy/... Again, do be careful when doing this kind of stuff. Go to goodwill, get some really solid practice on some old netgear routers or other embedded systems before jumping into the high dollar stuff. It helps keep your cool and also understand the process more. Repetition is king in our field … if you can get it.

C) If the target is an FPGA, its a bitstream. And bitstreams are very, very painful to re. The sea of gates is very big. Id recommend looking at something with a tied architecture and older.

Thank you all so much for reading my article. I hope it helped and you got something out of it or will try this in your free time. Keep your eyes peeled for more articles.

Post reply on HN