Forum Discussion

Logan912's avatar
Logan912
Icon for New Contributor rankNew Contributor
4 months ago

Controlling MCU with FPGA

Dear all,

I’m an embedded developer having pretty good experience in MCU, and I’ve recently begun working with FPGAs. I have no prior experience working on FPGA .

Current Scenario:

In my design, the FPGA orchestrates the system and issues commands to the MCU. The first task is delivering MCU firmware from a PC, through the FPGA (PC GUI -> FPGA -> MCU). I’ll use a custom PC GUI to send the firmware, but I’m uncertain about the appropriate pin connections, protocols, and overall transfer method.

Devices/system involved:

  1. GUI: Custom build GUI
  2. FPGA: Altera Cyclone V SX5CSXC6
  3. MCU: yet to decide(probably one of [stm32, Renesas, Analog device, TI])


My background Knowledge:

With MCU-to-MCU updates, the PC typically instructs the master MCU to place the slave into boot mode via reset/boot pins, the master acknowledges, and then forwards data transparently according to the MCU vendor’s bootloader protocol. That path is well documented. By contrast, I’m struggling to design an equivalent flow with the FPGA as the master.

Help needed:

Could you share best practices or references for:

  • Selecting the interface (e.g., UART, SPI, JTAG) and any required level shifting,

  • Controlling reset/boot-mode entry from the FPGA,

  • Deciding between transparent pass-through vs. FPGA-terminated protocol handling,

  • Managing flow control, buffering, and acknowledgments/error checking,

  • Example schematics or app notes for FPGA-to-MCU firmware download?

Any guidance or pointers would be greatly appreciated. Thank you in advance.

Configuration

5 Replies

  • Farabi's avatar
    Farabi
    Icon for Regular Contributor rankRegular Contributor
    4 months ago

    Hello,


    You may connect FPGA(eg. Cyclone V FPGA) GPIO to the MCU's RESET and BOOT0/BOOTn pins. With this setup, you can use simple FSM in verilog/vhdl to toggle these pins during startup(please make sure you take care of the timing closure).

    You may use SPI/UART bridge in FPGA to forward firmware data. For starter, can try with STM32 or Renesas MCUs in bootloader mode.


    regards,

    Farabi


    • Logan912's avatar
      Logan912
      Icon for New Contributor rankNew Contributor
      4 months ago

      Thank you Farabi,

      I have identified that the Cyclone V SoC FPGA includes an HPS with two UART interfaces. This allows me to physically connect UART0 to the PC application and UART1 to the MCU, so the hardware connectivity aspect is clear.

      The remaining question is about the internal operation of the HPS during firmware transfer. Specifically:

      • Do I need to develop custom software to manage data movement between UART0 and UART1 (e.g., by configuring registers, memory buffers, and flow control)?

      • Or does the HPS provide a built-in mechanism to automatically handle this, essentially functioning as a UART-to-UART bridge without additional intervention?

      Oh by the way I have decided to use STM for MCU as you have suggested

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor
    4 months ago

    Hi,

    accessing MCU thru FPGA is the unusal way, but may be preferred in some cases where FPGA is owning the primary system interface, e.g. PCIe, ethernet or custom specific interface.

    In systems that utilize both FPGA and MCU components, non time-critical communication, configuration and housekeeping jobs are typically assigned to MCU, because they are defined in sequential code and can be implemented there with less resource utilization. But that's a general consideration that must not necessarily apply to your design.

    Things depend on which interfaces are already determined by the system topology, what's their bandwidth and which share of interface bandwidth is required for intended communication.

    Also interface between MCU and FPGA (no matter which peer is director) will be designed according to bandwidth requirements. In order of increasing throughput we have I2C, UART, SPI, Quad-SPI, parallel data bus (e.g. STM32 FMC interface).

    For specifically asked MCU configuration, I agree with @Farabi that serial boot loader is a good method, because it doesn't require previous flash programming, at least in case of STM32. There should be ST code examples for using the boot loader interface in custom code.

    Regards
    Frank

    • Logan912's avatar
      Logan912
      Icon for New Contributor rankNew Contributor
      4 months ago

      @FvM
      Thank you for your wisdom
      >>accessing MCU thru FPGA is the unusal way,
      I agree. From what I’ve researched, most implementations typically follow the opposite approach.

      >>In systems that utilize both FPGA and MCU components...
      Point noted, thank you

      >>Things depend on which interfaces are already determined by the system topology...
      That makes sense. The HPS already provides dedicated pins and dual ARM cores, and I find working with these more straightforward(familiar) compared to directly implementing logic blocks in the FPGA fabric.

      >> For specifically asked MCU configuration, I agree with @Farabi that serial boot..

      I have decided(for the moment) to use the UART interface of HPS and connect UART0 to the PC application and UART1 to the MCU
      But now I am left the two doubts

      • Must I develop custom software to explicitly control data transfer between UART0 and UART1 (e.g., by configuring registers, managing memory buffers, and handling flow control)?

      • Or does the HPS provide a built-in capability to automatically forward data between the two UARTs, effectively acting as a UART-to-UART bridge without additional programming effort?

      Your guidance is much apprecited
      Thank you