Cyclone III EPC4 flash - programming off board

[Aiy]

Hello Everyone,
I got myself an Anritsu MS46121A (same as Shariar got for this video: )
Which has an Altera Cyclone EP3C10F256C7N on it together with a EPC4 serial flash.
I think/know that someone tried to load the wrong firmware to the device (There are MS46121A and B models and somebody tried to update the wrong firmware).
I've probed the pins in/out from the serial flash and they are wiggling furiously all the time which makes me think that the FPGA is trying to boot from it but fails.

The board has what I think is a 10-pin bus-blaster style JTAG connector, but I cannot scan/autodetect the jtag chain from Quartus programmer. The Cyclone 3 handbook says that JTAG takes precendence over other device configurations, but with a corrupted flash image I dunno.

So, to the question:
If I lift the EPC4 flash chip off the board, can I breadboard / Frankenstein a programming rig to erase and re-program the chip?
I have two Anritsu RBF firmware files, perhaps these can be programmed to the EPC4 somehow?

Best regards

[BrianHG]

The programming connector may be wired in AS (Active Serial) mode, or passive serial mode, did you test these modes?  These modes allowed read and write of the flash, but no real-time debug.

[marshallh]

Are you sure on the part number? That looks to be an EPCS4 device, not EPC4. There were never any EPC* devices with only 8 pins, unless I'm mistaken.


If it is EPCS4, then it is a bog-standard SPI flash. The M25P40 is a direct dropin replacement. Also, more recently the W25X40CLSNIG can be used as a dropin, though its silicon ID may not allow for Quartus to program it through the IDE.

In any case, that could be a JTAG or a AS programming header. You can try flipping it backwards, the pinout is safe and it won't blow up.
In case it is JTAG, you will have the option to create a Serial Flash Loader chain which basically programs the FPGA with a stub bitstream that wiggles and programs the flash for you, directly from Quartus.
JTAG is always available, if connected, no matter what configuration mode is specified on the FPGA's MSEL strapping pins. So if you have managed to power the probe, and tried Jtagging with both cable orientations with a known working USB Blaster, then it may not be a JTAG header. (Make sure you test your blaster on something else first)

In case it is AS, the header will directly connect to the SPI flash. You could beep out the connections to check this.

[Aiy]

Hi,
Thanks for the replies. I should have known I would invoke Cunningham's Law by not getting the SPI flash part number right =)

I have checked my bus-blaster with a FTDI Morph-IC II board I have lying around. It correctly identifies the Cyclone 2 on that board so i'm pretty confident about the JTAG dongle.

After studying the traces on the board I don't believe it is AS pinning, i'm leaning more and more towards the regular Bus-Blaster JTAG pinout the more I look at it.
Two of the traces on bottom side of the FPGA board are on the outer layer, and if i'm counting the vias under the BGA right they go to TDO and TMS correctly on the connector.
Still no luck with the auto identify though.

I even tried de-soldering the Flash, but still no luck.

I also tried a variant with only connecting GND, VTarget, TCK and TMS to see if they accidentally mapped tdi/tdo mixed up, pin3 on the bus-blaster connector toggles during the identify so it looks to be pinned just as the cyclone 3 handbook suggests (figure 9-24, page 9-50).
However, while doing this I saw three distinct logic levels (Low/High and Mid?!) on TDO when I ran the auto identify cycle. Does anybody know why that could be?

I'll try to capture it on the oscilloscope next time, maybe its time to connect the oscilloscope fully so i get all four signals for analysis.

Best regards

[Aiy]

Hi Everyone,
I connected up my oscilloscope to sample the signals.
I don't understand how the intermediate signal level in the image can happen on TDO, anybody got an idea?

Best regards

[Aiy]

Hi everyone,
OK so I figured out that the USB Blaster clone was the problem. It is a cheaply made CH552 copy of the Altera USB Blaster with just a CH552 IC in it, go figure...
I managed to upgrade the firmware in the CH552 from this GitHub: https://github.com/xjtuecho/CH552Nano and now I can do the auto detect and program in Quartus II programmer.

But now I arrive at the next issue.. The Firmware files we have from the Anritsu Shockline software are RBF format which to my knowledge is for passive serial programming.
I've played around with the Quartus programmer tool but I don't see how I could load the RBF anywhere, except with passive serial.

Anybody got an idea?

Best regards

[Daixiwen]

The Quartus programmer needs a .sof file to configure the FPGA directly or a .pof file for the EPCS flash. As far as I know the Quartus conversion tool (File > Convert Programming File) can convert a .sof or .pof to .rbf but not the other way round.
I think the formats have been reverse engineered so there may be some third party (opensource?) tools that could regenerate the correct file but I'm not aware of any.

[Daixiwen]

I wonder if you can just read the .rbf file as binary and write the contents to the SPI flash from address 0. If I remember correctly there is an issue with bit order (i.e. you need to reverse all bits in each byte from 0-7 to 7-0) but I'm not sure.

[Aiy]

Hi everyone,
So I downloaded TV84s little utility from over here: https://www.eevblog.com/forum/fpga/parser-for-(altera)-fpga-programming-files/
It gets flagged as dangerous / virus by modern webbrowsers so I sandboxed it in a virtualbox and tried it on the RBF files from Anritsu. Here's the output

Code: [Select]

FPGA Parser v0.1 (Alpha) - Parses (Altera + others??) .SOF/.POF/.RBF/.JIC/.RPD files
Processes all files in this directory + sub-directories

USBVNA.rbf
FPGA - RBF/RPD (Raw Binary File) - Filesize: 1 105 896 bits (00021BFD bytes)
00000000 - Start of File  (Type 1)

         [00000048                      00000021]
Bit 7  - 1111111111111111111111111111111111111111       FFFFFFFFFF
Bit 6  - 1111111111111111111111111111111111111111       FFFFFFFFFF
Bit 5  - 1111111111111111111111111111111111111111       FFFFFFFFFF
Bit 4  - 1111111111111111111111111111111111111111       FFFFFFFFFF
Bit 3  - 1111111111111111111111111110110010000000       FFFFFFEC80
Bit 2  - 0000100001101111111011011000000000111111       086FED803F
Bit 1  - 1100000000000111100010000001110111111111       C007881DFF
Bit 0  - 0000000000101011100100010100000011111111       002B9140FF

Bits 0080 - EPCS/EPCQ ID check: Enabled
Bits 005F - Stream size: 1 105 883 bits  (00021BFC bytes)  Compression Bit ON  (+1)     Size OK
Bits 0056 - 0000 0000 : 0x56-0x5D
Bits 004C - Programming Mode: Active Serial (AS x1)
Bits 003B - IDCode (Version+Part Number only): 0x020F1  (-> 0x024F1)
Bits 0008 - Usercode: 002B9140
00000049 - Header CRC-16_MODBUS: E0FF  [00000021-00000048]        CRC OK
0000004B - Initial 0xFF: 167  [0000004B-000000F1]
000000F2 - 4-byte words: 1260  [000000F2-000014A1]      Next: 00 12 00 80 01 00 18 00 00
00021BB3 - Post-device bitstream pad bytes (0xFF): 74  [00021BB3-00021BFC]
File Checksum: 0065614A


USBVNA2.rbf
FPGA - RBF/RPD (Raw Binary File) - Filesize: 1 368 696 bits (00029C4F bytes)
00000000 - Start of File  (Type 1)

         [00000048                      00000021]
Bit 7  - 1111111111111111111111111111111111111111       FFFFFFFFFF
Bit 6  - 1111111111111111111111111111111111111111       FFFFFFFFFF
Bit 5  - 1111111111111111111111111111111111111111       FFFFFFFFFF
Bit 4  - 1111111111111111111111111111111111111111       FFFFFFFFFF
Bit 3  - 1111111111111111111111111110110010000000       FFFFFFEC80
Bit 2  - 0000101001110001001101011000000000111111       0A7135803F
Bit 1  - 1100000000000111100010000000110111111111       C007880DFF
Bit 0  - 0000000001010011011011000110110111111111       00536C6DFF

Bits 0080 - EPCS/EPCQ ID check: Enabled
Bits 005F - Stream size: 1 368 683 bits  (00029C4E bytes)  Compression Bit ON  (+1)     Size OK
Bits 0056 - 0000 0000 : 0x56-0x5D
Bits 004C - Programming Mode: Active Serial (AS x1)
Bits 003B - IDCode (Version+Part Number only): 0x020F1  (-> 0x024F1)
Bits 0008 - Usercode: 00536C6D
00000049 - Header CRC-16_MODBUS: D1FF  [00000021-00000048]        CRC OK
0000004B - Initial 0xFF: 167  [0000004B-000000F1]
000000F2 - 4-byte words: 1260  [000000F2-000014A1]      Next: 00 12 00 80 01 00 18 00 00
00029C05 - Post-device bitstream pad bytes (0xFF): 74  [00029C05-00029C4E]
File Checksum: 00AC82C7
So the bitfile is Active Serial, that's useful information.
I have desoldered my EPCQ4A flash IC and put it on a SOIC breakout so I can play with it on a breadboard.
I tried to match up the Active Serial pinout from Cyclone III handbook page 9.57, Figure 9-29

But the Quartus II programmer says

Code: [Select]

Info (209060): Started Programmer operation at Thu Jan 18 17:59:36 2024
Error (209009): Unable to reset device before configuration
Error (209008): Configuration failed
Info (209061): Ended Programmer operation at Thu Jan 18 17:59:36 2024

The Active Serial pinout connects additional pins CONFIG_DONE, nCE, nCONFIG and from the log output I would suspect that the programmer tries to disable and/or reset the FPGA prior to starting the SPI transactions and maybe it expects some wiggle on CONFIG_DONE or something to begin.

Anybody know more?

Best regards

[Daixiwen]

nConfig and nCE are inputs, but you could try and connect the USB blaster pin connected to CONF_DONE to ground. This would indicate to Quartus that the FPGA is not configured.
But looking at the log, I'm not sure whether it is talking on resetting the FPGA or the EPCS. Do you see any change on the SPI signals when you try?
And of course I assume that you did configure Quartus programmer in AS mode and not JTAG mode?

[zrq]

Any news on fixing this?