Trouble configuring uTasker bootloader for RT1024

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Trouble configuring uTasker bootloader for RT1024

2,557 Views
davenadler
Senior Contributor I

No doubt I've missed something...

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.

Some basic questions:

  1. I didn't find any way to disable all serial communications in uTaskerSerialBoot\config.h.
    Do I need to do this? If so, how?
  2. Is there a way to configure "serial loader" to report (printf) step-by-step diagnostics to a file on the USB stick? That's how I debugged the last bootloader I had to implement for a no-serial board.

Excruciating details of my configuration and test in the attached PDF, along with the relevant configuration files.

@mjbcswitzerland- any help much appreciated!

Thanks!
Best Regards, Dave

Labels (1)
Tags (1)
0 Kudos
25 Replies

1,846 Views
mjbcswitzerland
Specialist V

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


Hello, world... MIMXRT1060 [Software 2]
Unique ID: 0x65f82946453849d2-500000ff
01.01.1970 00:00:08
Static memory = 0x000011a0
OS Heap use = 0x00000449 from 0x0002b000
Initial stack margin 0x0003bcb0
FlexRAM:
3 Code banks [0x00000000..0x00017fff]
13 Data banks [0x20000000..0x20067fff]
SPI Flash: ISSI 8MByte IS25LP064A
uFileSystem integrity
Granularity: 0x0001c000
Start: 0x600a0000
End: 0x607d3fff
uFileSystem size = 0x00734000
OK
USB DEVICE HOST
USB (1) HS device detected
USB device information ready:
USB2.0 device with 64 byte pipe
Vendor/Product = 0x0781/0x5588
Manufacturer = "SanDisk"
Product = "USB Extreme Pro"
Serial Number = "14A45679AE36"

Self-powered device with 1 interface(s)
Interface 0
Mass Storage Class : Sub-class = 0x06 interface protocol = 0x50
Endpoints:
1 = BULK IN with size 512
2 = BULK OUT with size 512
Enumerated (1) [1]
LUN = 1
UFI INQUIRY -> Enumerated (0) [1]
Status transport - Passed
UFI REQUEST SENSE -> Status transport - Passed
UFI FORMAT CAP. -> H:1 0x02008140 0xf0406001 0x02008100
HS USB error - 1
Stall (1) on EP-1
IN (1) EP-1 cleared
Status transport - UFI FORMAT CAP. -> H:1 0x82008140 0xf0406001 0x82008100
HS USB error - 1
Stall (1) on EP-1
IN (1) EP-1 cleared
Status transport - UFI FORMAT CAP. -> H:1 0x82008140 0xf0406001 0x82008100
HS USB error - 1
Stall (1) on EP-1
IN (1) EP-1 cleared
Status transport - UFI READ CAP. -> (512:250085375) Status transport - Passed
Mem-Stick mounting...
Disk E mounted

Serial number: 00
Software version V2.0.000
Device identification: uTasker Number 1

Main menu
===================
S         Configure serial interface
I         Go to I/O menu
A         Go to administration menu
O         Go to overview/statistics menu
U         Go to USB menu
u         Go to utFAT disk interface
help      Display menu specific help
quit      Leave command mode
u


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

Disk (125042687 kBytes) FATex
Bytes per sector: 512
Cluster size: 524288
Directory base: 0x00010800
FAT start: 0x0000c000
FAT size: 0x00000800
Number of FATs: 1
LBA: 0x0000c800
Total clusters: 0x0003b9c0
Info sect: 0x00000000
Free clusters: 0x00000000
Next free: 0x00000000
>dir
Directory E:\

---A 00.00.1980 00:00          8600360 SanDiskSecureAccessV3.01_win.exe
---- 00.00.1980 00:00 <DIR>            SanDiskSecureAccess
---A 00.00.1980 00:00        225888525 Firmware_Packet_V1.03.152.zip
---A 00.00.1980 00:00             8739 left.txt
---A 00.00.1980 00:00             8739 right.txt
4 files with 234506363 bytes
1 directories, 134215168 kBytes free
E:\>

0 Kudos

1,457 Views
davenadler
Senior Contributor I

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:

  1. increase timeout time constant to support old slow USB sticks (done),
  2. fix initialization of USB peripheral to correctly support new USB sticks,
  3. incorporate updates to support exFAT

I've done the first. What's the most efficient way to get the remaining fixes?

Thanks!
Best Regards, Dave

0 Kudos

1,440 Views
mjbcswitzerland
Specialist V

Dave

I have taken your advice and am in the process of fully implementing exFAT. The uTasker utFAT V2.1 document (not yet released) is here:
https://www.utasker.com/docs/uTasker/uTasker_utFAT_2.1.pdf
where exFAT technical details are being worked on in chapter 16.

exFAT read compatibility is fairly simple as long as unicode support is not needed in full (with ASCII / English names are no problem).
As seen from the technical details there are some interesting extensions (although not all necessary) but I am working through all of these to be sure of the best implementation and may be able to wrap up all write support shortly.

Since you don't need write support I expect that you will have no problems using this intermediate package:
https://www.utasker.com/software/utFAT/utFAT2.10.zip
Just overwrite the two files in the uTasker\utFAT director and enable exFAT support with
#define UTEXFAT // support also exFAT
in your config.h.

I think the serial loader doesn't need any other changes.

Good luck

Regards

Mark



0 Kudos

1,338 Views
davenadler
Senior Contributor I

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:

  1. exFAT support added:
    1. replaced mass_storage.c/h with the new versions you sent
    2. in C:\uTasker-GIT-Kinetis\Applications\uTaskerSerialBoot\config.h
      add line 1800: #define UTEXFAT
  2. USB power setting bug in uTasker USB stack corrected:

    1. "C:\uTasker-GIT-Kinetis\Hardware\Kinetis\kinetis_USB_HS_OTG.h"
      replace line 2121 with:
      phy->USBPHY_TX = (USBPHY_TX_EDGECTRL_VALUE | USBPHY_TX_RSVD1_VALUE | USBPHY_TX_TXCAL45DP_VALUE | // DRN: Correction per Mark Butcher
      USBPHY_TX_TXCAL45DN_VALUE | USBPHY_TX_DCAL_VALUE); // DRN: Correction per Mark Butcher

    2. When that did not work I tried the value 0x1006060c as that works in my application

The diagnostics (read from my in-memory buffer by connecting to the running bootloader):

 

No Application found in flash!!
No Application found in flash!!
USB HS device detected
USB device information ready:
USB2.0 device with 64 byte pipe
Vendor/Product = 0x0781/0x5588
Manufacturer =  \"SanDisk\"
Product = \"USB Extreme Pro\"
Serial Number = \"12A4567989D6\"

Self-powered device with  1 interface(s)
Mass Storage Class : Sub-class = 0x06 interface protocol = 0x50
Endpoints:
1 = BULK IN with size 512
2 = BULK OUT with size 512
Enumerated (1)\n\rLUN = 1
UFI INQUIRY -> Status transport - Passed
UFI REQUEST SENSE -> Status transport - Passed
UFI FORMAT CAP. -> H:1 0x02008140 0xf0406001 0x02008100
HS USB error - 0
Stall on IN EP-1
Cleared IN EP-1
Status transport - UFI FORMAT CAP. -> H:1 0x82008140 0xf0406001 0x82008100
HS USB error - 0
Stall on IN EP-1
Cleared IN EP-1
Status transport - UFI FORMAT CAP. -> H:1 0x82008140 0xf0406001 0x82008100
HS USB error - 0
Stall on IN EP-1
Cleared IN EP-1
Status transport - UFI READ CAP. -> (512:250085375) Status transport - Passed
Mem-Stick mounting...
*H:1 0x82008140 0xf0406001 0x82008100
HS USB error - 0
 TOD Timeout!
Stall on IN EP-1
Cleared IN EP-1
H:1 0x02008140 0xf0406001 0x02008100
HS USB error - 0
Stall on IN EP-1
Cleared IN EP-1
H:1 0x02008140 0xf0406001 0x02008100
HS USB error - 0
Stall on IN EP-1
Cleared IN EP-1
H:1 0x02008140 0xf0406001 0x02008100
HS USB error - 0
Stall on IN EP-1
Cleared IN EP-1
H:1 0x02008140 0xf0406001 0x02008100
HS USB error - 0
Stall on IN EP-1
Cleared IN EP-1
H:1 0x02008140 0xf0406001 0x02008100
HS USB error - 0
Stall on IN EP-1
Cleared IN EP-1
H:1 0x02008140 0xf0406001 0x02008100
HS USB error - 0
Stall on IN EP-1
Cleared IN EP-1
H:1 0x02008140 0xf0406001 0x02008100
HS USB error - 0
Stall on IN EP-1
Cleared IN EP-1
H:1 0x02008140 0xf0406001 0x02008100
HS USB error - 0
Stall on IN EP-1
Cleared IN EP-1
H:1 0x02008140 0xf0406001 0x02008100
HS USB error - 0
Stall on IN EP-1
Cleared IN EP-1
H:1 0x02008140 0xf0406001 0x02008100
HS USB error - 0
Stall on IN EP-1

Any ideas? What have I missed?

Thanks!
Best Regards, Dave

 

0 Kudos

1,329 Views
mjbcswitzerland
Specialist V

Dave

I have been working on the application and USB2 Host on an i.MX RT 1062 and didn't have any issues with that particular stick. I'll test the application and also the serial loader on the 1024 to see whether I can detect a difference. I'll also send you the application (which has the complete interface which allows analysing the file objects, depending on file system type - see the utFAT guide for details of its advanced functions).

One thing that that you could try, in the meantime, is the following:
In utReadMSD() you will find this

fnDebugMsg("*");
fnSendMSD_host(UFI_READ_10); // request the read (and enable IN polling for the read data)
#if defined _iMX_
fnDelayLoop(1000); // "temporary" to ensure the command was sent before starting an IN
#endif

The "*" can be seen in your log, showing that the stick sent back a stall when the first UFI_READ_10 was commanded to it.
Note that this "temporary" test with the delay loop is commented out. Could you comment it in by changing _iMX_ to _iMX since this is the only 'quick' modification that 'may' show a difference?

Regards

Mark


0 Kudos

1,319 Views
davenadler
Senior Contributor I

Hi Mark - With your above fix I finally can bootload off the fast stick.

Only remaining task I have to use the bootloader is display status by blinking a status indication pattern on a couple of external LEDs. I think I understand that to do this I'll need to:

  • Add a blinky task with a state machine to run the LEDs based on a published global state flag.
  • change the #define _DISPLAY_xxx macros to set the global state flag

I looked but did not find an example blinky task showing task table entry and sample state machine. Do you have such an example? If not not a big task...

Thanks for all the help,
Best Regards, Dave

0 Kudos

1,313 Views
mjbcswitzerland
Specialist V

Hi Dave

I am pleased that the fix worked - I don't know why that stick needs it but I will try to reproduce your original behavior without the fix and investigate a little more.

For the LED control you may be able to use the existing watchdog task

extern void fnTaskWatchdog(TTASKTABLE *ptrTaskTable) // watchdog called regularly
{
fnRetriggerWatchdog(); // hardware dependent
#if defined USER_WATCHDOG_FUNCTION
USER_WATCHDOG_FUNCTION();
#endif
}

The serial loader calls this at a 100ms rate, so that the watchdog is triggered regularly and the fnRetriggerWatchog() function is typically used to also toggle an LED:

TOGGLE_WATCHDOG_LED(); // optionally flash a watchdog (heart-beat) LED

This can be made an empty macro if not desired.

Notice that if you define the macro

USER_WATCHDOG_FUNCTION()

to a function that you provide it will be called every 100ms and you could use that to set multiple LEDs with different colors, etc. based on states that you would like to display (in fact the same is true of you define TOGGLE_WATCHDOG_LED() to be a function call of the code that you want to use).

In case you prefer to add a new task of your own you can get details in https://www.utasker.com/docs/uTasker/uTaskerV1.4_user_guide.PDF

To control GPIOs see the defines in app_hw_iMX.h for examples of configuring and toggling for various targets. This forum entry lists the GPIO macros that are easy to use and portable: https://www.utasker.com/forum/index.php?topic=1875.0
This video also explains the GPIO concept and how it is implemented in the uTasker project: https://youtu.be/SmFTi8hlba0

Regards

Mark

0 Kudos

1,265 Views
davenadler
Senior Contributor I

Thanks Mark - I implemented a separate task for status display and redefined the _DISPLAY_xxx macros so that's all set. Everything is now working OK.

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!

Thanks again for the help Mark!
Best Regards, Dave

PS: I've attached my notes (including the bug-fixes) in case anyone else wants to give this a try...

0 Kudos

2,365 Views
davenadler
Senior Contributor I

Hi Mark - I should have mentioned:
Both USB sticks I am testing with work fine on this hardware using tinyUSB.

The infinite loop I see is different from what you mention above and happens even if the USB stick is already plugged in when boot-loader started:

USB HS device detected
USB device removed
Mem-Stick unmounted
USB HS device detected
...

I will increase the time-out delay and see if the slow stick will mount.
Still need to find out why the fast stick goes into an infinite loop...

Thanks,
Best Regards, Dave

0 Kudos

2,365 Views
davenadler
Senior Contributor I

@mjbcswitzerland- Some success!
I increased the #define MAX_USB_MSD_READ_WAIT timeout by a factor of 10 and now blinky boot-loads and runs. Yay
Also:
- restarting board with no stick present shows boot-loader correctly branch into the application.
- restarting again with stick reloads application and starts it

Now - What to do about the fast stick that doesn't work?
It's a SanDisk ExtremePro 128GB with exFAT file system (again, works fine on this hardware with tinyUSB).

Thanks Mark!

 

0 Kudos

2,359 Views
mjbcswitzerland
Specialist V

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:

USB device information ready:
USB2.0 device with 64 byte pipe
Vendor/Product = 0xcd12/0xef18
Manufacturer = "USB "
Product = "DISK "
Serial Number = "0482DE22941182E"

Bus-powered device (max. 100mA) with 1 interface(s)
Mass Storage Class : Sub-class = 0x06 interface protocol = 0x50
Endpoints:
2 = BULK OUT with size 512
2 = BULK IN with size 512
Enumerated (1)

after which I would expect any special behavior to start.


The enumeration is controlled by fnHostEnumeration() in USB_drv.c which is generic for ever possible device.
You could add your debug output to there to see how often it is called and how the state-event machine progresses to get an idea of whether it aborts somewhere due to unexpected behavior.

If you have a USB analyser you could send a recording of an operating case and a failed case.

Regards

Mark



0 Kudos

2,315 Views
davenadler
Senior Contributor I

@mjbcswitzerland Any chance you could get one of these sticks and have a look?
Also, you do support exFAT, right?
Thanks!

0 Kudos

2,309 Views
mjbcswitzerland
Specialist V

Please can you confirm that this is the one I would need to order?

https://www.digitec.ch/de/s1/product/sandisk-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.

Regards

Mark

 

0 Kudos

2,284 Views
davenadler
Senior Contributor I

Yes that's exactly the drive. I'm using them because of speed and capacity (for the data-logging in this project). I'm a bit concerned about the power consumption though; they get warm...

0 Kudos

2,282 Views
mjbcswitzerland
Specialist V

OK. I ordered one and should be able to test it on Tuesday.

0 Kudos

2,156 Views
mjbcswitzerland
Specialist V

Dave

I received the drive and did a first quick measurement with my USB analyser and MIMXRT1024EVK running the MSD-host:

1. A typical HW device connection:

mjbcswitzerland_1-1709139309951.png

seen when connecting various devices (memory sticks, mobile phones, serial cables, wifi modules, etc.)

2. Connecting this stick (which otherwise behaves as you have described)

mjbcswitzerland_2-1709139480294.png

The high speed handshake is normal after the USB reset but when the host tries to send the getDescriptor (as is the case when a device is detected) the data that it sends out is "mangled".
Instead of the SETUP being seen [that is the byte sequence 0x2d 0x00 0x10] the analyser sees (when I check the data in the Invalid packets, which are being repeated by the USB controller due to a bus problem)
0xbd 0x95
0xbd 0x79 0xe8
0x7d 0x79 0xe8
0xbd 0x79
0xbd 0x79
0xbd 0x76 0xf4
and other similar but random values before giving up.

Therefore my initial impression is that the stick is loading the bus much more that expected and the data is not being sent (being corrupted) or its power consumption is causing the voltages to drop to unreliable levels.

Alternatively it may be that the stick drives the bus for a short time and this corrupts any data the host sends.

Could you check in the operating stack how it configures the HSUSB transceiver to see whether is does anything special (like setting very high drive level) or whether it adds a delay before it sends the first data [comparing the operation with a windows host I see that there is 30ms delay between the HW detection and the getDescriptor start]?

This is the transceiver setup that I have always used (based on NXP references)

PMU_REG_3P0 = (PMU_REG_3P0_OUTPUT_TRG_3V200 | PMU_REG_3P0_BO_OFFSET_175mV | PMU_REG_3P0_ENABLE_ILIMIT | PMU_REG_3P0_ENABLE_LINREG | PMU_REG_3P0_VBUS_SEL_1); // enable current limited LDO output at 3.2V from VBUS1 input

USB_ANALOG_USB1_CHRG_DETECT = (USB_ANALOG_USB1_CHRG_DETECT_EN_B | USB_ANALOG_USB1_CHRG_DETECT_CHK_CHRG_B); // disable charger detection

phy->USBPHY_TX = ((phy->USBPHY_TX & ~USBPHY_TX_DCAL_VALUE) | 0x0c); // trim the nominal 17.78mA current source for the high speed drivers (USB_DP and USB_DM) (taken from NXP reference)

but maybe they have changed something after encountering such devices (?)

Regards

Mark






0 Kudos

2,056 Views
davenadler
Senior Contributor I

Hi Mark - A quick search of my project's tinyUSB sources:

 

    PMU->REG_3P0 = (PMU->REG_3P0 & (~PMU_REG_3P0_OUTPUT_TRG_MASK)) |
                   (PMU_REG_3P0_OUTPUT_TRG(0x17) | PMU_REG_3P0_ENABLE_LINREG_MASK);
  // TX Timing
  uint32_t phytx = USBPHY->TX;
  phytx &= ~(USBPHY_TX_D_CAL_MASK | USBPHY_TX_TXCAL45DM_MASK  | USBPHY_TX_TXCAL45DP_MASK);
  phytx |=  USBPHY_TX_D_CAL(0x0C) | USBPHY_TX_TXCAL45DP(0x06) | USBPHY_TX_TXCAL45DM(0x06);
  USBPHY->TX = phytx;

 

The symbol USB_ANALOG_USB1_CHRG_DETECT does not appear in my project.

Hope that helps!
Best Regards, Dave

PS: My project's complete USB initialization routine follows:

 

static void DRN_init_USB(void)
{
  // If freeRTOS is used, IRQ priority is limited by max syscall ( smaller number is higher priority )
  NVIC_SetPriority(USB_OTG1_IRQn, configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY);
  // Clock
  CLOCK_EnableUsbhs0PhyPllClock(kCLOCK_Usbphy480M, 480000000U);
  CLOCK_EnableUsbhs0Clock(kCLOCK_Usb480M, 480000000U);
  // Enable PHY support for Low speed device + LS via FS Hub
  USBPHY->CTRL |= USBPHY_CTRL_SET_ENUTMILEVEL2_MASK | USBPHY_CTRL_SET_ENUTMILEVEL3_MASK;
  // Enable all power for normal operation
  USBPHY->PWD = 0;
  // TX Timing
  uint32_t phytx = USBPHY->TX;
  phytx &= ~(USBPHY_TX_D_CAL_MASK | USBPHY_TX_TXCAL45DM_MASK  | USBPHY_TX_TXCAL45DP_MASK);
  phytx |=  USBPHY_TX_D_CAL(0x0C) | USBPHY_TX_TXCAL45DP(0x06) | USBPHY_TX_TXCAL45DM(0x06);
  USBPHY->TX = phytx;
}

 

 

0 Kudos

1,917 Views
mjbcswitzerland
Specialist V

Dave

I experimented and identified how to get the stick working.

This is the line that is causing problems:
phy->USBPHY_TX = ((phy->USBPHY_TX & ~USBPHY_TX_DCAL_VALUE) | 0x0c); // trim the nominal 17.78mA current source for the high speed drivers (USB_DP and USB_DM) (taken from NXP reference)

 since it causes the value 0x1006060f to be written.

It works when I change the line to

phy->USBPHY_TX = ((phy->USBPHY_TX & ~USBPHY_TX_DCAL_MASK) | 0x0c);

which then sets 0x1006060c.

Although I never had an issue with any other device the D_CAL resistor trimming code value of 0xf (+25%)

mjbcswitzerland_1-1709911383409.png

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


However, reading the user's manual in more detail I find this (for the MIMXRT1024):

mjbcswitzerland_0-1709911323006.png

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:

mjbcswitzerland_2-1709911758119.png

 

Due to this I tried the recommended values on the MIMXRT1024EVK and they worked OK.

This means that I have changed my own code base to set the recommended values, depending on processor type:

phy->USBPHY_TX = (USBPHY_TX_EDGECTRL_VALUE | USBPHY_TX_RSVD1_VALUE | USBPHY_TX_TXCAL45DP_VALUE | USBPHY_TX_TXCAL45DN_VALUE | USBPHY_TX_DCAL_VALUE);

where

    #if (defined iMX_RT101X || defined iMX_RT102X || defined iMX_RT1064)
        #define USBPHY_TX_DCAL_VALUE      0x00000007                     // recommended certifiable values for J/K levels
        #define USBPHY_TX_TXCAL45DN_VALUE 0x00000000
        #define USBPHY_TX_TXCAL45DP_VALUE 0x00000000
        #define USBPHY_TX_RSVD1_VALUE     0x00000000
    #elif (defined iMX_RT104X || defined iMX_RT105X || defined iMX_RT106X)
        #define USBPHY_TX_DCAL_VALUE      0x00000008                     // recommended certifiable values for J/K levels
        #define USBPHY_TX_TXCAL45DN_VALUE 0x00000200
        #define USBPHY_TX_TXCAL45DP_VALUE 0x00020000
        #define USBPHY_TX_RSVD1_VALUE     0x00000000
    #else                                                                // original NXP SDK values
        #define USBPHY_TX_DCAL_VALUE      0x0000000c
        #define USBPHY_TX_TXCAL45DN_VALUE 0x00000600
        #define USBPHY_TX_TXCAL45DP_VALUE 0x00060000
        #define USBPHY_TX_RSVD1_VALUE     0x00000000
    #endif


You can simply set
phy->USBPHY_TX = 0x10000007;
to verify until I have updated the code in the repo.

Regards

Mark





0 Kudos

1,914 Views
mjbcswitzerland
Specialist V

Dave

The bad news is however that the FAT can't work with exFAT since it thinks the stick is not correctly formatted.

USB HS device detected
USB device information ready:
USB2.0 device with 64 byte pipe
Vendor/Product = 0x0781/0x5588
Manufacturer = "SanDisk"
Product = "USB Extreme Pro"
Serial Number = "14A45679AE36"

Self-powered device with 1 interface(s)
Interface 0
Mass Storage Class : Sub-class = 0x06 interface protocol = 0x50
Endpoints:
1 = BULK IN with size 512
2 = BULK OUT with size 512
Enumerated [1]
LUN = 1
UFI INQUIRY -> Status transport - Passed
UFI REQUEST SENSE -> Status transport - Passed
UFI FORMAT CAP. -> H:1 0x02008140 0xf0406001 0x02008100
HS USB error - 0
Stall on EP-1
IN EP-1 cleared
Status transport - UFI FORMAT CAP. -> H:1 0x82008140 0xf0406001 0x82008100
HS USB error - 0
Stall on EP-1
IN EP-1 cleared
Status transport - UFI FORMAT CAP. -> H:1 0x82008140 0xf0406001 0x82008100
HS USB error - 0
Stall on EP-1
IN EP-1 cleared
Status transport - UFI READ CAP. -> (512:250085375) Status transport - Passed
Mem-Stick mounting...
Malformed - Non-formatted Memory stick


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 [https://learn.microsoft.com/en-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

0 Kudos

1,902 Views
davenadler
Senior Contributor I

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!

PS: No idea about licensing...

PPS: Your customers will see increasing numbers of exFAT-formatted sticks...

0 Kudos