iMXRT1170 USB OTG issue: OSA_WaitEvent in USB_HostEhciTaskFunction forever

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

iMXRT1170 USB OTG issue: OSA_WaitEvent in USB_HostEhciTaskFunction forever

ソリューションへジャンプ
3,690件の閲覧回数
Desmond_lim
Contributor III

Hi all,

I am developing the USB OTG code on our prototype board based on the SDK "host_hid_mouse_keyboard_freertos_cm7". However, I am now facing the problem that I am totally stuck and dont know how to proceed further. I have basically changing the USB code to the SDK but it seems to stuck in this function OSA_WaitEvent insides USB_HostEhciTaskFunction forever. (Please refer to the snippet below)

------------------

if (OSA_EventWait(ehciInstance->taskEventHandle, 0xFF, 0, USB_OSA_WAIT_TIMEOUT, &bitSet) ==
KOSA_StatusSuccess) /* wait all event */

------------------

Basically, I need to understand what is this expecting and what is the configuration that I was setting it wrong or missed out? Is it a HardWare event or SoftWare event that it is expecting?

Most importantly, how can I resolve this issue?

Some of the configurations:

a) Preprocessors:

XIP_EXTERNAL_FLASH=1, XIP_BOOT_HEADER_ENABLE=1, XIP_BOOT_HEADER_DCD_ENABLE=1, USE_SDRAM, DEBUG, CPU_MIMXRT1173CVM8A_cm7, SERIAL_PORT_TYPE_UART=1, SDK_OS_FREE_RTOS, MCUXPRESSO_SDK, PRINTF_FLOAT_ENABLE=1, REMOTE_TEST_CMD=1, SDK_I2C_BASED_COMPONENT_USED,  DATA_SECTION_IS_CACHEABLE=1, USB_STACK_FREERTOS,USB_STACK_FREERTOS_HEAP_SIZE=32768, FSL_OSA_BM_TASK_ENABLE=0,FSL_OSA_BM_TIMER_CONFIG=0

------------------------------------------------------------------------------------------------

I noticed that there is configAPPLICATION_ALLOCATED_HEAP is being defined in the SDK. However, our case, we are not defining it. Is this the cause of the problem? 

b) The scatter file we are using it. It is almost same as the SDK. (Please refer to the attachment).

Are there anything else I need to configure apart from this?

 

 

0 件の賞賛
返信
1 解決策
3,422件の閲覧回数
Desmond_lim
Contributor III

Hi Jing,

Found the problem that actually lies in our prototype board that R205 and R210 should not be populated and this caused the entire interrupt failed to operate. 

Thanks for your support.

元の投稿で解決策を見る

0 件の賞賛
返信
14 返答(返信)
3,494件の閲覧回数
jingpan
NXP TechSupport
NXP TechSupport

Hi @Desmond_lim ,

First of all, please use host_hid_mouse_keyboard_bm or other bare metal project to check if it is really a hardware issue.

When I test host_hid_mouse_keyboard_freertos, it will not step into USB_HostTask() if I don't connect any usb device. Is it same as your board?

When step into OSA_EventWait(), it has timeout value. It should not hang there.

I don't know what is your IDE and what you've changed. Please start from a new SDK demo. Don't change anything. In the demo, DATA_SECTION_IS_CACHEABLE is 0 but you changed it to 1.

 

Regards,

Jing

 

0 件の賞賛
返信
3,489件の閲覧回数
Desmond_lim
Contributor III

Hi Jing,

Thank you for your reply.

I am testing with the mouse device connected to the board. So, I can check that it is stepping into the USB_HostTask().  

As for the OSA_EventWait(..), you are absolutely right that there is a timeout. Unfortunately, this timeout is set to forever, which seems to work perfectly. (^-^). I also just checked that even if the timeout is set to 0 if I did not set the USE_RTOS preprocessor, for some strange reasons that it is still stuck in the OSA_EventWait forever. It is getting really bizarre every time I started to investigate more things.

-----------------------------------------------------------------

Snippet:

...

if (OSA_EventWait(ehciInstance->taskEventHandle, 0xFF, 0, USB_OSA_WAIT_TIMEOUT, &bitSet) ==
KOSA_StatusSuccess) /* wait all event */

...

and

/*! @brief Define default timeout value */
#if (defined(USE_RTOS) && (USE_RTOS > 0))
#define USB_OSA_WAIT_TIMEOUT (osaWaitForever_c)
#else
#define USB_OSA_WAIT_TIMEOUT (0U)
#endif /* (defined(USE_RTOS) && (USE_RTOS > 0)) */

 

 

 

Let me try on your suggestion.

Cheers,

Desmond

0 件の賞賛
返信
3,423件の閲覧回数
Desmond_lim
Contributor III

Hi Jing,

Found the problem that actually lies in our prototype board that R205 and R210 should not be populated and this caused the entire interrupt failed to operate. 

Thanks for your support.

0 件の賞賛
返信
3,639件の閲覧回数
jingpan
NXP TechSupport
NXP TechSupport

Hi @Desmond_lim ,

The event comes from USB interrupt service routing. When USB interrupt comes, it register information in OSA. Then this function check the message and go next step.

 

Regards,

Jing

0 件の賞賛
返信
3,634件の閲覧回数
Desmond_lim
Contributor III

Hi JingPing,

Thank you for your reply. 

As I was investigating into the usb problem and understand from various sources, I started to think that my current problems lie in two areas.

1) configAPPLICATION_ALLOCATED_HEAP = 1: Currently, I am setting this to the default value which is 0, because if I set it to 1, my FreeRTOS tasks will not work for some reasons. I am now wondering why because from the FreeRTOS url, this preprocessor is to allow user to redefine the location of the ucHeap. Do you have any information on this?

2) Data Cache, my understanding is the USB relies a lot of data in the NonCache area. I suspect that my setting is wrong. Will you be able to help me identify what the problem is?

For now, I am looking in these two places. If you think there is something else I need to investigate and could be potential problem to my issues, please help me out here.

Thanks.

0 件の賞賛
返信
3,608件の閲覧回数
jingpan
NXP TechSupport
NXP TechSupport

Hi @Desmond_lim ,

When configAPPLICATION_ALLOCATED_HEAP=1, ucHeap will be allocate to noncacheable area. USB buffer is accessed by both USB DMA and MCU core. If it is cacheable, data will mismatch because MCU core will access RW cache first. So the data in real memory is dirty and may cause error. This is why those buffer must in noncacheable area.

Regards,

Jing

0 件の賞賛
返信
3,594件の閲覧回数
Desmond_lim
Contributor III

Hi JingPan,

Thank you for the explanation and I think it really makes sense for me. However, what does not make sense to me is that since USB DMA and MCU core are sharing the same area, why is it not splitting this two things into separate area where both USB DMA and MCU core are both fulfilled. 

Currently, this is a headache for me because I am forced to choose between cacheable and noncacheable for USB using a preprocessor called configAPPLICATION_ALLOCATED_HEAP. 

Can you shed some lights on how I can split this ucHeap into two sections and locate them into cacheable and noncacheable area as they wished. I was reading this forum (please refer to the link below) and the guy was mentioning about picking on one of the heapx.c. Currently we are using heap4.c as per the recommendation, and does it mean it is not suitable for my case?

USB Host enumeration fails - NXP Community

For my case, if I need to use USB, no matter what I need to change the ucHeap to noncacheable or there is another solution where I can redirect the USB 's heap to noncacheable and dont use the ucHeap at all?

Any great idea?

#if defined(configAPPLICATION_ALLOCATED_HEAP) && (configAPPLICATION_ALLOCATED_HEAP)

USB_DMA_NONINIT_DATA_ALIGN(USB_DATA_ALIGN_SIZE) uint8_t ucHeap[configTOTAL_HEAP_SIZE];

#endif

 

0 件の賞賛
返信
3,535件の閲覧回数
jingpan
NXP TechSupport
NXP TechSupport

Hi @Desmond_lim ,

The USB freeRTOS demo works fine already. Why you must change configAPPLICATION_ALLOCATED_HEAP to 0?

 

Regards,

Jing

0 件の賞賛
返信
3,525件の閲覧回数
Desmond_lim
Contributor III

Hi Jing,

It is still not working fine. I have managed to configure configAPPLICATION_ALLOCATED_HEAP to 1. But, it is not working. I noticed that it is stuck in the OSA_WaitEvent forever. This event will need OSA_SetEvent from the interrupt handler function USB_OTG1_IRQHandler(void). 

And I noticed that there is no interrupt triggered even though the interrupt has been enabled by calling USB_HostIsrEnable(void).

Seriously, I dont know why this is so **bleep** difficult to configure even I copy exactly the same SDK. Can you tell me besides that function.

EnableIRQ((IRQn_Type)irqNumber); in the USB_HostIsrEnable(void). What else is needed to set the interrupt up. 

I read the forum mentioned that USB OTG OC line is used as an interrupt. 

https://community.nxp.com/t5/i-MX-RT/External-Signals-Hardware-Configuration-for-USB-OTG-Interrupt-i...

I checked all the schematic and the pins, it is ok. Just that it does not trigger the USB interrupt. Any idea?

Cheers,

Desmond

0 件の賞賛
返信
3,517件の閲覧回数
jingpan
NXP TechSupport
NXP TechSupport

Hi @Desmond_lim ,

So, since the original SDK usb example can't run on your board, it is more like a hardware issue. Can you share the schematic? Have you measured such as VDD_USB_1P8, VDD_USB_3P3, USBx_VBUS?

 

Regards,

Jing 

0 件の賞賛
返信
3,509件の閲覧回数
Desmond_lim
Contributor III

Hi Jing,

We checked on the VDD_USB_3V3, it is ok. I did not check on the VDD_USB_1V8, which I will do it. However, in terms of the schematics, the USB OTG1 is the same as EVK except that we did not connect the DCDC_1V8_OUT as we are using it for ADC_1V8_In. This line is connect the SENS port right?

Is this needed for the USB interrupt?

Please see the attachment. 

As for the USBx_VBUS, the connection is the same, I noticed that this is actually controlled by two signals (ID and PWR). The problem is that the PWR will not be high if there is no USB interrupt.

In the SDK code, the program stuck in the OSA_WaitEvent before proceed to change the USB port, which provide the PWR (correct me if I am wrong as I observed from the light of the mouse.) In order to proceed from the OSA_WaitEvent, we need to have OSA_SetEvent which is called in the USB IRQ Handler. My current problem lies in there is no interrupt at all. No matter how I enable the interrupt by calling the Enabled_IRQ function. It is not budging a bit. 

Actually, I was wondering if there is something I missed out apart from the IRQ function. Can you confirm on this?

Thanks.

0 件の賞賛
返信
3,663件の閲覧回数
Desmond_lim
Contributor III

I have found another similar forum on the same topic. Just for the record here.

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

0 件の賞賛
返信
3,666件の閲覧回数
Desmond_lim
Contributor III

Hi experts,

As I have been testing on the configAPPLICATION_ALLOCATED_HEAP settings, I noticed that if this is set to zero, the host_hid_mouse_keyboard_freertos_cm7 cannot work properly. 

Trial 1:

In the app.c, I uncommented out the #ifdef so that USB_DMA can allocated some memories in the ucHeap

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

Result: The program is not able to function after the initialization.

I noticed that this configAPPLICATION_ALLOCATED_HEAP is used by this heap_4.c for the PRIVILEGED_DATA if this preprocessor is set to 0. Otherwise, it will be defined externally, which is making use of the definition in the app.c

/* Allocate the memory for the heap. */
#if ( configAPPLICATION_ALLOCATED_HEAP == 1 )

/* The application writer has already defined the array used for the RTOS
* heap - probably so it can be placed in a special segment or address. */
extern uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];
#else
PRIVILEGED_DATA static uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];
#endif /* configAPPLICATION_ALLOCATED_HEAP */

Questions:

1. For the USB, do we need to use the ucHeap or can we defined a memory location for the USB DMA? 

2. Currently, I just checked that the FreeRTOS is making used of this ucHeap Privileged Data section and if I were to make this USB DMA, both USB and FreeRTOS task cannot work properly. How can I make them work together properly?

3. Can I share the ucHeap between the FreeRTOS tasks and USB DMA? If not, can I shift it to somewhere? How can I do that using the scatterfile?

Thanks.

 

 

0 件の賞賛
返信
3,664件の閲覧回数
Desmond_lim
Contributor III
An additional point, quoted from the freeRTOS official page:
By default the FreeRTOS heap is declared by FreeRTOS and placed in memory by the linker. Setting configAPPLICATION_ALLOCATED_HEAP to 1 allows the heap to instead be declared by the application writer, which allows the application writer to place the heap wherever they like in memory.
This has been puzzling me as in how come if I set the configAPPLICATION_ALLOCATED_HEAP in this program, the program seems not to work properly. Can anyone shed some lights to this?
As for the original issue, I am still progressing inch by inch since there are so many things to unpack here.
0 件の賞賛
返信