Memory reconfiguration of i.MXRT1010

[laszlo]

My C application uses a lot of stack and heap space. Can someone point me to the information, how I can reconfigure the FlexRAM on the i.MXRT1010 EVK (possibly with MCUXpresso) to have all 128 KB as OCRAM (and no DTCM and ITCM)? Will then the linker know, where to put the stack, or do I have to edit its settings? -thx

[jeremyzhou]

Hi Laszlo Hars，

Thank you for your interest in NXP Semiconductor products and
the opportunity to serve you.
To provide the fastest possible support, I'd highly recommend you to refer to the AN12077: Using the i.MX RT FlexRAM which describes the flexible memory array available on the i.MX RT MCUs. Please refer to it for details.

Have a great day,
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.
-------------------------------------------------------------------------------

[laszlo]

According to the documents, I tried the following:

#define IOMUX16 (*(uint32_t*)0x400AC040)
#define IOMUX17 (*(uint32_t*)0x400AC044)

...

IOMUX16 &= ~7UL; IOMUX16 |= 6;
IOMUX17 &= ~0xffUL; IOMUX17 |= 0x6a;

It should achieve the following:

IOMUXC_GPR_GPR16 -> 0x0020_0006 (Use FLEXRAM_BANK_CFG, DTCM enabled, ITCM disabled)

IOMUXC_GPR_GPR17 -> 0x0000_006a (binary 0110_1010, see its meaning below)

BANK0 = DTCM  (0b10)

BANK1 = DTCM  (0b10)

BANK2 = DTCM  (0b10)

BANK3 = OCRAM (0b01)

With these changes, the board should have enough room for the needed 77KB stack.

But the C linker does not know about these changes, it still allocates a small stack.

I tried to change the MCU settings under the project properties in MCUXpresso, to reflect the changes (SRAM_DTC size = 0x18000, SRAM_ITC size = 0, SRAM_OC size = 0x8000) then refreshed the MCU cache.

-- Disaster:

After that, the board does not work anymore. When I try to debug a program, MCUXpresso does not find any SWD device. The red LED lights up on the board, and stays lit till I unplug the board from USB.

- The most urgent question: how can I get back the EVK to a working condition?

When I get back my evaluation kit, the next question is:

- How can I tell the linker to use a large stack? (The settings does not let me select larger than 0x8000 = 32 KB stack size.)

[jeremyzhou]

Hi Laszlo Hars，

Thanks for your reply.
1) how can I get back the EVK to a working condition?
-- Debug any one demo which is from the SDK library to recover.
2) How can I tell the linker to use a large stack?
-- Please refer to the 18.12 Modifying heap/stack placement section in the attachment.

Have a great day,
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.
-------------------------------------------------------------------------------

[laszlo]

> Debug any one demo which is from the SDK library to recover.

I tried both the hello_world example and the iled_blinky, they did not help. Still no SWD device is found. My other development boards work (KL25Z, K28F...), but not this one.

When I plug it into the USB port, a bright red LED flashes twice, then the board looks OK. However, trying to debug any program makes the red LED to light up, and to stay on.

To recap, what I did, breaking the EVK:

The modified beginning of the main function looks:

#define IOMUX16 (*(uint32_t*)0x400AC040)

#define IOMUX17 (*(uint32_t*)0x400AC044)

...

// Remap SRAM: DTCM: 96k. ITCM: 0. OCRAM: 32k

IOMUX16 &= ~7UL;    IOMUX16 |= 6;

IOMUX17 &= ~0xffUL; IOMUX17 |= 0x6a;

// Initialize board hardware

BOARD_ConfigMPU();

...

Since the C-linker does not know about these changes, it still allocates small stack, so we have to make changes to the project properties.

Project Properties -> C/C++ Build -> Settings -> MCU settings

SRAM_DTC size = 0x18000

SRAM_OC size = 0x8000

Project Properties -> C/C++ Build -> Settings -> MCU Linker -> Managed Linker Scripts

Stack size = 0x17000

However, all these seem to interfere with the function “BOARD_ConfigMPU()” in the system startup C file “board.c”. There the original, default region sizes are used (with setting the attributes shareable, cacheable, etc.), unaffected by the changes we just made in the project settings.

It is unclear if we have to edit the file “board.c”, too, and what else? - These were my original questions...

Editing the MCU settings under project properties caused the board to stop functioning.

[jeremyzhou]

Hi

Thanks for your reply.
Thanks for your reply.
1. I'd like to recommend you to use the NXP-MCUBootUtility tool to erase the complete external flash chip to recover.
2. It is unclear if we have to edit the file “board.c”, too, and what else?
-- Yes, it's also necessary to adapt the BOARD_ConfigMPU() to fit the management of the memory allocation.

Have a great day,
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.
-------------------------------------------------------------------------------

[laszlo]

Thanks, Jeremy, for your answers, but they don't help much.

1. I tried "to use the NXP-MCUBootUtility tool to erase the complete external flash chip to recover", as you suggested. I am stuck at its Note 2, because the step-by-step instructions are in Chinese, and some of the links don't work.

Note2: Before using NXP-MCUBootUtility, you need to rebuild the source in \NXP-MCUBootUtility\tools\image_enc\code directory to generate image_enc.exe and put it in \NXP-MCUBootUtility\tools\image_enc\win directory, or BEE/OTFAD related encryption function can not be used properly。See more details in 《The step-by-step guide to build image_enc.exe for BEE/OTFAD encryption》

Just to set up the tool is an awful lot of work. There should be a simpler recovery tool, offered by NXP, if the EVK could so easily (by a single C instruction) get into such an erroneous state. Maybe to get the EVK in Bootloader mode, and copy the recovery content to the bootloader drive?

2. "-- Yes, it's also necessary to adapt the BOARD_ConfigMPU() to fit the management of the memory allocation."

-How? -Where? -What else?

E.g. there is also the file "project / startup / startup_mimxrt1011.c". It also has references to the memory.

3. Again, does anyone have working code, that reconfigures the MCU memory?

[jeremyzhou]

Hi

Thanks for your reply.
1. I tried "to use the NXP-MCUBootUtility tool to erase the complete external flash chip to recover", as you suggested. I am stuck at its Note 2 because the step-by-step instructions are in Chinese, and some of the links don't work.
-- It's not necessary to integrate the HAB and BEE/OTFAD encryption feature in NXP-MCUBootUtility to connect the i.MX RT1010 and do erase operation.

GitHub - JayHeng/NXP-MCUBootUtility: A one-stop boot utility tool based on Python2.7+wxPython4.0, it... 
2)  "-- Yes, it's also necessary to adapt the BOARD_ConfigMPU() to fit the management of the memory allocation."
-- Please refer to the AN12042.

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

[laszlo]

I managed to erase the external flash of the EVK, with the “NXP MCU Boot Utility tool”, but it is not trivial. I list here the steps necessary, in case anyone else needs to revive a dead EVK, killed by some innocent-looking C code:

• Unplug the board from the USB connection
• Put the board to “Serial Download Mode”, by setting the switches SW8-3, SW8-4 to 0,1
• Plug the board to a USB port
• In the Windows device manager set the Baudrate of the board’s emulated COM port to 115200, if not already there
• Start the NXP‑MCU Boot Utility”, by executing “NXP-MCUBootUtility.exe” from the unpacked folder “...\NXP-MCUBootUtility-master\bin”
• From its “Tools” tab select “Run Mode / Master”
• In the “Port Setup” window (middle, left) select “UART”, the correct COM port and the Baudrate
• Press the “Connect to ROM” button in this window and check if the circle above it is colored green. (If not, no connection was established to the EVK, so check the cables, switches, and the port setup)
• In the main window on the top right, select the tab “Boot Device Memory”
• Press the “Erase” button
• Wait till the progress bar on the bottom indicates that the erase operation finished
• Close the “NXP MCU Boot Utility”
• Unplug the board from the USB
• Set normal boot mode by setting the switches SW8-3, SW8-4 to 1,0
• Plug the board to a USB port on the main PC
• In MCUXpresso debug a known good project (e.g. the “hello world” SDK example). It should now run, normally – after it automatically loads a valid flash image

However, I still cannot reconfigure the on-chip RAM. Whatever changes I make have either no effect or kill the EVK board. I keep asking, please provide a functioning example, with instructions. The linked NXP documents don't have enough information. I already wasted a week on this, and about to give up and go with another product.

[jeremyzhou]

Hi,

Thanks for your sharing.
To provide the fastest possible support, I want to point you to a
similar question that has been answered on our NXP community.
Please refer to https://community.nxp.com/message/1239365?commentID=1239365#comment-1239365
to view the details.

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

[laszlo]

Thanks, Jeremy, for the link. Even though it concerns a different evaluation board, I did give it a try. For the i.MXRT1010 the SRAM_OC (used by the ROM code) cannot be made less than 64KB, and the SRAM_ITC (interrupt vector table is there at address 0) cannot be made of size 0. It means, that there is no way the SRAM_DTC region can be increased. In fact, no memory reconfiguration looks possible, and so the processor manual is misleading.

When trying to make SRAM_ITC of 0 size, starting the debugger gives the error message:

Sending VECTRESET to run flash driver
chip initialization failed - Em(12). Target rejected debug access at location 0x00000000
failed to initialize flash driver MIMXRT1010_SFDP_QSPI.cfx