Is there iMX RT1024 feature to be used in place of EEPROM ?

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

Is there iMX RT1024 feature to be used in place of EEPROM ?

Jump to solution
4,546 Views
Anonymous
Deactivated User

I need to store a persistent data . I've being using EEPROM for this purpose with other MCUs.

May be it is possible to use some features in RT1024 in place of external EEPROM. For ex. can internal flash 4MB be used as EEPROM ? Are there SDK APIs to write/read directly addressed integers in the internal flash ?

Note: no security features of the chip are currently used - only direct access to the flash without encryption.

Labels (1)
Tags (2)
0 Kudos
1 Solution
4,472 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello, 

It's possible to use the on-chip flash of the RT1024 as NVM. Within the SDK we provide an example named flexspi_nor_polling_transfer. This example has the functions to read, write and erase the flash memory. Also, you might find useful the following community document where I described how to do this on the RT1064 which also has an on-chip flash. 

https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/How-to-use-the-RT1064-on-chip-flash-as-NVM/ta-p/...

Regards,
Victor 

View solution in original post

0 Kudos
15 Replies
4,473 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello, 

It's possible to use the on-chip flash of the RT1024 as NVM. Within the SDK we provide an example named flexspi_nor_polling_transfer. This example has the functions to read, write and erase the flash memory. Also, you might find useful the following community document where I described how to do this on the RT1064 which also has an on-chip flash. 

https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/How-to-use-the-RT1064-on-chip-flash-as-NVM/ta-p/...

Regards,
Victor 

0 Kudos
2,963 Views
larrydemuth
Contributor III

Victor,

Thanks for the info. I'm considering using the i.MXRT 1024 in an existing product, and one of the features of the product is remote firmware update. On the current product using a K66 part I upload the .s19 file, decode and save it in unused flash (flash block 1). Once uploaded I have a routine that runs in RAM to erase flash block 0, and copy block 1 to block 0, then do a system reset. Is it possible to do something like this in the 1024?

I have the upload, decode, and writing to flash (thanks to your example) figured out. Its the copying part I'm unsure of since it uses the FlexSPI to do flash operations. I'm assuming I would need some routine that could be run from RAM to do it. Any suggestions on how the routine would be done?

 

0 Kudos
4,233 Views
ping1
Contributor V

Hi, Victor

Does RT1024 has same internal flash as RT1064?

Ping

0 Kudos
4,224 Views
Anonymous
Deactivated User

Yes, the same external SPI serial interface but embedded on-chip like RT1024.

The last digit "4" in RT1064 means 4MB flash. Beware though it is only BGA balls with small pitch 0.8mm package

4,212 Views
mjbcswitzerland
Specialist V

Hi

Note that the difference between the 1024 and the 1064 is that the (same) QSPI flash is connected internally on FlexSPI2 in the 1064 but on FlexSPI1 in the 1024. Its address in the 1064 is 0x70000000 and in the 1024 it is 0x60000000.

The 1024 doesn't connect the FlexSPI1 bus to any pins so no external QSPI flash can be added, whereas the 1064 allows additional QSPI flash to be added on its external FlexSPI1 connection.

Regards

Mark

 

4,467 Views
Anonymous
Deactivated User

Thank you Victor - this is the perfect solution to a bit. And your blog post is also very good on this topic.

0 Kudos
4,486 Views
mjbcswitzerland
Specialist V

Hi

The uTasker i.MX RT 1024 project includes file system (FAT or uFileSystem) and parameter system (uParameterSystem) in the internal QSPI flash, which allows EEPROM type storage to be implemented. It also contains a turn-key security solution which, however, doesn't affect or limit the internal storage utilisation.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/iMX/RT1024.html

0 Kudos
4,464 Views
Anonymous
Deactivated User

Thank you Mark for a reply. Your uTasker solution for this is interesting as well as other tasks within uTasker could be of value too. I am not sure though that making this feature using a complete FS library is not an overkill... we do use FatFS for microSD card only. I saved the links to uTasker to my notes just in case as it seems to have everything we need but at the moment I prefer to use visual configuration tools provided in MCUXpresso and compiled with GCC toolchain 'cause we keep changing pins allocation too often. If I understand correctly uTasker does not work with NXP configuration tools.

Thanks again,

Vlad

0 Kudos
4,445 Views
mjbcswitzerland
Specialist V

Hi Vlad

I also would not use FS for parameters - uParameterSystem is designed for parameter storage and is simple and very low footprint.

uTasker works with MCUXpresso and GCC and code generated with configuration tools can be used with it. However the uTasker concept does it differently and makes configuration very simple so that additional tools are hardly needed (much is automated at run time instead) - the tools may save a few minutes when you are not yet up to speed with these first steps but overall developments can be much faster with the uTasker concept (which includes simulating the i.MX RT 1024 and visualising exactly how it has been configured and monitoring it at run time) so saving a few minutes setting up some basics tends to be easily offset by gaining maybe weeks over the course of a typical development. Another advantage is that code developed on an i.MX RT 1024 will run on all other i.MX RT 10xx parts or Kinetis parts without needing different resources and porting (just change the target processor and it essentially works on the alternatives if they have equivalent peripherals in place).

Even if you are not comfortable outside the traditional methods you can still look into using it as secure in-field / OTA boot loading concept (which works with any application and allows anyone to have on-the-fly decryption operating in their project in as little as 5 minutes) and production programming tool (where you can let one board rapidly program others).

You can view some videos discussing concepts and i.MX RT topics at https://www.youtube.com/watch?v=GXztWg9m6_8&list=PLWKlVb_MqDQEOCnsNOJO8gd3jDCwiyKKe

Regards

Mark

 

0 Kudos
4,431 Views
Anonymous
Deactivated User

uTasker is quite well thought through as I can see before diving into it...

I only started as a newbie researching the i.MX family as of now,  our project has been done with another Cortex-M7 (ATSAM E70) .  It's funny how you mention the "traditional way" using the GUI configuration tools   these kind of configuration tools I never encountered until probably few years ago , for 30+ years before that the only way of embedded code configuration I did was exactly what you do in uTasker : all choices of library configurations in C were done using "#defines"  whence since last century I always considered that way "traditional" but may be I am behind the reversed trend  

Seriously I'd like to also try the uTasker after playing with the MCUXpresso config tools + iMX RT1024 SDK library from NXP... it is safer to know all the options if we decide to have our project on iMX-RT.

Regards,

Vlad

 

0 Kudos
4,423 Views
mjbcswitzerland
Specialist V

Hi Vlad

With "traditional" I was not specifically referring to the way that the project is configured but more to the fact that it is designed on i.MX RT 10xx simulation (including memory, peripherals, interrupts, DMA, USB and some external parts like memory sticks, SD cards, I2C devices) which avoids the need for developing and debugging on the HW for much of the actual work. A result is that it makes code reviewing, learning, code coverage etc. so much easier, as well as configuration of projects, GPIO, peripherals and such. Clock configuration takes maybe half an hour of deciding what one wants and then it is automated at run time to achieve optinal power consumption by disabling everything that is not use and only gating when a peripheral is needed (and in some cases automatically powering it down when its function - such as a single shot HW timer - has completed.

In this respect "traditional" is the technique of writing chunks of code, loading, testing, debugging, correction cycles. The uTasker technique is, on the other hand, to step through existing code in the simulator and effectively write and test each line of code as you go - which can be factors more efficient and accurate.

I have accompanied a number of projects with the i.MX RT parts - some using just the loader concept and some using its full features. The configuration tools were often used and may make it easier for simple first steps without needing to 'understand' much. But after the initial quickly getting something fairly simple up and running the reality kicks in that these parts are not simple and to use them one can't rely on black boxes - typically such i.MX RT developments drag on for many months (and in some cases over a year) before they actually get close to a production state. The possible initial quick saving of a few minutes is quite insignificant where it was envisaged that automation tools would take over all the hard stuff and make things quick.

The other concept difference is that most developers take examples (which is what the SDK is) and build up a project by adding in various examples (basically copy past from one example project to the one being developed) or by adding in various middle ware code.
The uTasker concept is a "single" project which contains all of the examples and middle-ware (most middle-ware was also designed for the project so is fully integrated already) which operates out-of-the-box (that is has been tested over years to ensure that many possible combinations are operational, efficient and reliable). Rather than manually combining examples (which may or may not work together) it is a case of starting with a full blow operating solution (with USB stack, TCP/IP, command line interface, file systems, parameter systems, various peripheral operations) which can run compatibly on any part without needing to port between them and deciding what is to be disabled or enabled.
Finally the new "application" functionality is added to make the product into the unique solution that it becomes - essentially skipping large amounts of work to initially combine a number of examples that will often never have been used (or may not yet work) in combinations that the haven't been attempted before.

Therefore in some aspects techniques are old fashioned, or traditional, or modern but the combination has been developed always with the goals of having an overall environment that allows fast, reliable projects to be developed in as short amount of time as possible. I think that it has been successful as experienced with daily developing and user support but the fact is that nothing comes for free and some effort and learning will always be necessary.

Regards

Mark

0 Kudos
4,415 Views
Anonymous
Deactivated User

Looking into the example link you provided I saw a rather expansive example yet all heavily centered around the TCP/IP which we don't need in our project. Nevertheless the idea of the all-including-application example is great. (I did something like this in the past developing on-line distributed "universal" application framework to control "any" hardware) . These two ways of development are similar to the different machining technologies: additive (3D printing) vs subtractive (CNC) . But practically ... might be hard for the developer to dig out all he needs from the huge pile of unnecessary stuff...

Would be very interesting to see an example app which has all of the following (deeply biased view:):

composite USB (CDC+MSC) with full support for Vbus sensing (USB cable presence); ADC one-shot; ADC continuous with IRQ triggered if results out-of-limits, ADC continuous with on-going DMA transfer to RAM without triggering IRQ, SPI master with DMA and IRQ, I2C master with discovery of all slave devices, UART communication (fixed parameters), GPIO inputs individually set to trigger IRQ, PIT with attached dynamically maintained link list of timer tasks (IRQs with Callbacks per task),  GPT Timer-programmed delays from inputted GPIO signals , GPT timer output triggering PWM, Timer-based signal capture and measuring period/frequency with Callback, Quadrature Hall signals reading and Callback reporting, FatFS + uSD card, RTC setup from externally acquired time, wheatstone bridge sensor reading ...

Quite common set which can make many large robotics applications...  if such wonderful all-including app exists, most likely it has mountain of unneeded services (from each individual app point of view) with many "#ifdef...#else" code all over which must be sifted through ... or sifting done with yet additional set of #defines...  one gets puzzled what is better : Additive approach or Subtractive?  I've made 1st approach for all my embedded-only projects... may be worth also to try the 2nd some day...

every approach has it's downside, it is hard when we have choices to make

0 Kudos
4,410 Views
mjbcswitzerland
Specialist V

Hi

To build the application that you have in mind:

1. Disable #define ETH_INTERFACE to remove everything to do with Ethernet and the TCP/IP stack
2. #define USB_INTERFACE, #define USB_DEVICE_SUPPORT #defined USE_USB_CDC, #define USE_USB_MSD, #define SDCARD_SUPPOT [adds CDC-MSD composite with access to SD card]
3. #define SUPPORT_ADC, #define TEST_ADC, #define TEST_AD_DA shows regular single shot sampling and in/out limit (see the ADC/DAC document) and a DMA based sample to DAC (when DAC available or to a PWM output which can be RC filtered to extract the analogue level) (if USB audio is enabled it will also send it to a USB loudspeaker)
4. With #define USB_SERIAL_CONNECTIONS (and #USB_CDC_DEVICE_COUNT set to a higer value) the USB CDC will have multiple CDC interfaces and perform multiple USB<->UART bridges. UART is interrupt or DMA driven and there is usually a command line interface on one as standard. UART parameters are controlled by USB host and can be changed in real-time on the command line interface. [Options for HW or SW flow control, RS485 and single-wire or Modbus if #define USE_MODBUS and either #define MODBUS_RTU and/or #define MODBUS_ASCII are enabled]
5. With #define I2C_INTERFACE there are about 10 standard slave devices to chose from (like accelerometers, EEPROM, port expanders) but I don't have a discovery reference today
6. With #define SUPPORT_PORT_INTERRUPTS and #define IRQ_TEST each GPIO can generate an individual interrupt callback (each one can be enabled/disabled as required and their interrupt level,edge set up). With #define DMA_PORT_MIRRORING some GPIO inputs can use DMA to mirror their state to other ports - see also the video: https://youtu.be/zNWIG-O7ZW0
7. HW driven SW timer lists are integrated in the uTasker OS and usually use the SYSTICK (but can be configured to use other HW timers if there is a reason to do it - on Kinetis parts the low power timer was sometimes used in place since it allows lower power consumption and continued operation when the processor is using very low power modes (since the LPTIMER continues to run in these states)
8. Various HW timer delays that can be triggered from GPIO input changes are available but maybe no reference that exactly matches
9. #define SUPPORT_PWM_MODULE and #define TEST_PWM will generate various PWM outputs based on either GPT or FlexPWM
10. #define SUPPORT_TIMER and #define TEST_CAPTURE shows input pulse measurements (the HW timer document explains various methods also using DMA or PWM value determination)
11. Presently there is no specific quadrature input reference
12. #define SDCARD_SUPPORT includes SD card and FAT operation and a DOS like interface on the command line interface for file system usage (if FTP, HTTP are enabled these can also directly access the SD card). It uses utFAT which has more features that FatSF (like undelete, file analysis, LFN patent workaround - see utFAT document).
With #define USB_INTERFACE, #define USB_HOST_SUPPORT #defined USB_MSD_HOST the same is true for memory sticks (both memory stick and SD card are usable if all are enabled at the same time whereby the SD card will be disk and memory stick E: on the command line interface)
13. #define SUPPORT_RTC enables RTC and its time/date can be configured on the command line interface. If SNTP or time server are enabled (and the TCP stack is running over Ethernet, RNDIS or WiFi or a 4G modem - which can also be enabled) the time will be updated from these sources. See the "time management" document.
14. Some specific things may not be possible and that is where the developer adds the code to to what remains.

In addition there are various LCD solutions (graphic stuff, CANopen, DMX, and numerous other things that have been integrated over the last 15 years based mainly on real industrial product requirements and the goal is to allow all of these to be used seamlessly on almost any of the supported devices that supply the needed peripherals. In some cases there may be peripheral conflicts due to lack or resources but these are logical restrictions and not necessarily errors in the concept).

So the above configuration can be made to maybe get 50..80% of generally needed functionality, which can work on any Kinetis or i.MX RT parts with no additional work. There is a simulation model for each part and the majority of the configurations can be tested in the simulation environment without needing to do anything on the HW for the moment. The developer now adjusts and adds what else is needed to shape the final product with the overall aim to get the product reliably "finished" faster than the competitors (using other methods).

Of course there will never be everything that one would like to have immediately since that would be an illusion and impossible to realise and maintain. But there is a lot to accelerate developments. There is of course a certain amount of code included which the configuration controls but it is not overwhelming or over powering. From the user's perspective this is how the project looks - it is designed to hide the bigger details and so keep things fairly simple:

mjbcswitzerland_1-1611776372709.png

At the end of the day it is one of various solutions - some might find it good and some might find it bad but it can usually (even drastically) improve development efficiency and decrease costs. This means that it is worth considering if these are of concern.

Regards

Mark

0 Kudos
4,394 Views
Anonymous
Deactivated User

Just now UPS delivered my 1st i.MX EVK board. Will start from "quick start" ... then...

Mark, please let me know is there a free download to play with the uTasker examples ? Is there tech support with purchase? What portion of uTasker is packaged in the shared library form and how much of it is user-customizable source files ? Customization is important as we have most of our project running and a new platform is mostly for porting while preserving the same architecture and most of our code...

Thank you for a valuable info

Vlad

0 Kudos
4,329 Views
mjbcswitzerland
Specialist V

Vlad

Details are here: https://www.utasker.com/Licensing/License.html
whereby code is shared on a private GIT server.

Depending on the plan the project is free for commercial use as long as support isn't needed or full time e-mail and remote desk top support during 3 or 12 months is included in the paid commercial plans.

There is a framework and applications. All applications share the framework but each application configures it for their own use. Usually it is not necessary to make changes in the framework (but can be edited if needed). This video shows how custom applications are cloned/added to the framework so they can have their own independent Git repository too: https://youtu.be/_7Rxdr0NKWE

Attached is an i.MX RT 1024 binary (it can be loaded using NXP MCU Boot Utility - see chapter 4 of https://www.utasker.com/docs/iMX/uTaskerV1.4_iMX.pdf
or using whatever other tools are available for loading binaries.

It has a command line menu on the LPUART at 115kBaud with a number of menus that can be experimented with (including parameter storage and reading, writing, erasing QSPI flash addresses/sectors). The USB enumerates as CDC (with the same command line interface on it and a command to move to USB<->LPUART bridging mode) and USB-MSD composite. The MSD is a FAT emulation and allows a snap shot of the internal QSPI Flash content and different RAM areas to be viewed.

Unlike in the document this is a single combined i.MX RT 1024 image (allowing in-field loading via USB-MSD  - the loader mode can be commanded in the "admin" menu with command "boot"), a fall-back loader (allows in-field upgrading of the serial loader and recovery in case of serious problems with installed software) plus an application. It is all encrypted and protected again cloning (the loader automatically partitions the internal memory for best operation and the the application is run in tightly coupled instruction memory at 500MHz with zero wait states and optimises power by automatically disabling all clock and clock gates that are not in use). The processor sleeps between actions until an interrupt wakes it to do work, after which is re-sleeps.

This is the standard project build (loader and encryption is automated in the build so there is no extra work for the developer). All operation is simulated in Visual Studio so it is easy to follow the code, analyse operations and learn all details about the i.MX RT 1024 and the firmware stacks it is running. See https://youtu.be/o7hQbOqhJoc for an analysis of the encryption concept.

The project builds the same loader concept and application for any i.MX RT 10xx part/board by setting just one define. The same application builds for and runs equivalently on any Kinetis part with USB (again controlled by a single define) so the exact i.MX RT part used for development doesn't lock the product to this part (porting between chips is not needed) and moving between Kinetis and i.MX RT allows the optimal power/performance part to be moved to at any point.

Regards

Mark

P.S: There is a second encrypted image attached too that can be uploaded to the board via USB drag-and-drop when the loader mode has been entered. It adds SD card operation so the board then appears as two external hard drives (emulated FAT and real SD card) when a formatted card is inserted. In the utFAT menu on the command line interface the SD card content can be browsed and files and directories analysed.

 

Hello, world... MIMXRT1024 [Power-on]
i.MX RT Unique ID: 0x50000030-677efb092d3a19d2
Static memory = 0x00001314
OS Heap use = 0x03a5 from 0xa000
Initial stack margin 0x00024b34
FlexRAM:
2 Code banks [0x00000000..0x0000ffff]
6 Data banks [0x20000000..0x2002ffff]
SPI Flash: Winbond 4MByte W25Q32
uFileSystem integrity
Start: 0x600a0000
Granularity: 0x0000c000
End: 0x603abfff
OK
Enumerated [1]

Serial number: 00
Software version V1.4.014
Device identification: uTasker Number 1

Main menu
===================
1 Configure LAN interface
2 Configure serial interface
3 Go to I/O menu
4 Go to administration menu
5 Go to overview/statistics menu
6 Go to USB menu
7 Go to I2C menu
8 Go to utFAT disk interface
9 FTP/TELNET commands
a CAN commands
help Display menu specific help
quit Leave command mode




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

0 Kudos