openMV RT1062 self firmware update

casper9429 · April 22, 2024, 7:42am

Hello!

I am trying to update the compiled firmware of the OpenMV RT1062 in the field.

The OpenMV RT1062 is connected to a co-processor with LTE-M connectivity, which will receive the compiled firmware files. I’m considering the simplest way of updating the firmware on the OpenMV RT1062.

Questions:

Is self-flash already implemented in the OpenMV fork of MicroPython or the bootloader?
What path would you suggest to make this possible?
Is it more feasible to flash the firmware of the OpenMV RT1062 from a weaker co-microcontroller (MCU)?
Does the OpenMV MicroPython fork use any RTOS, like uTasker or FreeRTOS?
Where is the OpenMV RT1062 bootloader code located on GitHub?

Thank you!

Best regards,
Casper

iabdalkader · April 22, 2024, 1:47pm

The simplest way would be to modify the bootloader to enable UART (if it’s not enabled already, I think it is) and use it to update the firmware. Our bootloader is basically the one generated by MCUXpresso, flashloader example (I think based on MCU boot) with some minor modifications:

Is self-flash already implemented in the OpenMV fork of MicroPython or the bootloader?

No we don’t have any support for that, and MicroPython doesn’t run an RTOS.

kwagyeman · April 22, 2024, 7:36pm

You can use the MCUExpresso to generate a partial binary that you can jtag onto the MCU. To generate the binaries that the IDE uses to flash to the camera you then need to use the MCU Expressor Secure Previsioning tool to take the elf files generated and turn those into .bin files that can be flashed to the camera.

You’re going to need to go deep reading a lot of documentation to understand NXPs bootloader. It’s quite capable but very complex. However, you’re pretty much able to do whatever you need to do as we’ve made no hard decisions for you on usage. The NXP bootloader can boot the system from a variety of different media and also accept firmware images from many different interfaces. The keys are unprovisioned, the HAB is open, etc. So, you can lockdown the device as little or as much as you like. We only burn a fuse to make it ignore external I/O pins when booting.

casper9429 · April 24, 2024, 2:09pm

We are already using the JTAG for I2S with some hardware modifications. Can you update the bootloader without using the JTAG?

Best Casper

kwagyeman · April 24, 2024, 3:08pm

Yeah, it can be updated via USB. Just put the camera into SBL mode and you can load a new one.

Note, the IDE can do this for you. Find your OpenMV IDE resources directory and the bootloader file is under firmware/OPENMV_RT1062. There’s two files, one which is a first stage bootloader that gets loaded and then a second stage bootloader. The SBL one is the first stage, that never gets written to flash. The BL one is the second stage that’s saved to flash. Both are actually the same code generated by the bootloader project shared above.

Regarding your resources, the IDE has its install for which the bootloader comes in. This has a resource dir. However, this get copied to a OS specific user folder so we can have write access and update the resources. Please let me know what OS you are using and I can give you the exact path.

By overwriting the bootloader file the IDE uses to reprogram the camera you don’t need to do this then via command line scripts. However, we can give you those if you’d like to use the command line instead.

casper9429 · April 24, 2024, 6:16pm

Thank you!

Reading a little bit, there is some code that indicates that it is activated:

github.com

openmv/openmv_rt_bootloader/blob/1775034f564041771156c372dcafa46646615384/evkbmimxrt1060_flashloader/MIMXRT1062/bootloader_config.h#L24


      
          //
          // Bootloader configuration options
          //
          
          //! @name Peripheral configuration macros
          //@{
          
          #undef BL_TARGET_RAM
          #define BL_TARGET_FLASH (1)
          
          #define BL_FEATURE_ROM_UART_PORT (0)
          
          // UART ports
          #if !defined(BL_CONFIG_LPUART_1)
          #define BL_CONFIG_LPUART_1 (BL_FEATURE_ROM_UART_PORT)
          #define BL_FEATURE_UART_RX_PULLUP (1)
          #endif
          
          #ifndef _DEBUG
          #define BL_CONFIG_LPUART (BL_CONFIG_LPUART_1)
          #define BL_TARGET_LPUART (1)

Reading the reference manual for the imxrt 106X:

My goal is to enter the serial downloader mode and then program the imxrt over UART as you proposed. This can be done as I have understood through e-fuses, gpio BOOT_MODE_0 and BOOT_MODE_1, or by writing to registers.
I guess you already are doing this when programming the OpenMV RT1062 through the IDE through BLhost.

If done through the BOOT_MODE GPIO pins:
GPIO_AD_B0_04 is easy to access:

But: GPIO_AD_B0_05 is harder to access without interfering with the camera connection.

It can also be done through the registers SRC_SBMR2 which will read in from the BOOT_MODE pins, the e fuse settings are also involved in the boot behaviour:

9.3.3 Boot From Fuses mode (BOOT_MODE[1:0] = 00b)
A value of 00b in the BOOT_MODE[1:0] register selects the Boot From Fuses mode.
This mode is similar to the Internal Boot mode described in Internal Boot mode
(BOOT_MODE[1:0] = 10b) with one difference. In this mode, the override from the
GPIO boot pins are ignored. The boot ROM code uses the boot eFuse settings only. This
mode also supports a secure boot using HAB.
i.MX RT1060X Processor Reference Manual, Rev. 1, 05/2022
NXP Semiconductors
199Boot modes
If set to Boot From Fuses, the boot flow is controlled by the BT_FUSE_SEL eFuse value.
If BT_FUSE_SEL = 0, indicating that the boot device (for example, flash) was not
programmed yet, the boot flow jumps directly to the Serial Downloader. If
BT_FUSE_SEL = 1, the normal boot flow is followed, where the ROM attempts to boot
from the selected boot device.
The first time a board is used, the default eFuses may be configured incorrectly for the
hardware on the platform. In such case, the Boot ROM code may try to boot from a
device that does not exist. This may cause an electrical/logic violation on some pads.
Using the Boot From Fuses mode addresses this problem.
Setting the BT_FUSE_SEL=0 forces the ROM code to jump directly to the Serial
Downloader. This allows a bootloader to be downloaded which can then provision the
boot device with a program image and blow the BT_FUSE_SEL and the other boot
configuration eFuses. After the reset, the boot ROM code determines that the
BT_FUSE_SEL is blown (BT_FUSE_SEL = 1) and the ROM code performs an internal
boot according to the new eFUSE settings. This allows the user to set
BOOT_MODE[1:0]=00b on a production device and burn the fuses on the same device
(by forcing the entry to the Serial Downloader), without changing the value of the
BOOT_MODE[1:0] or the pullups/pulldowns on the BOOT_MODE pins.
9.3.4 Serial Downloader (BOOT_MODE[1:0] = 01b)
The Serial Downloader provides a means to download a Program Image to the on-chip
RAM over USB or UART serial connection. In this mode, typically a host PC can
communicate to the ROM bootloader using serial download protocol. Serial downloader
and the protocol are discussed in Serial Downloader.
9.3.5 Internal Boot mode (BOOT_MODE[1:0] = 10b)
A value of 10b in the BOOT_MODE[1:0] register selects the Internal Boot mode. In this
mode, the processor continues to execute the boot code from the internal boot ROM.
The boot code performs the hardware initialization, loads the program image from the
chosen boot device, performs the image validation using the HAB library (see Boot
security settings), and then jumps to an address derived from the program image. If an
error occurs during the internal boot, the boot code jumps to the Serial Downloader (see
Serial Downloader (BOOT_MODE[1:0] = 01b)). A secure boot using the HAB is
possible in all the three boot modes.
i.MX RT1060X Processor Reference Manual, Rev. 1, 05/2022
200
NXP SemiconductorsChapter 9 System Boot
When set to the Internal Boot, the boot flow may be controlled by a combination of eFuse
settings with an option of overriding the fuse settings using the General Purpose I/O
(GPIO) pins. The GPIO Boot Select FUSE (BT_FUSE_SEL) determines whether the
ROM uses the GPIO pins for a selected number of configuration parameters or eFuses in
this mode.
• If BT_FUSE_SEL = 1, all boot options are controlled by the eFuses described in
Boot eFuse descriptions.
• If BT_FUSE_SEL = 0, the specific boot configuration parameters may be set using
the GPIO pins rather than eFuses. The fuses that can be overridden when in this
mode are indicated in the GPIO column of Boot eFuse descriptions. GPIO boot
overrides provides the details of the GPIO pins.
The use of the GPIO overrides is intended for development since these pads are used for
other purposes in the deployed products. NXP recommends controlling the boot
configuration by the eFuses in the deployed products and reserving the use of the GPIO
mode for the development and testing purposes only.

I wonder what is the default behaviour of the openMV RT1060. Is the e-fuses set in such a way that it by default will enter serial downloader and look for a USB or UART connection to be programmed for, if not it will continue to execute the program?
Like this behaviour:

A value of 00b in the BOOT_MODE[1:0] register selects the Boot From Fuses mode.
This mode is similar to the Internal Boot mode described in Internal Boot mode
(BOOT_MODE[1:0] = 10b) with one difference. In this mode, the override from the
GPIO boot pins are ignored. The boot ROM code uses the boot eFuse settings only. This
mode also supports a secure boot using HAB.
i.MX RT1060X Processor Reference Manual, Rev. 1, 05/2022
NXP Semiconductors
199Boot modes
If set to Boot From Fuses, the boot flow is controlled by the BT_FUSE_SEL eFuse value.
If BT_FUSE_SEL = 0, indicating that the boot device (for example, flash) was not
programmed yet, the boot flow jumps directly to the Serial Downloader. If
BT_FUSE_SEL = 1, the normal boot flow is followed, where the ROM attempts to boot
from the selected boot device.

To be more concrete which way is the default way of booting the OpenMV RT1062 in this diagram and what are the default e-fuse settings:

This post might be a bit messy, thank you for the patience. I have not yet fully understood the inner working of the boot process of the imxrt 106X.

Best Casper

casper9429 · April 24, 2024, 6:35pm

I think my question can be futher refined as:

Is the BT_FUSE_SEL changed from the factory default? If not, then BT_FUSE_SEL = 0. Then the question arise which of the options in the setting column is executed?

Boot sequence determined by GPIO pins.

OR

Automatically enter serial downloader.

If I am totally of, how do you make the OpenMV RT1062 enter serial downloader using the IDE?

Thank you again!

Best Casper

kwagyeman · April 24, 2024, 8:17pm

Pulling the SBL pin high when you turn the MCU on puts you into the serial bootloader mode using the ROM bootloader.

We burn a fuse to make sure the board tried to load the QSPI flash first before running the ROM bootloader. Virgin chips just enter the ROM bootloader always on boot. So, you have to burn a fuse to make them actually run code on boot up.

It works via USB though. I don’t know if it works via UART. Talking about the ROM bootloader.

The IDE cannot force the ROM bootloader. When the IDE resets the board the regular bootloader is entered (which is burned into the flash) and then exits and launches the firmware if then blhost application doesn’t connect in time.

Note, you can prevent the bootloader from exiting if you pull the Wakeup pin low for 100ms while you reset the MCU. If you do this the bootloader will not jump to the application image but instead just wait until something connects.

You can then definitely connect to the bootloader via USB after doing this. However, I don’t know how you connect to the UART for the bootloader. Not sure if we exposed the right pins for that. So, you might need to edit the pins it uses.

Then, it has a complex protocol, the blhost application can open a UART on a PC to send the right data, however, you’ll need to roll that yourself on your MCU.

casper9429 · April 24, 2024, 8:33pm

With serial bootloader, do you mean "Download and Autenticate Image via Serial Downloader(USB1 or LPUART1) in this image ?

kwagyeman · April 24, 2024, 8:56pm

Our IDE does this to setup a factory board:

Load RAM only bootloader via ROM bootloader from the chip using sdphost.
Use that bootloader to program QSPI flash with actual bootloader.
Talk to the actual bootloader and load firmware via blhost.
Burn the fuse to make sure the board executes QSPI versus going to ROM bootloader on startup.

kwagyeman · April 24, 2024, 8:56pm

Yes, we connect via USB but you could also via a UART.

kwagyeman · April 24, 2024, 8:58pm

Sorry, at a conference and not infringe of PC. So, hard to answer easily.

Topic		Replies	Views
Over the air (OTA) Wireless Updates OpenMV Boards	1	29	August 15, 2024
OpenMV ide firmware update problem OpenMV Boards	1	134	June 16, 2024
Firmware updates OpenMV Boards	10	5150	October 16, 2018
Flashing the firmware using pyopenmv.py, functions not working as intended OpenMV Boards	15	594	November 17, 2021
Custom firmware on OpenMV-H7 OpenMV Boards	3	664	December 16, 2020

openMV RT1062 self firmware update

Related topics