Recent Posts

Pages: [1] 2 3 ... 10
1
USB / Re: USB MSD data corruption MK20DX256VLH7
« Last post by mark on October 06, 2024, 01:44:40 AM »
Hi

Sorry that I didn't see this post until now.

I don't know why this would happen but it is due to the file object, which is written after loading a new FW, being corrupted. Potentially it was written correctly but later overwritten, causing some values to be modified.

Attached is the latest version of usb_device_loader.c which was modified with this change quite some time ago:
16.01.2017 Check valid file and display for delete if random data    {33}

You will see that it uses
fnCheckFileObject() to verify that the file object is not corrupted and will, if it finds it to be bad, display a file called "UNKNOWN.BIN" with a size matching the application area (instead of trying to display the content according to teh fiel object itself).

This allows the user to do a delete of the file (cleans the application area) and then load the FW (again).

The problem with a corrupted file object can also be that multiple strange files of seemingly random lengths are found and it may otherwise not be possible to delete them to clear it up. This check and the "UNKNOWN-BIN" method ensures easy recovery.

This doesn't help with a source of corruption itself though.

Regards

Mark


2
USB / USB MSD data corruption MK20DX256VLH7
« Last post by Alex1982 on September 24, 2024, 08:27:51 AM »
Hello Mark,

Some customers are experiencing issues with USB-MSD firmware updates (flash drive emulation mode). The MK20DX256VLH7 appears as a drive, as expected, but it shows a file with a seemingly random name and a size of over 3GB.

Attached are screenshots from two different customers illustrating the issue.

Have you encountered this type of problem before, and can you recommend any solutions to resolve it?

Thank you!
3
NXPTM M522XX, KINETIS and i.MX RT / Reliable reset of (iMX RT) FlexRAM during SW reset
« Last post by mark on September 06, 2024, 11:50:57 AM »
Hi All

As you are probably aware, the uTasker project typically uses FlexRAM for optimal speed efficiency and divides the FlexRAM into ITC (Instruction Tightly Coupled) for code location and DTC (Data Tightly Coupled) for variables. The FlexRAM partitioning is performed automatically in this mode when the boot loader starts the serial loader or application (when running in RAM).

During intensive testing of SW and watchdog resets it was identified that returning the FlexRAM back to its default configuration was not always guaranteed since this has to be done during the reset command and is not performed automatically in HW during reset. This happened maybe once every 1000 resets or so and is almost certainly due to the fact that the chip's ROM loader - which starts the boot up sequence - fails when OCRAM (general purpose configuration) is disabled during the partitioning (tests where an OCRAM bank was left as it was by default didn't suffer from the issue) and couldn't be returned reliably during the reset operation.

A solution to this, which was tested positively in a long term test of continuous SW and/or watchdog resets, has been added that is recommended to ensure that a board can't remain in an undefined state after a commanded or watchdog reset, noting that it is generally recommended to use an external power-cycling circuit to also capture any potential hanging situation - see https://www.utasker.com/docs/iMX/uTasker_iMX_WDOG.pdf

1. In the bare-minimum (primary) boot loader a routine has been added that can reliably return the FlexRAM settings to their defaults and command reset (the bare-minimum loader operates directly from QSPI flash and can, thus, do this easily.

Code: [Select]
static void fnRestoreFlexRAM(int iReset)
{
    IOMUXC_GPR_GPR16 = IOMUXC_GPR_GPR16_DEFAULT;                         // set the FlexRAM layout back to that taken from the eFuse setting (default configuration)
    if (iReset != 0) {
        APPLICATION_INT_RESET_CTR_REG = (VECTKEY | SYSRESETREQ);         // request cortex core reset, which will cause the software reset bit to be set in the mode controller for recognition after restart
    }
}
2. The location of this routine is added to its Flash configuration, which means that it is - for i.MX RT 10xx parts - at a fixed address of 0x200 offset from the start of QSPI flash:
Code: [Select]
const FLEXSPI_NOR_BOOT_CONFIGURATION __attribute__((section(".boot_hdr.conf"))) __boot_config
= {
    ....
    (unsigned long)fnRestoreFlexRAM                                      // insert the address of a routine that can be called to return the FlexRAM back to default settings and reliably reset the device
};
3. The general SW reset function now uses this call (when it exists) to ensure reliable resets:

Code: [Select]
// This routine is called to reset the processor
//
extern void fnResetBoard(void)
{
#if !defined iMX_BOOTLOADER
    uDisable_Interrupt();
#endif
#if (!defined iMX_BOOTLOADER && !defined NO_STACK_RESET)
    fnStackReset(1);                                                     // {7} if the boot loader supports this method the code will not return
#endif
    APPLICATION_INT_RESET_CTR_REG = (VECTKEY | SYSRESETREQ);             // request cortex core reset, which will cause the software reset bit to be set in the mode controller for recognition after restart
    IOMUXC_GPR_GPR16 = IOMUXC_GPR_GPR16_DEFAULT;                         // set the FlexRAM layout back to that taken from the eFuse setting (default configuration) - although the reset is commanded before executing this line it still operates and avoids the RAM layout being changed when the code is still running
}
and the watchdog interrupt also uses it:

Code: [Select]
// If the watchdog fires this interrupt is called 255 clock cycles before the watchdog reset actually takes place
//
static __interrupt void wdog3_irq(void)
{
    __disable_interrupt();
    #if !defined NO_STACK_RESET
    fnStackReset(0);                                                     // {7} if the boot loader supports this method the code will not return
    #endif
    IOMUXC_GPR_GPR16 = IOMUXC_GPR_GPR16_DEFAULT;                         // set the FlexRAM layout back to that taken from the eFuse setting (default configuration)
    FOREVER_LOOP() {}
}
in both cases as long as the user expressly disables it with
#define NO_STACK_RESET

4. As can be seen from the fnStackReset() code it first checks that the bare-minimum loader does have valid code and so it will use the original technique in case it doesn't.

Code: [Select]
// This routine calls a routine in QSPI flash that reconfigures the FlexRAM back to its default and then conditionally commands a core reset
//
extern void fnStackReset(int iReset)
{
        #if defined SECURITY_OTFAD
    void (*_fnCode)(int) = (void (*)(int))(*(unsigned long *)(FLEXSPI_FLASH_BASE + 0x600)); // fixed location in QSPI flash of code to be executed
        #else
    void (*_fnCode)(int) = (void (*)(int))(*(unsigned long *)(FLEXSPI_FLASH_BASE + 0x200)); // fixed location in QSPI flash of code to be executed
        #endif
    if (((unsigned long)_fnCode < FLEXSPI_FLASH_BASE) || ((unsigned long)_fnCode > (FLEXSPI_FLASH_BASE + 0x8000))) {
        return;                                                          // no valid code exists
    }
    _fnCode(iReset);                                                     // execute (doesn't return but either reset or wdog reset will restart the processor after the flexRAM has been set to default)
}
It is recommended that the bare-minimum loader uses this code (included in recent check-ins) and serial loader and applications the new SW reset and watchdog interrupt code to ensure reset reliability when using code from RAM operation.

Regards

Mark
4
NXPTM M522XX, KINETIS and i.MX RT / Tips when building Loader with MCUXpresso (especially for i.MX RT 1064)
« Last post by mark on June 18, 2024, 03:26:09 PM »
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: https://www.utasker.com/docs/iMX/MCUXpresso.pdf
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
iMX_RT_10xx_FlexSPI_NOR.ld
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.


Regards

Mark


5
NXPTM M522XX, KINETIS and i.MX RT / Re: Can't compile uTaskerV1.4 on Keil uVsion 5
« Last post by BangkokUni on May 15, 2024, 02:31:59 PM »
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.
6
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 »
Hi

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()

to

#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.

Regards

Mark
7
NXPTM M522XX, KINETIS and i.MX RT / Can't compile uTaskerV1.4 on Keil uVsion 5
« Last post by BangkokUni on May 15, 2024, 12:10:34 PM »
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 https://github.com/uTasker/uTasker-Kinetis. I've followed the instruction in "Kinetis Compiler/IDE Information" page (https://www.utasker.com/kinetis/compilers.html#KEIL) and also from youtube "uTasker SHORT Getting Started - From GIT to KDS build" (https://www.youtube.com/watch?v=K8ScSgpgQ6M&t=311s). 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...
linking...
.\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 "kinetis.co". 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 ?
8
NXPTM M522XX, KINETIS and i.MX RT / Re: reinstalling serial loader with fallback loader, how to start fallback loader?
« Last post by mark on April 07, 2024, 11:53:28 PM »
Hi

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

Regards

Mark
9
NXPTM M522XX, KINETIS and i.MX RT / reinstalling serial loader with fallback loader, how to start fallback loader?
« Last post by jackking on April 07, 2024, 03:42:12 PM »
I am reading the test drive document for the Serial Loader: https://www.utasker.com/docs/iMX/uTaskerLoader_TestDrive.pdf

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



10
NXPTM M522XX, KINETIS and i.MX RT / Re: Jumping to SerialLoader from flashloader (blhost)?
« Last post by jackking on April 07, 2024, 03:37:27 PM »
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.

Pages: [1] 2 3 ... 10