RT1064 Online Upgrade Plan The following figure is the hardware expansion diagram of our product: 1.The PC and mainboard are connected via TCP 2.The mainboard is connected to four subboards through four SPI buses, and the functions of the subboards are the same 3.The uart4 of the mainboard can be switched to UART1 of 4 sub boards through a serial port swtich chip foreverwlh2025_0-1789970732170.png Due to project requirements, the PC needs to upgrade the firmware program of four sub boards RT1064 through TCP. Based on hardware expansion, can you help provide the simplest solution for upgrading the sub board firmware (considering the workload of upper computer development, mainboard development, and sub board development) i.MXRT 106x Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 ,
Thank you for your questions.
Recommended Approach
The PC communicates with the mainboard over TCP. The mainboard acts as a TCP server and implements a UART transparent bridge. UART4 on the mainboard is routed through a serial switch chip to the UART1 interface of the selected sub-board. The sub-board runs the RT1064 ROM Bootloader, so no additional bootloader or firmware development is required on the sub-board side.
Step-by-step upgrade flow for a single sub-board :
Assert RESET on sub-board N; set BOOT_MODE[1:0] = 01 (Serial Downloader mode)
Switch the serial switch chip to connect UART4 to sub-board N's UART1
Release RESET — sub-board N enters the RT1064 ROM Bootloader and waits for UART commands
Enable TCP↔UART4 byte forwarding
Toggle RESET and restore BOOT_MODE to normal — sub-board N boots with the new firmware
Switch the serial selector to the next sub-board and repeat
Hardware Prerequisites
Please confirm the following hardware conditions are in place before implementation:
Mainboard has independent GPIO control over each sub-board's BOOT_MODE[1:0] pins
Mainboard has independent GPIO control over each sub-board's RESET pin
The serial switch chip is controllable by mainboard GPIO and supports switching among all 4 sub-boards
Please feel free to reach out if you have any questions or would like to discuss implementation details further. Re: RT1064 Online Upgrade Plan 4.Enable TCP↔UART4 byte forwarding -----Excuse me, do we need to develop an additional upper computer for this step of data transmission? For example, what format should the PC transmit image data in, how should it parse the response data returned by the sub board, and how should it interact Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 ,
Please find below a summary of our recommended solution for your firmware upgrade scenario.
1. PC Tool
On the PC side, we provides blhost — an open-source command-line client that implements NXP's MCU Bootloader private framing protocol (BSD/MIT license). The device-side protocol is implemented by the MCU on-chip ROM Bootloader. Together, they enable firmware download and device configuration.
The tool supports USB and UART1, doesn't support TCP.
Open-source repository: https://github.com/nxp-mcuxpresso/spsdk
blhost and the ROM Bootloader communicate using a proprietary framing packet protocol, please refer to: MCU Bootloader v2.5.0 Reference Manual (MCUBOOTRM)
For firmware image generation and packaging, please use the nxpimage tool included in NXP's SPSDK (Secure Provisioning SDK).
2. Recommended Solution: TCP Transparent Forwarding via Mainboard
For your scenario (PC→ Mainboard → Sub-board), the minimum-effort approach is to have the mainboard act as a transparent TCP-to-UART bridge, with a small modification to blhost to wrap serial data in TCP:
Architecture:
PC (modified blhost)
↓ TCP packet (include original UART byte stream)
Main Board (TCP Server)
↓ Unpack and forward to sub-board via UART
Sub-board (ROM Bootloader)
Key modification points:
Modify blhost transport layer: Add a new TCP transport module in the blhost source code. The existing UART byte stream (Framing Packets) is wrapped into TCP packets as-is on the send path, and unwrapped on the receive path.
Main board implements a TCP Server: Receives TCP data from the PC, forwards the payload byte-for-byte to the sub-board via UART1; sub-board responses are forwarded back to the PC via TCP in the same transparent manner.
Sub-board requires no changes: The sub-board MCU simply needs to be in ISP mode with the ROM Bootloader running, waiting for standard UART commands.
Re: RT1064 Online Upgrade Plan Here are a few questions: 1. Can't the bin firmware compiled directly from mcuXpressIDE be used? Do I have to use nxpimage? 2. It seems that to complete the upgrade of the sub board, we need to switch the MCU's startup mode and switch channel using our own upper computer software. In other words, we must use our own upper computer and blhost software together. If we upgrade four sub boards, frequent switching can be a bit troublesome 3. The motherboard TCP needs to enter transparent mode first in order for the BLhost to interact with the subboard. After the interaction is complete, how can the motherboard be triggered to switch from transparent mode to TCP receiving mode, so that the subboard can enter normal startup mode 4. Add a new TCP transmission module to the blhost source code - do you have an example 5. Is there any suggestion for implementing serial port transparent transmission on the motherboard, such as using DMA or implementing interrupt and blocking Re: RT1064 Online Upgrade Plan Dear @ShellyZhang Can you provide a response to the issue raised last time today? Thank you!! PS:The upgrade plan for this project is brand new and may require a lot of your support Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 ,
1. The BIN file generated directly by MCUXpresso IDE cannot boot. nxpimage converts the BIN file generated by MCUXpresso IDE into a bootable image.
2. Yes, you need to modify your host PC software yourself. With this approach, the four sub -boards can only be upgraded one at a time.
3. The main-board application needs to handle this. After the firmware upgrade is completed, the main-board should switch back to TCP receive mode by itself, control the sub-board's boot mode to switch to QSPI boot mode, and then reset the sub-board. The sub-board will then boot normally.
4. No, we do not have an example for this.
5. No specific recommendation. After all the TCP data has been received, send it to the sub-board through UART. We recommend using a polling method for the UART transmission.
Best Regards,
Shelly Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 ,
1. After blhost completes programming the firmware to the board via UART1, the bootloader will return a response after it finishes verification of the programmed image.
For your use case, the PC can monitor this response and then command the main board to switch to the TCP received mode.
2. Instead of acting as a transparent forwarding device, the main board can function as a server and implement the MCU Bootloader protocol (host) directly in its firmware. This allows the main board to manage the firmware upgrade process and communication with the sub-boards itself.
Best Regards,
Shelly
Re: RT1064 Online Upgrade Plan Dear @ShellyZhang After the firmware upgrade is completed, the main-board should switch back to TCP receive mode by itself 1.In transparent transmission mode, the mainboard cannot detect that the sub board upgrade has ended, right? 2.It seems that this solution has some less coding on the device side, but there are many things to do on the host side, and upgrading all of them makes the operation more complicated. Is there any other solution?
View full article