Re: Windows 7 Loader EXtreme Edition
Ingelore Clason
I have a custom board with USB OTG, and need to boot-load from a USB memory stick (USB host MSD load). As NXP's boot-loader doesn't seem to support this configuration, I'm trying the uTasker boot-loader. My board has no externally connected serial ports. I made a 'blinky' test application, verified it works as a normal application, then built it as a boot-loadable application per the instructions. I configured, built, and installed the boot-loader - all seems OK. But when I insert the USB stick with "software.bin" the stick's LED comes on, briefly blinks off, then stays on - but blinky is never loaded and executed.
Dave
I didn't know that FatFS had exFAT support but I see that it was added in 2016 - three years before Microsoft released the specification - presumably the project developer had insider information or was a member of group with access to it. I read somewhere that there is a charge of $4 per devices using exFAT, payable to Microsoft via a few partner companies that collect it for them, but I don't know whether it is still valid or not.
So that your boot loader will not be restricted I added exFAT read capabilities yesterday to the utFAT that the uTasker loader uses so that I can list the stick content and read its files (I haven't checked very large files yet since I need to add some long long counters to ensure larger data than 4GBytes can be read but I am sure your FW upload won't need that immediately ;-). Also I haven't yet handled the date/time since they use a different format that I need to convert for listing functions - again not important for the loader since it only checks the name).
I'll check in the new support shortly: you just need to add #define UTEXFAT to the utFAT configuration section of config.h to enable the new capability whereby the application (serial loader) itself is not affected.
Below is the listing from my stick (I just added a couple of additional files to its delivered state) in the root directory. [Tested in the uTaskerV2.0 application since it supports testing various functions of the interface - also supporting the same on exFAT formatted SD cards].
Regards
Mark
Disk interface
===================
up go to main menu
info utFAT/card info
dir [path] show directory content
dird [path] show deleted directory content
dirh [path] show hidden content
infof [path] show file info
infod [path] show deleted info
cd [path] change dir. (.. for up)
comp compare [file1] with [file2]
file [path] new empty file
write [path] test write to file
mkdir new empty dir
rename [from] [to] rename
trunc truncate to [length] [path]
copy [file1] to [file2]
hide [path] file/dir to hide
unhide [path] file/dir to un-hide
prot [path] file/dir to write-protect
unprot [path] file/dir to un-protect
print [path] print file content
del [path] delete file or dir.
format [-16/12] [label] format (unformatted) disk
fformat [-16/12] [label] full format (unformatted) disk
re-format [-16/12] [label] reformat disk!!!!!
re-fformat [-16/12] [label] full reformat disk!!!!!
sect [hex no.] display sector
sectw [hex no.] [offset] [val] [cnt]
help Display menu specific help
quit Leave command mode
>info
Hi Mark - I finally ready to get back to the bootloader. I've just now finished hardware qualification of my board (for which I had to recode some buggy FSL stuff - grrrrrr). From your replies above I think the fixes to your bootloader I need are:
Hi Mark - Unfortunately still no joy.
I updated my application build to create a bootloadable image and it works AOK with the slow stick.
The fast stick goes into an infinite loop.
Here's what I did to try get the fast stick working:
Testing has shown one annoying behavior you may want to fix (though not urgent). If there is no software image already loaded and the user inserts a USB stick without a new image, when the user realizes (ooops wrong stick) and removes it, your code doesn't move back to the "no USB stick" state. Thus a power-cycle is required. Not a big deal but especially annoying on my sensorbox with its built in UPS, it needs to be unplugged for a minute!
Dave
>>restarting again with stick reloads application and starts it
In this case it is verifying that the code matches the loaded one and starts it (also if the source on the drive is stored in encrypted form) - it doesn't reload it again since that takes longer and would "wear out" the QSPI over time.
In the case of the stick that is not enumerating that doesn't show any information about the enumeration process it is not something that I have experienced and the reason is only visible with the debugger or with a USB analyser. It may be something trivial since the enumeration is carried out only on EP0 and is not dependent on what the device does later - the enumeration sequence is always the same - a few descriptors are requested and then the details are shown:
Please can you confirm that this is the one I would need to order?
-extreme-pro-128-gb-usb-a-usb-stick-6073315?ip=SANDISK+E...
The utFAT used is FAT12/16/32. I was told by someone that they could work with exFAT formatted drives (although files > 4GBytes can't be worked with) but I was surprised but never checked myself.
If you could format the drive that works as exFAT instead of FAT you could check whether it is true or not.
doesn't allow bus operation with this particular stick.
Notice that I had an error in the code since the masking of the field was not correct since it was masking with 0xc instead of with 0xf but, as noted, this difficulty was never experienced with any other device and so was "hidden".
which in fact 'recommends' the use of 0x10000007 and not 0x1006060c as used by the SDK and also your project code. Those values are, according to this, potentially not certifiable.
I then checked in the MIMXRT1060 user's manual and find that other values are recommended there:
Does your project contain an exFAT implementation so that your embedded code can work with the stick?
Also, do you know the details about licensing exFAT since, although the specification for it has been open since 2019 [ -us/windows/win32/fileio/exfat-specification] it looks like it needs either royalty payments to Microsoft or membership of OIN (open invention network)?
Regards
Mark
I use the widely-used Chan's FatFs, which supports exFAT. I've been using this for decades, in many successful projects (also boot-loaders for PIC32, etc.). In my current RT1024 project I've already done through-put tests writing very large data-logs to the fast (exFAT-formatted) USB stick. Works just fine (and fast enough for my logging requirements).
Hope that helps!
And when I get back I have a lot of work to do (like rework NXP's astonishingly bad LPSPI driver so it properly manages CS signals and byte ordering, which I must do to get my application working reliably)...
Hi @mjbcswitzerland - I made an in-memory buffer for the diagnostic messages (in uTasker/Driver.c function fnDebugMsg),
and attached to the running process to see the results.
Looks like some kind of error occurred while mounting the memory stick.
Here's what I see in the debug log (stick inserted before bootloader started):
I loaded the serial loader (with UART enabled) onto the MIMXRT1024-EVK. The LED doesn't flash since you have moved it but I could load your application and it ran (I don't see it blinking since it is on a different port) but when I connect with a debugger it is in a loop in valid XiP flash range.
which is a USB stall due to the memory stick not supporting a certain MSD command. There is indeed a USB error due to the stall but it is normal and recovers with the endpoint clear (a method used by the USB protocol).
The actual error that you have is when the mass storage module (utFAT) tries to mount the stick and performs sector reads. It uses utReadMSD() (in usb_host_loader.c) to issue read commands but there is no answer within the expected time limit:
I think I remember having a stick once that wouldn't read until I enabled SKIP_READ_FORMAT_CAPACITY but it worked fine with Windows. When I checked the windows behavior it also didn't issue the READ_FORMAT_CAPACITY - possibly because they know that it can cause issues(?).
To remove all serial mode support in the loader simply comment out
#define SERIAL_INTERFACE
This will remove the LPUART driver and all modes that are associated with the serial interface (and all debug output via UART).
since this will cause the loader to always start and always jump to the application after checking. As you don't have any GPIO to control this it may be that the ones used are causing the RETAIN_LOADER_MODE() to stay in the loader and not start your application (for example).
since you have moved it to port 3.
This is in fact a potentially serious error since the watchdog task will be writing to a non-initialised port and it may result in a hard fault.
Note that when the serial loader is running its heartbeat LED is expected to be flashing at 5Hz and not remain static.