Seeking Advice on High-Speed SPI Flash Analysis (~44 MHz) - Page 1
Forum section: electronics / projects

author: Greg J
author_rank: Regular Contributor
timestamp: April 12, 2025, 06:28:37 pm
content: Hello all,I'm seeking some guidance regarding an SPI flash analysis task that has proven a bit more challenging than anticipated. While my background is primarily in software, I have some experience with hardware tools and protocols, and I’m hoping to learn more through this process.The goal is to identify which regions of a flash memory chip are being accessed by the microcontroller on a small embedded device. I've successfully dumped the SPI flash contents—no issues there.However, the microcontroller in question appears to be of a rather obscure type (GPCE100A - μ'nSP2.0), and I haven’t found any reverse engineering tools or frameworks that support it. Given that, I decided to monitor live SPI traffic using a scope and logic analysers.Here’s where I’ve encountered trouble:The SPI clock appears to run at approximately 44 MHz, based on oscilloscope measurements.Probing the SPI clock line with a scope or logic analyzer introduces instability. In some cases, simply attaching the probe causes the system to freeze or stop executing code.I’ve attempted to capture the traffic using both a Digilent Digital Discovery and a DSLogic U2Basic, both of which claim to support these speeds. However, the data I’m receiving seems unreliable—either incomplete, corrupted, or nonsensical.At this point, I suspect signal integrity issues or possibly excessive loading on the clock line. Still, I’d prefer not to proceed purely by trial and error. If anyone has experience with non-intrusive probing of high-speed SPI or has encountered similar issues, I would greatly appreciate any suggestions or insights—particularly when working with inexpensive or mid-range equipment.Thank you in advance for your time and assistance.

author: DavidAlfa
author_rank: Super Contributor
timestamp: April 12, 2025, 06:52:10 pm
content: Not sure what you're trying to achieve here, I doubt you'll find anything useful by probing the bus directly.It's just a spi memory with the firmware in it, it'll be fetching instructions and data all the time.Dumping the memory with a cheap CH341A programmer or similar will probably be way more useful.Anyway:- Set the scope probes to 10x, 1x will cause a huge capacitive load, but still might be too much for such speed.Use thin wires for the pico and keep them as short as possible, also keep the wires way from each other, don't shield them.This will reduce inductances and capacitances, which likely are the issue there.Option B:Take a buffer (I.E. 74HC244, 74HC245) and connect it to the board.Use max. 30mm wires between the buffer and the board. Connect the unused inputs to Gnd to avoid unwanted noise (You can leave the outputs floating).Now you'll be able to connect anything to the buffer output it without disturbing the original signal.

author: Greg J
author_rank: Regular Contributor
timestamp: April 13, 2025, 03:59:13 pm
content: Probes are always at 10X. Annoys me that Rigol has defaults in settings to 1x, but probes ship with switches at 10x!The reason for this approach is that nobody can reverse engineer machine code for GPCE100A AKA μ'nSP2.0 architecture. Literally none of the reverse engineering tools, ida pro, ghidra, binary ninja etc.So the thought was, let's see what addresses the uC requests - and try to modify some of it to see if graphics changes on the screen.Not that crazy of a thought , me thinks, .Alternative is to try to remove this chip every so often , make small change, put it back in, etc. That's tedious!

author: DavidAlfa
author_rank: Super Contributor
timestamp: April 13, 2025, 05:06:56 pm
content: The FW might be scrambled and/or encrypted.How about using a SOIC8 socke like this one?There's a documentherereferencing "GPCE100A Programming Guide", so try asking them?

author: Greg J
author_rank: Regular Contributor
timestamp: April 13, 2025, 07:25:12 pm
content: firmware is not encrypted, I can see clearly header etc in the SPI.I don't know what type of case this is, but it's very finely pitched. Luckily getting it off the board is easy , I then solder it onto a test board and dump it that way - using RaspberryPI . See the pics.I have now moved to trying to analyse test points leading directly to one of the LED drivers. But I can't seem to figure out what sort of protocol it is.You wouldn't happen to know what sort of protocol this might be?Looks like first pin is some sort of a synchronisation per byte or such. Second one is data and third one is end of line .