FTP and flash file system for RT1020?

[rshipman]

Hi,

What is the best way to get a file system set up in flash?

For example, the RT1020-EVK has an 8MByte flash, and I would like to set up a flash FS that allows FTP access (via ethernet)?

I am looking at FatFS, including the evkmimxrt1020_sdcard_fatfs SDK demo as a starting point.

There does not seem to be an obvious physical drive number for flash (to give to f_mount):

/* Definitions of physical drive number for each drive */
#define RAMDISK 0 /* Example: ram disk to physical drive 0 */
#define USBDISK 1 /* usb disk to physical drive 1 */
#define SDDISK 2 /* sd disk to physical drive 2 */
#define MMCDISK 3 /* mmc disk to physical drive 3 */
#define SDSPIDISK 4 /* sdspi disk to physical drive 4 */
#define NANDDISK 5 /* nand disk to physical drive 5 */

What if I modified the RAMDISK support to handle erasing, and configured fatfs to allow for the flash page size?

Is this a sensible approach, or is there a much better way? Perhaps using a different file system/library?

Any information/suggestion greatly appreciated.

[jeremyzhou]

Hi ,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1） What if I modified the RAMDISK support to handle erasing, and configured FatFs to allow for the flash page size?
-- No, I'm afraid it doesn't work, as the evkmimxrt1020_sdcard_fatfs doesn't provide the corresponding driver to support the RAMDISK.
2) Is this a sensible approach, or is there a much better way? Perhaps using a different file system/library?
-- For IoT, maybe you can consider the LittleFS file system.

TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[mjbcswitzerland]

Hi

I am using the RT1020-EVK with file and parameters systems in the QSPI flash which are accessed by FTP over Ethernet TCP/IP (and serve web pages for HTTP server).

To do it I am using either the uTasker uFileSystem (2k code overhead) or the uTasker utFAT (12k code overhead and 1k RAM overhead), whereby one has be be aware that the QSPI flash is not very convenient for FAT due to its long erase times - for example, when a file is created and a small amount of data written to it it requires several write/erase operations (to update the file object, the FAT (whereby there are usually two in case one gets corrupted and to add/update data). Although writes are fairly quick the sector erasures take typically 70ms..300ms each and writing a data packet often requires half  a second to complete. If wear leveling is enabled it also (as background task) will block access for several hundred ms or more when it is working.

In systems requiring FAT in the QSPI such slow writing is to be considered - if the code needs to also run XIP in the same flash the processor is effectively non-operational during these times since no flash access is possible for code to operate either.

Generally I use uFileSystem since it is usually adequate for embedded system requirements (for example, to support some 60 x 128k files or so) and doesn't have the FAT overhead (if not overwriting files it has no erase down time and has very high integrity for only about 2k code overhead) but is still fully integrated with the FTP and HTTP servers.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[rshipman]

Hi Mark,

Thank you for such a great informative answer. We are aiming to do a similar thing (but without the HTTP page serving).

Does that mean you can use just the uTasker uFileSystem (and ftp support) without having to use their OS?

We were looking at using FreeRTOS and LwIP that come with the MCUXpresso SDK to provide the OS and ethernet. Are you doing a similar thing?

Also the uTasker documentation regarding the RT1020 seems to suggest the support for this platform is still in development and so it may be sometime before it becomes stable. Do you have any comment on this?

Thanks again.

Regards,

Ronnie

[mjbcswitzerland]

Hi Ronnie

The uFileSystem is described here:
https://www.utasker.com/docs/uTasker/uTaskerFileSystem_3.PDF
and is freely available in the open source version of the uTasker project on Github (for Kinetis and STM32)

I use the exact same code on the i.MX RTs but with a QSPI flash driver below it. All services above (including FTP) are identical to those used on Kinetis, etc. but the uFileSystem interface can probably be used fairly easily from any upper layer with a little work.

The commercial i.MX RT project is being verified in first developments and will be officially released quite shortly, together with documentation and compatible operation on the main i.MX RTs.

The uTasker project can run with the uTasker OS and FreeRTOS - but the FreeRTOS mode hasn't been verified yet in the i.MX RT version. Practically the uTasker OS achieves better performance in most embedded systems and the FreeRTOS mode only used in special cases..

Although alternative middle-ware is possible the uTasker project uses a single integrated concept with its own optimised USB, TCP/IP etc. which gives low footprint (for fastest speed from exclusively internal RAM operation) and belongs to a complete integrated concept for secure loading and OTA updates as turn-key complete solution.

It allows projects to be developed on Kinetis chips and then moved to i.MX RT with almost no effort - or i.MX RT developments to be run on Kinetis parts. A series of videos will be released shortly demonstrating the concept and the various advantages it offers for real-world requirements (reduced development time, dynamic FlexRAM scaling for optimal performance, etc.), as well as accurate i.MX RT emulation for development/debugging without the need for HW.

If your requirement is to use LwIP you are probable best to interface to the uFileSytem if its functionality is suitable. If you are interested in evaluating the development version of the uTasker project you are also welcome to do so.
The i.MX RT 1021 device guide is here:
https://www.utasker.com/docs/iMX/i.MX_RT_1021_uTasker.pdf

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[mjbcswitzerland]

Hi Ronnie

I have attached binaries for you to check the performance and capability:

1. "uTaskerSerialBootBM.bin" This is the boot loader which is needed for applications to be loaded. It can be loaded using any QSPI Flash loader tool (I use NXP MCU Boot Utilit v2.2.0).
When it runs it flashes the green LED at 5Hz to indicate all is well and a USB-MSD drive appears when you connect the board's (processor) USB to a PC.

2. Drag and drop the file "uTaskerV1.4_application.bin" onto this drive to load it

3. After it loads the board will reset - you need to power cycle the board now (I'll explain why later)

4. The board (green LED blinks at 2.5Hz) now runs an FTP server and web server from QSPI Flash and can be connected to on 192.168.1.6.

To load a set of web pages open the folder "WebPagesiMX" and execute the bat file "Copy_all.bat", which executes a command that connects to the FTP server and copies all the files in the directory. If you prefer, connect with the FTP client of your choice and load the *.htm, *.jpg and *.gif files. In renamed the bat file to .txt in case it is otherwise blocked

Then you can browse to the same address and play around with some dynamic web content and upload images to it from the start web side (there are some alternative animated images for the start page in the sub-folder)

5. If the IP address is not suitable use the board's VCOM UART connection at 115k to connect to a menu -> go to the LAN menu and change the IP address configuration. Command "save" to commit changes to the parameter system in QSPI Flash and power cycle again to get the new settings to operate.

There are various menus allowing a number of additional operations (not all related to LAN) and you can also connect the HS USB, which appears as USB-CDC and offers the same command line menu (with a few commands to switch to USB-UART bridging node, etc.)

If you want to get back to the USB loader reset the board with the USER switch held down. Now new applications can be loaded by drag-and-drop again.

Although the processor is running at 500MHz if you measure the current consumption you will find it is about half that of example projects due to that fact that it is using dynamic low power switching whenever it can but without any loss of responsiveness.

The application (command line menu with a number of features, TCP/IP stack with FTP and web server serving from a file system in QSPI Flash, USB stack with CDC) is 61.2k in size and runs from ITC RAM (which is dynamically configured by the boot loader to suit the application's requirement to optimise program and data allocation) so there are no QSPI accesses (apart from file system access) to give lowest EMC radiation (all internal operation) and fastest code and data access (all are at 500MHz so no wait states and no caching jitter or complications - OCRAM is disabled since it is slower and not needed). Also the QSPI flash is powered down most of the time since code doesn't run from it, again increasing efficiency.

Although this is still Beta you should find it robust and very fast (although I have actually set slow QSPI flash speed in this version due to the fact that I have been using a logic analyser to monitor - if I set to133MHz the analyser has problems and the attached cables cause unreliability when booting with them attached).

The web server can in fact handle hundreds of parallel accesses at the same time due to its technique of saving RAM requirements while still offering high speed TCP transmission. The FTP server is however a single user access server (I disabled password so anonymous can be used - in one of the menus I think the password protection can be enabled/disable). It will thus refuse a second access.

Due to the efficient code size for a high level of features complete applications can usually fit comfortably in internal RAM, which results in the numerous advantages listed above.

Now to the things that need to be solved:
1. Presently the Ethernet connection only works reliably after a power cycle but not (always) after a warm reset (that is why it needs to be power cycled to be sure...). This needs to be solved before release. (The link comes up normally and I do receive frames according to the MIB counters but they tend to be counted as CRC errors or similar.. never saw this on Coldfires or Kinetis parts, which effectively have the same Ethernet controller)

2. When running from RAM and using the FlexSPI for the file system the processor does not restart after either a commanded reset nor a watchdog reset and one needs to push the reset button to get it going again. There is another thread from someone with a similar problem and in both cases one sees that the ROM loader doesn't try to start the code (it may do so but there are no SPI bus accesses taking place and one sees that the ROM loader is running). Again this needs to be solved before release.

Otherwise I am quite happy with the project - it inherits almost all functionality from the Kinetis project (so has a complete Modbus ASCII/RTU/TCP and MQTT solution integrated) so the effort is mainly due to special i.MX RT chip features and quirks that needed to be handled. Most are solved and the performance increase and price/performance ratio compared to the project predecessor (Kinetis) is great. For best development efficiency and to get the most out of the chips (without need for external code operation) the uTasker solution should give a big advantage.

Since the loader concept is more or less ready I need to solve the couple of known difficulties (1, 2 above) and verify operation on i.MX RT 1010..1064s (unlike other libraries the project can run on all with a single HW library, and also on all Kinetis chips by switching out the single i.MX RT HW library for the single Kinetis one). I'll also have time to get the video tutorials ready shortly which show how much easier it is to develop (using the i.MX RT simulator) too.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[mjbcswitzerland]

Hi

Note that the reset issue has been solved as described here: https://community.nxp.com/thread/524754#comment-1271411 

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[mjbcswitzerland]

Hi

First full-featured uTasker i.MX RT reference is now on-line: https://www.utasker.com/iMX/RT1020.html
Showing HS USB, TCP/IP and boot loading concept as integrated solution:

- USB-MSD / KBOOT composite loader
- Embedded FTP and web server with files in QSPI flash
- Telnet, USB-CDC, UART command line interfaces
- HS USB MSD composite with emulated FAT for viewing and transferring logged data

Complete reference project (including boot loader concept) runs on any i.MX RT or Kinetis part with the necessary peripherals.

Tutorial:
https://www.utasker.com/docs/iMX/uTaskerV1.4_iMX.pdf

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[samsaprunoff]

Good day All,

At the expense of derailing this thread a bit, I wanted to say Congratulations to Mark Butcher on providing RT processor support within uTasker, but also developing and supporting uTasker as you do!  This is in addition to his efforts responding to numerous support threads on this site!  I say again, Well Done!

Cheers,
Sam