Hello
We are working on a project using i.MX RT1050 processor along with SDK_2_10_0_EVKB-IMXRT1050 for our development. The hardware is based on the IMXRT1050-EVKB. In our application we are using Crank software for GUI and need to use USB in Host mode for storing data in one Mass Storage Device. We are also I2C for communicating with other peripherals. Since the application code makes use of a GUI, RTOS and many other components\modules for various operations, we need to make use of SDRAM as the internal RAM is not sufficient for all these operations. We are able to successfully verify USB and Crank functionalities on our board via example codes which are based on internal ram. The application is loaded from SD Card.
We were able to test and verify the crank, i2c and USB working on the reference board individually. We merge the crank and i2c application to make it work with our LCD and it worked fine.
For USB application, we used usb_host_msd_freertos example as base. As per our understanding USB stack cannot run directly from SDRAM but runs either from DTC RAM or any other dedicated non-cacheable memory section. To use the Non cacheable memory following two macros need to be defined in the processor:
configAPPLICATION_ALLOCATED_HEAP=1(also from FreeRTOSConfig.h)
DATA_SECTION_IS_CACHEABLE=1
Now by default all example code make use of heap_4. RTOS initializes the memory(ucHeap) for the selected non-cacheable region in heap_4.c during its first call for pvPortMalloc. But that happens only if configAPPLICATION_ALLOCATED_HEAP is set in the project and if not done then ucHeap is initialized as cacheable and USB enumeration fails.
However when are using configAPPLICATION_ALLOCATED_HEAP=1 for initializing as non-cacheable memory(ucHeap), it been observed that i2c stops working after a while.
We are using i2c1 to read data periodically from a particular sensor. Its able to read data for while, but after sometime(usually less than a minute), entire i2c operation hangs in LPI2C1_DriverIRQHandler. The issue is takes time to produce in debug mode but when ran freely, its occurs very fast. For I2C we are using i2c freertos drivers. We tried with baremetal drivers also in the freertos application but there also if we are allocating memory for the non-cacheable region, same behavior is observed.
Does the I2C has any dependency on the non-cacheable memory sections? Is there a way to remove this dependency or a work-around to the issue?
Kindly help in resolving this issue. Any leads would be appreciated.
Thanks
Aditya Saini
Hi: Aditya Saini
Since you don't use DMA for I2C, so there is no non-cache memory issue for i2c.
I tested on my side with i2c demo on my side, sdram as the primary RAM. It works well.
I would suggest you run the i2c task only, increase the i2c task stack, and check whether this issue still happens.
Regards
Daniel