MAX 10 Remote Update for External flash image

[Jacob11]

Hello everyone.

We are running a custom board with a MAX 10 and a winbond W25Q64JV external flash chip.

In Qsys I have Nios2 processor, the Generic Serial Flash interface(driving the winbond external memory), jtag uart, and a standard UART RS-232 IP.

These devices are all properly constrained and functioning as expected.

Our basic design is for the FPGA internal flash memory, we just have a simple bootloader(bootloader.pof). On the external flash we have our firmware(XIP_flash.bin and header file XIP_flash.bin.header.bin).

The bootloader checks the integrity of the data on the external flash and then jumps to the reset vector of the external flash and our custom firmware starts running. All peripherals are configured and started by the firmware. This is all functioning properly.

I am currently using the customizable flash programming tool to write this firmware onto the external winbond flash. It works, but it is not friendly for our end users. What I am looking for is a flow similar to the RSU update process defined in the an741.pdf, but for the external flash. The bootloader is "golden code" and will not need to change at this point. So, this an741 document is not really helpful for us. All our further development will be on the firmware stored in the external flash.

UART RS-232 is already working, and I have designed an interface that allows function calls from the nios environment over UART.

Any ideas on how I can accomplish this Remote Upgrade of the external flash image would be greatly appreciated.

EDIT: We are also working totally in a Linux environment.

[Farabi]

Hello,

I am sorry, may I know what do you mean by external flash? Can you provide simple diagram to make sure I can understand your problem?

regards,

Farabi

[Jacob11]

External flash??? It means a QSPI flash that is not inside the FPGA. It is a separate chip altogether, but on the same PCB.

[Jacob11]

Here are also my qsys screenshots. There is a lot in the system, but this shows the main components we are talking about.

The normal RSU flow will allow you to update the image stored on the internal memory(UFM/CFM...etc). This is not what I am trying to do.

I want to have a flow where I dont need to load this special max10_flash_pgm.sof file or use the system console with the customizable programmer.tcl script. I think this is too unfriendly for customers when there is a firmware update. I just need an easy flow that uses UART or some other communications protocol to update the firmware that is on the external flash with a new ***.bin file.

Thanks.

[Farabi]

Hello,

There is a good documentation on Remote upgrade using NIOS II as RSU controller.

link : https://www.intel.com/content/www/us/en/docs/programmable/683661/current/reference-design-functional-description.html

You can refer to this document to perform the remote upgrade.

regards,

Farabi

[Farabi]

Hello,

I am sorry, if you want to Remote Update external flash/QSPI content, up to now no solution provided to perform the image update for external flash. This is because QSPI programming will take very long time to complete(expect 10-20mins top depending on QSPI storage capacity). It will consist of erase, program and verify process.

The QSPI programming/update can be done with Quartus programmer working with GFSI (Generic Serial Flash Interface) IP and Avalon MM. But this method cannot be done without connecting the QSPI flash to host PC/laptop (where the Quartus Programmer run) via JTAG interface.

regards,

Farabi

[Jacob11]

Thank you, that is what I assumed, but I wanted to confirm that I wasn't missing something.

Most of our customers don't actually have a blaster/programming cable for the MAX10 so updating the firmware in the traditional way is not possible for them. That is how I do it in my own lab, but I need another solution with a basic protocol that everyone can use.

I have managed to make a solution using the UART RS-232 interface in Nios and a custom python script. Basically the UART does nothing until the start bit is sent from python over the UART. Then the ISR reads the incoming data word and copies it to the proper memory location until EOF is rcvd.

in python 3 you can do something like

ser = serial.Serial('/dev/ttyUSB0', 115200, timeout=0.5) to open the serial connection and

data=firmware_file.read()

ser.write(data) writes data over the serial connection

Loop this through the entire firmware.bin file until EOF.

So far this is working, but needs a lot more testing before I am comfortable sending it out to customers.

Thanks anyway.

Jacob

[Farabi]

Hello Jacob,

That is brilliant idea. Hope you will be successful to develop the data transmission flow until user can use it easily. You can file the process flow as your own IP.

best regards,

Farabi

[Jacob11]

Hello again Farabi,

This process has turned out to be very successful. You mentioned filing the process flow as an IP.

Would you have some more information about how I go about doing that? I would like to look into it but I don't know where to start.

Thanks,

Jacob