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
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)
Dear @foreverwlh2025 ,
Thank you for your questions.
Recommended Approach
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.
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
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.