Recent Posts

Pages: [1] 2 3 ... 10
Hi All

Here are a few Q.A.s relevant to building the loader using MCUXpresso, especially when building for the i.MX RT 1064 (which has internal QSPI flash at the address 0x7000 0000 instead of the typical 0x6000 0000, used by external QSPI flash (and also the internal QSPI in the i.MX RT 1024).
Note that the full instructions can be found in the document:
The details in the document are believed to be complete and accurate and if followed to the letter there should be no issues but deviating based on assumptions that things should be a little different may lead to failure to obtain a bootable image and so modifying details should be avoided to be sure of quick success.

>>The config.h files have the wrong target set - how does it still work for my target, the i.MX RT 1064?
This pre-processor define for the target board is delivered as an environment variable when building with MCUXpresso and the value in the config.h files is not used (it is greyed out by MCUXpresso when viewed in its editor) and is only used when building with methods that cannot be better automated (such as the VS bat file method which uses the values in the headers and so needs them all set to match).
IMPORTANT: when setting the environment variables they must be set for "All configuration" so that the single setting is valid for all. Never change for just one single target configuration!!

>> The properties in the MCUXpresso properties are for the the wrong processor - why does it still work?
The target is not important for building since the compiler is the same for all ARM7s. It is only relevant when debugging so that the debugger presents the correct peripheral registers view (if ever used). It won't harm setting to match the exact chip but is usually not needed.

>>I use a processor with double-precision processor but the project is set for single-precision - why does it still work?

The FPU is probably not used by the loaders (as there is no calculations in the code that need it) and it could be set to single, double or SW to result in the same outcome on most parts (if optimised for the processor's capabilities calculations using FPU may be slightly faster but wouldn't be noticeable).
This is left by default at "single" so that it run on the i.MX RT 1011 as well (which has single precision HW). If it were set to double as default there could be an issue for i.MX RT 1011 users in case the compiler did make use of the FPU and it could result in such users experiencing hard-faults when the code tried to execute if this setting were not explicitly set to single or SW methods.
Since the FPU setting and use is not really relevant it is simpler to just default to single so it can always be used successfully and not cause potential loss of time if were an exception needed by just some.
If the target processor has double precision FPU it can of course be set to that.

>> The uTaskerBoot linker is set to to iMX_RT_1064_FlexSPI_NOR.ld as per the instructions but the loader fails.
The 1064 has one single exception due to its internal memory layout and that is to set this file ONLY to the BM-loader. The serial loaders are linked to run in RAM (so that they can program the Flash) and so ALWAYS (irrespective of the processor) MUST be left as iMX_RT_10XX_FlexSPI_NOR_BOOT.ld. This locates to RAM and doesn't use Flash - therefore its flash setting (0x6000 0000) is not relevant and is left as the one that matches the majority of processors.

The names of the linker scripts reflect their intention
iMX_RT_1064_FlexSPI_NOR.ld <- 1064 means specifically for this part
iMX_RT_1064_FlexSPI_NOR.ld <- NOR means booting/running from NOR flash

iMX_RT_10XX_FlexSPI_NOR_BOOT.ld <- 10xx means suitable for any 10xx part (including 1064)
iMX_RT_10XX_FlexSPI_NOR_BOOT.ld <- BOOT means suitable for operation with the BM-boot loader (i.e. located in RAM)

The BM-loader (primary loader) is configured to use
by default, which is already suitable for any other i.MX RT 10xx parts and this change is ONLY needed by the i.MX RT 1064.



Hi, Mark

Thanks a lot for your suggestion. The project is able to compiled successfully now (with target"uTaskerV1.4" as you recommend). So, I will try to flash FRDM-K64 board and see how it will go.
NXPTM M522XX, KINETIS and i.MX RT / Re: Can't compile uTaskerV1.4 on Keil uVsion 5
« Last post by mark on May 15, 2024, 02:25:02 PM »

I believe that newer versions of the KEIL compiler have become more GCC compatible and they removed the instrinsic __wifi().

In kinetis.c change

#define __sleep_mode()        __wfi()


#define __sleep_mode()        __asm__("wfi")

If this also doesn't work disabled SUPPORT_LOW_POWER in config.h as the instruction is only needed when using the processor's wait mode (to save power when the core has nothing to do).

I see that you are building the target "uTaskerV1.4-BM". This target works together with the uTasker boot loader so it may be easier for you to start with the "uTaskerV1.4" target [you can select the target to be built in the IDE] instead otherwise you will need to build and install the loader before you can test some operation.


I am just starting to use utasker for my class as supplementary tool for students. Hopefully this tool will help students to gain some more understanding about Arm programming. So, I am trying to get familiar with utasker which seems not to be an easy job. Anyway, currently I try to use Keil uVision 5 to build uTaskerV1.4 which is downloaded from I've followed the instruction in "Kinetis Compiler/IDE Information" page ( and also from youtube "uTasker SHORT Getting Started - From GIT to KDS build" ( Then, when I build the project there will be an error message about ".\Objects\uTaskerV1_4_BM.axf: Error: L6218E: Undefined symbol wfi (referred from kinetis.o)." The following message is output when I build the project in Keil uVision 5:

Rebuild started: Project: uTaskerV1.4
*** Using Compiler 'V6.18', folder: 'C:\Keil_v5\ARM\ARMCLANG\Bin'
Rebuild target 'uTaskerV1.4-BM'
compiling eth_drv.c...
compiling can_drv.c...
compiling SSC_drv.c...
compiling GlobalTimer.c...
compiling iic_drv.c...
compiling low_power.c...
compiling uFile.c...
compiling uNetwork.c...
compiling USB_drv.c...
compiling Tty_drv.c...
compiling uMalloc.c...
compiling Watchdog.c...
compiling dhcp.c...
compiling arp.c...
compiling uTasker.c...
compiling dns.c...
../../../uTasker/Driver.c(948): warning: implicit conversion from 'unsigned long' to 'float' changes value from 4294967295 to 4294967296 [-Wimplicit-const-int-float-conversion]
        if (floatToConvert >= (unsigned long)0xffffffff) {
                           ~~ ^~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
compiling Driver.c...
compiling Ethernet.c...
compiling ftp.c...
compiling icmp.c...
compiling http.c...
compiling ip_utils.c...
compiling ip.c...
compiling time_keeper.c...
compiling NetBIOS.c...
compiling pop3.c...
compiling snmp.c...
compiling ppp.c...
compiling smtp.c...
compiling tcp.c...
compiling telnet.c...
compiling tftp.c...
compiling udp.c...
compiling webutils.c...
compiling zero_config.c...
compiling igmp.c...
compiling ftp_client.c...
compiling application.c...
compiling KeyScan.c...
compiling debug.c...
compiling usb_application.c...
compiling modbus_app.c...
compiling snmp_mib_handlers.c...
compiling webInterface.c...
compiling NetworkIndicator.c...
compiling FreeMaster.c...
compiling nRF24201.c...
compiling MODBUS.c...
assembling kinetis_asm.s...
compiling GLCD.c...
compiling LCD.c...
compiling mass_storage.c...
compiling kinetis.c...
.\Objects\uTaskerV1_4_BM.axf: Error: L6218E: Undefined symbol wfi (referred from kinetis.o).
Not enough information to list image symbols.
Not enough information to list load addresses in the image map.
Finished: 2 information, 0 warning and 1 error messages.
".\Objects\uTaskerV1_4_BM.axf" - 1 Error(s), 1 Warning(s).
Target not created.
Build Time Elapsed:  00:00:04

I use Arm compiler version 6, and already modify parameter in "Asm" Tab and "Linker" Tab in "Option for Target" of uVision's project accordingly (I use FRDM-K64F Board). It seems like the linker can't found "__wfi()" in "". I am not sure whether this error is from unsupport feature of ARMv7 or not (I guess). Can u suggest about how to solve this problem ?

The fall-back loader is intended mainly as a loader to install new serial loader versions. It can be started from the application using the "fboot" command or from the serial loader using the "fb" command.
If the serial loader were corrupted (check-sum or authentication is invalid) it will behave as if it is not available and start the fall-back loader so that an un-corrupted version can be loaded.
Typically the primary loader is configured to start the fall-back loader if it has counted 16 watchdog resets:
- that means that there is a serial loader (or more likely) an application that is failing (possibly not allowing the serial loader to be commanded)
- after the failure has taken place 16x (if an application had been loaded that almost immediately hard faults due to a certain error were loaded it would watchdog reset every few seconds) the boot loader will start so that the user has the opportunity to load a new serial loader version
- the fall-back loader will typically automatically start the serial loader after 15s, thus giving the user the opportunity to load a new application
- the serial loader typically times out after 60s (when no activity is taking place) and so the cycle will repeat - the idea is that the user should not need to wait that long before the fall-back and then the serial loaders are automatically offered in such a case


I am reading the test drive document for the Serial Loader:

the doc mentions:
"recovery via serial “Fall-back” loader when a faulty application or a faulty serial loader is installed"

But the doc doesn't describe how this actually happens.   How does uTaskerBoot know to start the fallback loader instead of the serial loader if the serial loader is corrupted?

I see the fallback loader start if the serial loader is missing completely, but how would this work if the serial loader is present, but corrupted or needs to be updated?


Thanks for the reply, I am going to continue trying to get my blhost based reset working with my existing flashloader (based on the NXP mcu-boot project).

I will update here if I have any success.


I don't have experience with using blhost but if the serial loader has been installed into flash I would expect that a reset would cause it to start.

I have, however, worked with the SDP protocol that blhost uses and used the following technique:

1. I build the serial loader using the bat file/make file method which generates and output using (see make_uTaskerSerialBoot_GNU_iMX):

# Create SDP output file and show its size
uTaskerSerialSDP.elf: $(OBJS) $(OBJS2_SDP) iMX_RT_10XX_SDP_BOOT.ld
   $(CC_LNK) $(C_FLAGS) -Os -g -TiMX_RT_10XX_SDP_BOOT.ld -nostartfiles -Xlinker --gc-sections -lm -Wl, -o uTaskerSerialSDP.elf $(OBJS) $(OBJS2_SDP)
   $(CC_OBJ) --only-section=.init --only-section=.text --only-section=.rodata --only-section=.vectors --output-target=binary uTaskerSerialSDP.elf uTaskerSerialSDP.bin
   $(CC_SIZE) uTaskerSerialSDP.elf
   $(CC) -v

This output is suitable for use by loading with the SDP protocol (it is loaded and run in OCRAM)
I think I set this define in config.h
#define CONFIG_SDP_LOADER                                        // build the serial loader to work as a downloaded loader with the NXP serial download protocol

2. The serial loader can be build with any options and the one I use is SREC via USB-CDC

3. When this binary is installed and started (I think it is equivalent to when you load your flashloader and will be suitable for any boards that can run the serial loader since it will be configured with the same flash driver, and can be modified to add more functions such as test functions for production) it runs this serial loader and so appears as a CDC device. Like this the host can load SREC files (in order to install the final serial loader + application into flash) and can be commanded to start with the "go" command.



P.S. I use a second i.MX RT for production programming that uses the SDP protocol via USB (as host) connected to fresh i.MX RTs in their ISP mode. It detects when they enumerate, installs the uTaskerSerialSDP.bin that I generated for the target and starts it. The device then enumerates as USB-CDC and the host sends the SREC interface "bc", "ld", SREC image, "go" commands to install the complete serial loader/application.
At the same time the i.MX RT host controls the bed of nails tester to test the board and program other parts on it.
I have used the technique a number of times in quite large volumes - recently I tested/programmed 1000 boards myself and they all programmed without any glitches.

I am trying to completely automate my dev cycle, using command line sdphost to load the flashloader, then blhost to write the uTasker Serial Loader.  This is instead of using MCU Boot Utility.

I can get the SerialLoader written to flash without issues, but I would like to then cause blhost to jump to execution of the SerialLoader.

I tried following this approach:

It does jump, but the SerialLoader doesn't seem to actually execute correctly, so I must be missing something.

Has anyone tried this with the uTasker SerialLoader?

Here are my commands to try and execute the jump from blhost:
Code: [Select]
../secure_provisioning/blhost -t 5242000 -u 0x15A2,0x0073 -- read-memory 0x60001000 8
Inject command 'read-memory'
Successful response to command 'read-memory'

d1 00 20 41 00 20 00 60

(1/1)100% Completed!
Successful generic response to command 'read-memory'
Response status = 0 (0x0) Success.
Response word 1 = 8 (0x8)
Read 8 of 8 bytes.

Application address:  0x60002000
../secure_provisioning/blhost -t 5242000 -u 0x15A2,0x0073 -- read-memory 0x60002000 8
Inject command 'read-memory'
Successful response to command 'read-memory'

00 c0 2b 20 61 33 00 60

(1/1)100% Completed!
Successful generic response to command 'read-memory'
Response status = 0 (0x0) Success.
Response word 1 = 8 (0x8)
Read 8 of 8 bytes.

Stack pointer:  0x202bc000
Reset vector:  0x60003361
../secure_provisioning/blhost -u 0x15A2,0x0073 -- execute 0x60003361 0 0x202bc000
Inject command 'execute'
Successful generic response to command 'execute'
Response status = 0 (0x0) Success.

NXPTM M522XX, KINETIS and i.MX RT / Re: Set up for ADC on i.MX RT... not getting it.
« Last post by mark on March 21, 2024, 10:41:59 PM »
The ADC interface 'attempts' to be compatible across processors and ADC types so some of the values will not do anything but can be left so that the interface remains operational with those that need them, or react to them.

The calibration flag should only be set once, the first time the interface is called (for each ADC).

The easiest way to learn the interface is to run the main application in Visual Studio and step through the code so that the effect of flags can be seen. The idea is to start with a basic interface that has a certain amount of features, and basic compatibility although the internal workings may not be highly efficient due to this. One can see which paths are used (and needed) and take these into a custom function if speed is important.


Pages: [1] 2 3 ... 10