1
\$\begingroup\$

I have an old PCB that is no longer manufactured. I'd like to get the firmware out of it, but it looks like it has an MCU on it and an Altera Cyclone FPGA first generation. I'm still learning how the PCB is constructed and I'm a novice at extracting firmware (I'm so sad that I didn't learn earlier to do this, because it looks so cool and is worth knowing), but I suspect that there are two firmwares, if I may call them that.

The one on the MCU runs and accepts requests from the machine's keypad. It drives motors and also checks the status of various sensors on the machine. In general, it performs all the functions of the machine.

The PCB is connected to another PCB (the second PCB is not of my interest, it is still in production. It is from a different manufacturer) and it's communicating with it and here the FPGA seems to be doing the work. Actually the FPGA receives signals from the second PCB and I guess tells the MCU what to do - which motor to drive, status of sensors, etc. I'm not sure why they use both - MCU and FPGA at all on this PCB. Probably the MCU can't accept such requests from the second PCB because it should do multiple things in parallel like move two motors at the same time, check the status of multiple sensors at the same time and the MCU can't do that.

Fortunately, the PCB has two open connections - a UART controller that is built on the PCB with USB-B from the PCB and I can connect to it with a simple USB-B to USB-A cable to the computer. On the other hand, there is also a JTAG open connection. It appears to be connected to flash memory on the PCB and FPGA. I verified this by looking at the PCB paths. Both MCU and FPGA are also connected together. I have the basics of dumping the firmware on the PCB, but I lack the knowledge of how I can extract both firmwares (if there are two).

I assume the MCU firmware is written in C and the FPGA firmware is written in HDL. How can I be sure that when I try to extract the information that I got all the data from all the FLASH and EEPROM on the MCU and FPGA?

I'm going to try to rebuild the exact same PCB and want to make sure all the data is extracted, so I can later upload it to the new PCB and still be able to do what it should do and communicate with the second PCB effectively.

\$\endgroup\$
6
  • \$\begingroup\$ Cross posted to reddit reddit.com/r/embedded/comments/10iiqru/… \$\endgroup\$ Jan 22, 2023 at 12:57
  • 3
    \$\begingroup\$ What makes you think the firmware is even dumpable? MCUs have lock bits to allow manufacturers to prevent cloning a product by just dumping the firmware. The FPGA configuration data may also be scrambled to prevent using it with another FPGA with different serial number. And it does not matter at all how the MCU firmware is made, C or whatever, or how FPGA configuration data is made, HDL or graphically, they are just binary data now. \$\endgroup\$
    – Justme
    Jan 22, 2023 at 14:22
  • 1
    \$\begingroup\$ Even if you are able to dump the MCU FW, the fact the it may have been written in C is almost irrelevant. C is a compiled language, so what's inside the MCU is "machine code", which can only be represented as assembler (for humans). \$\endgroup\$
    – brhans
    Jan 22, 2023 at 14:52
  • \$\begingroup\$ @Justme - I have a program acting like a driver which works by connecting to the built in UART controller on the PCB with USB-B from the PCB to the USB-A on the computer. It's a basic program to test the motors and check the status of the sensors. It's communicating with the MCU on the PCB. The company left open some ports with headers: UART controller with a USB-B and a JTAG 10 pin labeled as FPGA ISP on it. Considering the fact that they offered firmware update via one of their technicians back in the days, I strongly believe that they have no protection at all. It's not a huge company. \$\endgroup\$
    – nRov
    Jan 22, 2023 at 15:05
  • \$\begingroup\$ @Justme - I will try to dump the firmware by connecting to the MCU via the UART and using Putty on Windows. I will see if there is any bootloader and use it to dump the firmware. But what about the FPGA firmware? I have Altera USB ByteBlaster to connect to the JTAG. I will use Quartus II programmer. Any other ideas to make sure that I dumped everything? Maybe I don't even have to use the USB ByteBlaster and dumping through the UART communication will be enough? Could you please let me know some ideas on how to approach this? Thank you! \$\endgroup\$
    – nRov
    Jan 22, 2023 at 15:08

1 Answer 1

1
\$\begingroup\$

In my opinion you can take several approaches:

  1. If both devices (MCU and FPGA) store their code/configuration in the same flash, you can simply download the contents via a dedicated reader (You can buy one, serial or parallel) and write the contents to the new chip on the new board.

  2. You can just unsolder the flash and resolder it to the new board.

  3. You can unsolder and resolder the FPGA and MCU (If they store their config internally and readout is locked)

  4. You can connect to the MCU/FPGA via e.g. a JTAG-Probe and download the internal code/config if readout is not locked.

  5. You can scan the internet/ask the manufacturer for the .bin files. With some luck they will provide them as they no longer manufactur the device in question.

As, in my opinion, the flash only holds the config for the FPGA you can download/reuse the contents from these chips. The MCU will, most likely, store its code internally. Therefore you will have to download (JTAG, if not locked) the code and flah it to a new device - or simply reuse the current device.

My advice:

Simply reuse the components in question (MCU, FPGA, Flash, EEPROM) by unsoldering and resoldering them.

This depends on the "solderability" of these devices and your skillset/tools available - but in my opinion this is the easiest route. Also, if you lack the tools/skills/time, you can involve an "repair-shop" for these kind of tasks. They will charge a few hundred bucks, but this can be worth it (Mandatory machine controllers, defence equipment, what not).

A few problems:

The components (FPGA/MCU) may have code in them to check for device IDs on boot. This is a common feature to make "ripping it off" harder. If so, you will have to reuse the current devices. If not, you will have to dig through the code and find the "comparison" routine.

If the FPGA/MCU/Flash are in some "high density .35mm pitch 1000Pins package" you can run into trouble unsoldering/resoldering them quickly.

Why use a FPGA/MCU tandem:

There are many, many, and even more reasons to do that. MCUs in general are targeted for special jobs - as FPGAs are. BUT: a FPGA can be a simple MCU/dedicated FPGA. It can be what you want it to be.

So judging from the information available to me: I would say, that the FPGA does implement some custom Card<->Card interface reused by the design team. They opted with a FPGA as they maybe wanted special features or internal frame buffering or what not.

The MCU treats the FPGA as some sort of "external communication device" - quite like a UART/USB converter you can buy - and does the "heavy application lifting".

But maybe the FPGA does also implement the actual motor-drive logic and the MCU works as sort of "Sensor-Hub" reading currents and voltages or switches and whatnot.

We would need to trace out the PCB to form a clearer picture of the "assumed" block diagramm of the pcb - but you will never know for sure "what does what" as long as you dont dig thorugh the code/configuration, spend countless hours reading and thinking, measuring and testing.

EDIT 1: To get more detailed (based on the comments) i append this edit.

  1. As it seems, the used FPGA does not have any internal configuration. So all configuration will be stored on an external Device. Either, on boot, the fpga is configured directly from a Flash/EEPROM Memory (easy case) or via the MCU loading the firwame (maybe encrypted, but unlikely) from the flash and sending it to the FPGA (Not so easy case).

To get the contents of the FLASH/EEProm you will have to read it. You should obtain a datasheet for the specific memory used. Based on the exact information you can order/build a probe to read the memory contents. You will have to unsolder the IC to read from it.

When assembling your new PCB, you simply use the same probe to write the exact contents to the new FLASH IC !before! soldering.

  1. To connect to the MCU you will have to get information on what interface is used. To do this, you have to find a datasheet. This will have information on what debug/programming interface is used. If i had to guess, i would go with JTAG.

You then have to order/build a probe for this pecific interface to connect to the controller - it is !very! unlikely that this can be bypased and instead be done via the UART port.

The downloading is usually as follows: You obtain the memory addreses from the datasheet (Flash x->y, eeprom a->b - the addresses) and use you probe via command line/GUI. You then tell it to download the content from addres (x or a) with a size of (y-x, b-a) and save it to your local machine.

On your new PCB you connect to the MCU via the probe again and tell it to upload the contents to the same addresses as they were downloaded from.

In anycase:

If you want to build your own PCB (why not reuse the old one and repair it?) you will have to download the FPGA configuration and the MCU software -both are important.

EDIT 2:

As you downloaded the FPGA configuration succesfully, you now have to continue with MCU firmware.

You can connect to the AVR MCU via the ISP header present on the board. Make sure to get the pinout correct: ISP Datasheet.

To verify, that the ISP is enabled/functional you can try the following: Download the EEPROM content and check for a 0xFF byte. Then try to write that 0xFF byte to a known value ( e.g 0x12). Download the EEPROM content again. If the byte was changed, you can trust both FLASH and EEPROM downloads.

Make sure to also download the fuses - these are important too.

You can store these three files on your local machine to later on programm them onto your new device.

EDIT 3:

As you now have all four files required (FPGA config, MCU flash, MCU EEprom, MCU Fuses) you can rebuild your board.

But be aware: The MCU code may hide some ID-Checks, internal PCB speciic calibration, what not - so dont be happy to early!

\$\endgroup\$
41
  • \$\begingroup\$ Thank you for your answer. The problem is that I have two separate machines and the PCB on one of it is not working anymore. I have to copy the stuff from the one that currently works and reproduce it, so I can get the second machine to work as well. \$\endgroup\$
    – nRov
    Jan 22, 2023 at 15:10
  • \$\begingroup\$ I have a program acting like a driver which works by connecting to the built in UART controller on the PCB with USB-B from the PCB to the USB-A on the computer. It's a basic program to test the motors and check the status of the sensors. It's communicating with the MCU on the PCB. The company left open some ports with headers: UART controller with a USB-B and a JTAG 10 pin labeled as FPGA ISP on it. Considering the fact that they offered firmware update via one of their technicians back in the days, I strongly believe that they have no protection at all. It's not a huge company. \$\endgroup\$
    – nRov
    Jan 22, 2023 at 15:10
  • \$\begingroup\$ I will try to dump the firmware by connecting to the MCU via the UART and using Putty on Windows. I will see if there is any bootloader and use it to dump the firmware. But what about the FPGA firmware? I have Altera USB ByteBlaster to connect to the JTAG. I will use Quartus II programmer. Any other ideas to make sure that I dumped everything? Maybe I don't even have to use the USB ByteBlaster and dumping through the UART communication will be enough? Could you please let me know some ideas on how to approach this? Thank you! \$\endgroup\$
    – nRov
    Jan 22, 2023 at 15:11
  • \$\begingroup\$ @nRov I see. I guess the simplest way to get all Firmware - and make sure it is complete - is to do the follwing: Read the datasheet for the FPGA: Does it have nonvoltaile internal configuration? If so -> Try JTAG/whatever to connect to it and download it. If not: Just use the flash contents. What could be though: The controller writes config directly to the FPGA on every boot. So you will have to get the MCU firmware as well. There i would try JTAG (If unlocked you can download FLASH/EEPROM). \$\endgroup\$ Jan 22, 2023 at 15:21
  • 1
    \$\begingroup\$ You can't expect to be able to dump firmware via serial port and a terminal program. Is there something you know about the device? Many MCUs don't even have a bootloader, do you know anything about the MCU? Which MCU it is? \$\endgroup\$
    – Justme
    Jan 22, 2023 at 16:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.