Recent Posts

Pages: [1] 2 3 ... 10
1
µTasker general / Re: Tools that might be of interest to uTasker users
« Last post by mark on April 08, 2025, 01:03:18 PM »
Hi All

If you ever have a difficulty with COM0CO on Windows 11 this link may come in handy:
https://groups.io/g/win4icomsuite/message/4126

Regards

Mark
2
NXPTM M522XX, KINETIS and i.MX RT / Re: Rookie Question: µTasker "SDKs"
« Last post by mark on November 20, 2024, 12:15:50 PM »
Hi

It is possible to enable such functionality in the serial loader or the uTasker application but if you load your won application instead of the uTasker application none of its operation is available as only your application is running.

Therefore you can either implement the application using the uTasker project (use the uTasker project as a framework for your own application code) or you need to develop all functionality needed in your own application (as the loaders do not run in parallel with it).

Regards

Mark
3
Hi

When the serial loader has completed its work the application is started and the serial loader is no longer running - therefore its normal that the upload disk is no longer available.

For the disk to re-appear the application would need to implement the same USB-MSD loader functionality, although this is not practically possible as the application would delete itself during the operation.

Typically the application, when it knows that the loader is needed again, will command a reset to the loader and then the serial loader allows the next update.

Alternatively the application allows new code to be saved to an intermediate area in flash and the BM-loader then updates it at the next reset. This would allow USB-MSD to be used (to load to intermediate memory) if the application can implement its own method.

Regards

Mark
4
NXPTM M522XX, KINETIS and i.MX RT / Re: Connecting over Vcom
« Last post by mark on November 20, 2024, 12:02:52 PM »
Hi

I would try first without RNDIS in case that is causing a problem with its composite configuration.
Also compare the operation withe a reference from https://www.utasker.com/iMX/RT1060.html since these are known to operate correctly.

Regards

Mark
5
NXPTM M522XX, KINETIS and i.MX RT / Rookie Question: µTasker "SDKs"
« Last post by Samuel S on November 15, 2024, 10:15:47 AM »
Hello Mark,

Another Rookie question.  My program has been build using MBDT from NXP and is compiled using Embedded Coder with Simulink, as opposed to MCUXpresso.

I can incorporate SDKs from NXP / MCUXpresso for Vcom capabilities (calling directories, h files and c files), but I'd much prefer to leverage the capabilities of µTasker with the Simulink compiler (MCUCpresso GCC).

Specifically one goal is to have Vcom for UART1 (Freemaster initially and other functions) and RNDIS for Ethernet (to allow XCP on Ethernet over USB-Hardware).

Have I understood correctly, that:
- Vcom and RNDIS need to be defined for the building of:
   - uTaskerBoot_MIMXRT1060.bin
   - uTaskerFallbackLoaderImage_MIMXRT1060.bin
   - uTaskerSerialLoaderUpload_MIMXRT1060.bin
   - uTaskerBootComplete_MIMXRT1060.bin

- To incorporate the Vcom and RNDIS capabilities into my compiled code in Simulink, specific h and c files would need to be called by my compiler

- Or, these capabilities would already be available within the "uTaskerBootComplete_MIMXRT1060.bin" and I would just need to set up Freemaster on UART1 and Ethernet on (initially):
#show_config

IPV4 address = 192.168.1.3
MAC address = 00-00-00-00-00-00
Subnet mask = 255.255.255.0
Default gateway = 192.168.1.1
DNS server = 192.168.1.1
Trusted IP = 0.0.0.0
DHCP CLIENT - disabled
DHCP SERVER - disabled

Apologies if they're dumb questions.

Regards,
Sam
6
Hello Mark,

I've been reading through the examples and documentation but one answer to a question alludes me.

Currently after flashing "uTaskerBootComplete_MIMXRT1060" to my board, "Upload Disk" is available in My Computer. I copy across a program, such as one of the examples "uTaskerCompleteImage_MIMXRT1060_RNDIS_device.bin" or "uTaskerV1.4_AES256_MIMXRT1060.bin" and flashing is successful.  But for further updates "Upload Disk" isn't available.

What do I need to incorporate into my program, so that "Upload Disk" is always available.

My program requires calibration updates and I'd love to use to potential of µTasker.

Regards,
Sam
7
NXPTM M522XX, KINETIS and i.MX RT / Connecting over Vcom
« Last post by Samuel S on November 15, 2024, 09:28:04 AM »
Hello Mark,

Feeling dumb as always.  I'm trying to follow your example below:
https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/iMXRT1062-Ethernet-over-USB/m-p/1440177

I can flash the code to the board without issue and it enumerates as a Vcom and RNDIS device.  Screenshot attached.

But I can't connect to the Debugger as described.  Attached a screenshot from Putty.

I tried with Terraterm but the same results.

I then try to follow the advice in:
https://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf

But after loading "uTaskerSerialLoaderUpload_MIMXRT1060.bin" I see no Com's to connect to.

What am I missing?

Regards,
Sam
8
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


9
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!
10
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
Pages: [1] 2 3 ... 10