USB Hard Fault during ISR if task is not running

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ldchub on Wed Dec 09 02:25:33 MST 2015
Hello everybody,

I have a problem with USB on LPC1766 processor.

Setup)
Toolchain & Editor: LPCXpresso v7.9.2
uC: LPC1766

Problem description)
I'm modified the usbd_lib_cdc example from LPCopen to integrate the USB functionality into Freertos-based application firmware.

I followed the indications from here:
http://www.freertos.org/FreeRTOS-Plus/BSP_Solutions/NXP/combining_lpcopen_example.html
The final result is OK with the USB task being the only task in the system (apart from the idle one).

Later on, I added tasks for my application, and now I'm getting an Hard Fault when the USB_IRQHandler() is called. This does not happens always, but only when the running task is not the USB one. Instead, the call to
USBD_API->hw->ISR(g_hUsb)
does not produces any error if the running task is the USB one.

What I did)
I tried to modify the task' stack up to 1024 bytes, but the error persisted.

I also checked the priority value of USB interrupt to comply with FreeRTOS requirements (logic priority less or equal to configMAX_SYSCALL_INTERRUPT_PRIORITY. But the problem persisted.

Further, the problem arises both if I use FreeRTOS api in USB ISR (...FromISR suffix) or I don't use any synchronization at all.

Could you help me?

Some information:

List of tasks launched, with priorities and dimensions:

xTaskCreate( usb_entry_point, ( signed char * ) "USB", 1024, ( void * ) NULL, tskIDLE_PRIORITY+4, &xUsbTaskHandle );

    xTaskCreate( vuIP_Task, ( signed char * ) "uIP", mainBASIC_WEB_STACK_SIZE, ( void * ) NULL, mainUIP_TASK_PRIORITY, NULL );
    
    xQueue_myQueue = xQueueCreate( 4, ( unsigned portBASE_TYPE ) 40 );
        
    xTaskCreate( vSIM_Task, ( signed char * ) "SIM", configMINIMAL_STACK_SIZE, ( void * ) NULL, tskIDLE_PRIORITY + 1, ( xTaskHandle * ) NULL );

Register dump during Hard Fault:
r0volatile uint32_t0x2007c010 (Hex)
r1volatile uint32_t0x1000025c (Hex)
r2volatile uint32_t0x800005ff (Hex)
r3volatile uint32_t0xd24d (Hex)
r12volatile uint32_t0xa5a5a5a5 (Hex)
lrvolatile uint32_t0xc189 (Hex)
pcvolatile uint32_t0xd25a (Hex)
psrvolatile uint32_t0x1000028 (Hex)

The program counter points to the flash sector, indeed I'm using usbd ROM stack. So I think NXP should take the floor here.

In attachment you can find the linker file and the file containing the USB ISR and task.

Thanks for your support

Original Attachment has been moved to: cdc_if.c.zip

Original Attachment has been moved to: linker_file.zip

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ldchub on Thu Dec 10 15:20:19 MST 2015
At the end I found the problem: the r2 register was loaded with a value coming from a memory region that was overwritten by the ethernet packet buffers. The address was totally outside any mapped region of memory. Eventually loading a register from this unmapped address caused a bus fault further escalated into a hard fault.

Thanks to vtw for the suggestions.

Best Regards

ldchub

lpcware · ‎06-15-2016

Content originally posted in LPCWare by vtw.433e on Wed Dec 09 05:02:11 MST 2015
Sorry, but you are missing the point here.

The PC may be in the ROM, but it is not that which is causing the fault. The fault will be caused by an instruction at that address accessing a memory location that causes the fault - most likely an address that you have passed to the ROM routine.

So, as I said, find the address that caused the fault - this is NOT the PC. You can find this by reading the FAQ that I pointed you at.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ldchub on Wed Dec 09 03:35:28 MST 2015
Hi vtw,

The point is that the PC points to value 0xD25A, and, as explained before, it is part of the USBD rom library. This can be clearly seen from the .map file:

.text.hwUSB_WriteEP
                0x0000d208       0x44 ..\lpc_chip_175x_6x\libs\libusbd_175x_6x_lib.a(hw_usbd_ip3503.o)
                0x0000d208                hwUSB_WriteEP
.text.hwUSB_ISR
                0x0000d24c      0x1a0 ..\lpc_chip_175x_6x\libs\libusbd_175x_6x_lib.a(hw_usbd_ip3503.o)
                0x0000d24c                hwUSB_ISR

Being in a pre-compiled library, I do not have the possibility to understand what's wrong in hwUSB_ISR

The following is the dissassembly for the hwUSB_ISR:

 hwUSB_ISR:
0000d24c:   stmdb sp!, {r4, r5, r6, r7, r8, r9, r10, lr}
0000d250:   ldr.w r9, [r0, #456]    ; 0x1c8
0000d254:   mov r10, r0
0000d256:   ldr.w r2, [r9, #4]
0000d25a:   ldr r3, [r2, #0]

I'm not used with assembly debugging. What should I check here?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by vtw.433e on Wed Dec 09 02:47:58 MST 2015
Why don't you start by tracing the cause of the hard fault?
https://www.lpcware.com/content/faq/lpcxpresso/debugging-hard-fault

This will tell you the address that has cause the fault, which should give you a clue.

It is impossible for anybody to debug your code for you.