iMXRT1170 USB OTG issue: Part 2 discussion on configAPPLICATION_ALLOCATED_HEAP issue

[Desmond_lim]

Hi,

As per our previous discussion in 

https://community.nxp.com/t5/i-MX-RT/iMXRT1170-USB-OTG-issue-OSA-WaitEvent-in-USB/m-p/1651745, we managed to make the USB demo work on our board however, as we started to enable some other external peripherals, the USB is not working again. 

As I troubleshoot the root cause, I noticed that there might be a conflict between the external peripheral and the USB in terms of using the ucHeap. As I pointed out in the previous discussion, for USB mouse or keyboard to work, I will set the configAPPLICATION_ALLOCATION_HEAP to 1 and declare the ucHeap somewhere whereas the external peripheral will make use of the heap_4.c PRIVILEGE_DATA ucHeap.

I am still trying to understand this USB demo code and try to incorporate this code into our working code without any memory usage conflicts between the peripherals. Any idea?

[Desmond_lim]

Hi giraffe508,

Thank you for your quick response. 

1. I will try on that to ensure it work. Most likely I will double the size and see if it works or not. Currently, the heap size I am setting is 0xc000. I will try to set 0x20000 just for the try out. Is there a limit to set for the heap for this case?

2. This is the current setting I am doing now. I am following the SDK examples for USB and I think this is the only option I have since my understanding from the last conversation that USB needs to run in nonCacheable area, am I right in that aspect?

Hence, I set the configAPPLICATION_ALLOCATED_HEAP = 1 and definition of ucHeap as per SDK. The snippet of the code is as follows:

#if defined(configAPPLICATION_ALLOCATED_HEAP) && (configAPPLICATION_ALLOCATED_HEAP)
USB_DMA_NONINIT_DATA_ALIGN(USB_DATA_ALIGN_SIZE) uint8_t ucHeap[configTOTAL_HEAP_SIZE];
#endif

3. I was thinking of doing that too, but was a bit worried if I will break something else. Are there any SDK example in using heap_5.c for this matter?

I have also configured different combination of setting like turning on/off the configAPPLICAITON_ALLOCATED_HEAP and compare the map files and observed the output. 

Let me try out your first suggestion and see if that is the issues. If it is then, it is the best. Oh, by the way, is there a way to check if the heap size is enough or not? Any tools to use besides MCUExpresso?

[Desmond_lim]

Hi Giraffe508,
I have tried many things and I really don't understand what is wrong and maybe you can give me some points to it.
1. As per your suggestion that I have tried to increase the heap size to 0x20000, however that does not work at all. Hence, I am going to the second option.
2. As what the embedded wizard is using the frame buffer starting address of 0x81000000, which is also the starting point of the noncacheable location. I thought it could be due to the memory crashing. Hence, I have shifted the location of this USB_DMA_NONINIT_DATA_ALIGN(USB_DATA_ALIGN_SIZE) uint8_t ucHeap[configTOTAL_HEAP_SIZE]; to 0x81500000.

I made the following changes:

a) Changing of the size of noncacheable address in the scatterfile:
#define m_ncache_start 0x81000000 //0x81000000
#define m_ncache_size 0x00500000 //0x01000000

b) Add in the new section for the USB part:
ER1 0x81500000 0x500000 {
* (NonCacheable_USB.init)
* (*NonCacheable_USB)
* (DataQuickAccess_USB)
}

c) in the usb_misc.h file, change the sector to refer to the new location.

#define USB_LINK_NONCACHE_NONINIT_DATA __attribute__((section(".bss.NonCacheable_USB")))

I checked my map file and indeed the location of ucHeap has become as follows:
ucHeap 0x81500000 Data 49152 usbhidapp.o(.bss.NonCacheable_USB)
Image$$RW_m_ncache_unused$$Base 0x8150c000 Number 0 anon$$obj.o ABSOLUTE
Image$$RW_m_ncache_unused$$ZI$$Limit 0x81a0bfe0 Number 0 anon$$obj.o ABSOLUTE

The compilation and everything looks file and perfect. However, the code crashed in runtime.
It crashed in this routine before even started.
#ifndef NDEBUG
#if (defined(__CC_ARM)) || (defined(__ARMCC_VERSION)) || (defined(__ICCARM__))
void __aeabi_assert(const char *failedExpr, const char *file, int line)
{
#if SDK_DEBUGCONSOLE == DEBUGCONSOLE_DISABLE
PRINTF("ASSERT ERROR \" %s \": file \"%s\" Line \"%d\" \n", failedExpr, file, line);
#else
(void)PRINTF("ASSERT ERROR \" %s \": file \"%s\" Line \"%d\" \n", failedExpr, file, line);
#endif

for (;;)
{
__BKPT(0);
}
}
Now, I am puzzle why is it crashing and dont really understand that what makes it crashed.
Please shed some lights for me as I am now completely perplexed by this thing.
What is so special about this ucHeap or what have I done wrong??

[Desmond_lim]

As for the heap_5.c, to be honest, I am still confused by the concept compare to the heap_4.c. How to set it up and what needs to be changed? The concept is also very confusing like non-consecutive memory area. The one I did in my previous example where the heap is defined in 0x81500000 is it considered as consecutive or non-consecutive?

[Desmond_lim]

I have also attached the scatter file as follows.

[jingpan]

Hi @Desmond_lim ,

I can't open the link you gave and the zip file seems empty too. I guess you may meet SDRAM cache issue. You can refer to this post.

https://community.nxp.com/t5/i-MX-RT/USB-Host-enumeration-fails/m-p/1436138

Here is some other post for your reference.

https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/Using-NonCached-Memory-on-i-MXRT/ta-p/1183369

https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/How-to-move-CM4-core-project-to-SDRAM-in-RT1176/...

Regards,

Jing

[Desmond_lim]

Hi JingPan,

I just checked on the zip file, it is not empty. However, in the zip file, there is a file which does not have a file type. However, you can open the file using any text editor because it is a text file. This file is a scatter file or linker script and by default the file type should be scf.

I am not sure if you pc will automatically delete any suspicious file or not if it is not txt. Anyway, I will upload again by changing it to txt

[jingpan · Accepted solution]

Hi @Desmond_lim ,

Please see BOARD_ConfigMPU() in board.c. The code is hung at 

          assert(!(nonCacheStart % size));

This checking is due to MPU feature. The MPU region size should be 2^N, 5<=N<=32, region base should be multiples of size.

Regards,

Jing

[Desmond_lim]

Hi Jing,

Yes. I did a mistake in the size calculation. It is ok now. Thanks for your help.

[giraffe508]

Hello, It seems like you are facing a memory allocation conflict between the USB and the external peripherals. To resolve this issue, you can try the following steps:

1. First, ensure that you have enough heap memory allocated for both the USB and the external peripherals. You can increase the heap size in the linker script or the FreeRTOSConfig.h file, depending on your project setup.
2. Next, you can try to use a single heap memory for both USB and external peripherals. To do this, you can set the configAPPLICATION_ALLOCATION_HEAP to 1 and use the same ucHeap for both USB and external peripherals. Make sure to allocate enough memory for both peripherals to avoid conflicts.
3. Alternatively, you can create separate heap memory for USB and external peripherals. This can be done by using the FreeRTOS heap_5.c implementation, which allows you to create multiple heap regions. You can find more information about heap_5.c and how to use it in the FreeRTOS heap management article.

Here's a code snippet to create separate heap regions using heap_5.c:

 /* Define the heap regions. */ HeapRegion_t xHeapRegions[] = {     { ( uint8_t * ) ucHeap1, configTOTAL_HEAP_SIZE1 },     { ( uint8_t * ) ucHeap2, configTOTAL_HEAP_SIZE2 },     { NULL, 0 } /* Terminates the array. */ };
/* Initialize the heap with multiple regions. */ void vApplicationDefineHeapRegions( HeapRegion_t * const pxHeapRegions ) {     /* Pass the array into heap_5.c. */     vPortDefineHeapRegions( pxHeapRegions ); } 

Make sure to adjust the configTOTAL_HEAP_SIZE1 and configTOTAL_HEAP_SIZE2 according to your memory requirements for USB and external peripherals.

I hope this helps you resolve the memory allocation conflict between the USB and external peripherals. If you have any further questions or need more assistance, please feel free to ask.