Memory configuration in iMXRT

Question

Hello,

We are trying to run our HMI application on a slightly customized iMXRT 1050 board. Our application runs on the eval board but does not run on the customized board.

The main difference is the memory - we only have 8MB SDRAM on this board and the start address is different (0x62000000). We have updated the SDRAM_BASE_ADDR & SDRAM_SIZE_BYTES macros to fit our case

Please let us know if there is something else that has to be adapted (for example in the board.c file - I have uploaded the file we use here https://ask.embedded-wizard.de/?qa=blob&qa_blobid=1131630317249952571). Do we have to change something in BOARD_ConfigMPU()?

What we observe is that the application stops at the call to NxpRtCreateSurface - we get 2 calls to this function with the full dimensions (800x480). After the second call, the application just stops. The memory allocation is actually successful but application does not continue afterwards when returning from this function.

Please provide your feedback.

Thanks,

Hemant

Answer 1

Hello Hemant,

of course, the MPU settings have to be adapted to the new start address and the new address range. Otherwise hard faults can happen.

Please try first to run the SDRAM memory test before executing the GUI application the first time.

Best regards,

Manfred.

Comments

Hi Manfred,

Thanks for the hints, we will perform the SDRAM test.

One more crucial aspect - on this custom board we dont have the internal flash/SDRAM. Instead we use a Hyper Flash and a Hyper RAM connected to the Flex SPI bus.

Does Embedded Wizard support Hyper RAM? We noticed that the application allocates surfaces of dimension (800x480):

- why are these surfaces needed when we already have double buffered frame buffer allocated separately?

- is it OK to have these surfaces on the Hyper RAM?

---

Hi Hemant,

from Embedded Wizard point of view, there is no restriction concerning the Flash/SDRAM - as long as it is mapped into the address space and can be accessed from CPU, PXP and LCD without restrictions (random access).

When you provide the two framebuffers (in case of double buffering), there is no need to allocated separate framebuffers. But maybe your application contains full screen images and your bitmap resources are stored compressed. In this case a full screen surface is allocated in order ot load the image.

Best regards,

Manfred.

---

Thank you.

The hint about bitmap resources was indeed helpful. This was also the problem. Although we intended to render the bitmaps from flash, we did not make the setting explained in this link https://doc.embedded-wizard.de/formatofbitmapresources-attr

After setting the "FormatOfBitmapResources" to "DirectAccess", the issue is not seen anymore.

 

Regards,

Hemant