LPC54608::SDK 2.4.1.::keyboard2mouse example always goes into hard fault in debug (OM13092

[belmontbob59]

Hello,

I've downloaded SDK  2.4.1. for Keil MDK tool chain.

I am using the example "as is" it with no modifications whatsoever.

proceed as follow:

a) download SDK 2.4.1. package from SDK builder for KEIL MDK.

NOTE:  Do not download the standalone example; you must use the full SDK 2.4.1. package.

b) connect to the target to the host Keil IDE via either cms-is port (J8) or the external debug port P1.

c) setup the board to use USB 0 for host and USB 1 for device. 

d)I connect a USB keyboard to USB 0 and connect USB 1 to a PC and provide power to J1.

e) open / compile  and link the application keyboard2mouse from "boards\lpcxpresso54608\usb_examples\usb_keyboard2mouse\bm".

f)launch the program in debug mode with a break point set at line #360 in file app.c ("while (1)" line).

g) press F5 when the debugger breaks at a line #360 to resume execution

->the firmware always goes into hard fault in usb_host_ohci.c::USB_HostOhciAddToPeriodicList()::line #769

when I launch the program in debug mode WITHOUT any breakpoints then the application runs fine. no hard fault.

Note : you must use the example from the full blown SDK 2.4.1. package. 

If you download and use the standalone example "keyboard2mouse" from the SDK builder then the hard fault never occurs. This problem is specific to SDK 2.4.1. full blown package.

Why is is keyboard2mouse from full blown SDK 2.4.1 always going into hard fault in debug mode when the standalone example always works in debug mode ? Does this mean that SDK  2.4.1. can not be trusted ?

[victorjimenez]

Hello bob belmont, 

The keyboard2mouse example of the SDK 2.4.1 works fine. If there was a problem with this example, it would not work under any circumstances. However, you are saying that the program only goes to the hardfault when you added a breakpoint in the line 360 of the app.c file, this totally make sense, let me explain why.

Before entering the infinite loop you activated the communication with the device (mouse). 

USB_DeviceApplicationInit();‍

With this the PC will start the communication with the device that correspond to the LPC that is working as a mouse. At the moment you add the breakpoint you are breaking the state machine of the USB communication. Since, The PC will start sending information to the device but the device won't be able to answer because the program was stopped. This is why you end up in the hardfault, because the PC doesn't detect any device. In general you have to be really careful when debugging programs that use USB communication. 

Hope it helps!

Victor.

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[belmontbob59]

Actually no.

1) I stated in my repro that:

1.a) keyboard2mouse from full blown SDK 2.4.1 zip (Where all the examples like "hello world" are located) always goes into hard fault. 

2.b) keyboard2mouse from standalone SDK 2.4.1 zip (which only contains keyboard2mouse and nothing else) never goes into hard fault.

So this tells us that something is wrong with the firmware. And a firmware that can not recover gracefully upon resuming from BP has a bug; regardless of the protocols in use on target. 

We do not believe in magic, so something is wrong.

2) What changed ?

2.a)The source files between the two zips (although located in different sub folder) are exactly the same. 

2.b)The compile order of the sub component DOES change, which leads to a different memory map for USB static SRAM

keyboard2mouse standalone (works):

m_usb_global 0x40100000 Section 208 usb_osa_bm.o(m_usb_global)
s_UsbBmSemStruct 0x40100000 Data 8 usb_osa_bm.o(m_usb_global)
s_UsbBmEventStruct 0x40100008 Data 48 usb_osa_bm.o(m_usb_global)
s_UsbBmMsgqStruct 0x40100038 Data 152 usb_osa_bm.o(m_usb_global)
m_usb_global 0x40100100 Section 40 usb_device_hid.o(m_usb_global)
s_UsbDeviceHidHandle 0x40100100 Data 40 usb_device_hid.o(m_usb_global)
m_usb_global 0x40100140 Section 128 usb_device_class.o(m_usb_global)
s_UsbDeviceCommonClassStruct 0x40100140 Data 16 usb_device_class.o(m_usb_global)
s_UsbDeviceSetupBuffer 0x40100180 Data 64 usb_device_class.o(m_usb_global)
m_usb_global 0x40100200 Section 5472 usb_device_lpcip3511.o(m_usb_global)
s_EpReservedBuffer 0x40100200 Data 5120 usb_device_lpcip3511.o(m_usb_global)
s_ControlTransferData 0x40101600 Data 64 usb_device_lpcip3511.o(m_usb_global)
s_SetupData 0x40101640 Data 64 usb_device_lpcip3511.o(m_usb_global)
s_ZeroTransactionData 0x40101680 Data 64 usb_device_lpcip3511.o(m_usb_global)
s_EpCommandStatusList1 0x40101700 Data 96 usb_device_lpcip3511.o(m_usb_global)
m_usb_global 0x40101760 Section 112 usb_device_dci.o(m_usb_global)
s_UsbDevice 0x40101760 Data 112 usb_device_dci.o(m_usb_global)
m_usb_global 0x40101800 Section 1376 usb_host_ohci.o(m_usb_global)
s_UsbHostOhciHcca 0x40101800 Data 256 usb_host_ohci.o(m_usb_global)
s_UsbHostOhciTd 0x40101900 Data 1120 usb_host_ohci.o(m_usb_global)

keyboard2mouse full blown (Hard fault prone):

m_usb_global 0x40100000 Section 1376 usb_host_ohci.o(m_usb_global)
s_UsbHostOhciHcca 0x40100000 Data 256 usb_host_ohci.o(m_usb_global)
s_UsbHostOhciTd 0x40100100 Data 1120 usb_host_ohci.o(m_usb_global)
m_usb_global 0x40100560 Section 208 usb_osa_bm.o(m_usb_global)
s_UsbBmSemStruct 0x40100560 Data 8 usb_osa_bm.o(m_usb_global)
s_UsbBmEventStruct 0x40100568 Data 48 usb_osa_bm.o(m_usb_global)
s_UsbBmMsgqStruct 0x40100598 Data 152 usb_osa_bm.o(m_usb_global)
m_usb_global 0x40100700 Section 5472 usb_device_lpcip3511.o(m_usb_global)
s_EpReservedBuffer 0x40100700 Data 5120 usb_device_lpcip3511.o(m_usb_global)
s_ControlTransferData 0x40101b00 Data 64 usb_device_lpcip3511.o(m_usb_global)
s_SetupData 0x40101b40 Data 64 usb_device_lpcip3511.o(m_usb_global)
s_ZeroTransactionData 0x40101b80 Data 64 usb_device_lpcip3511.o(m_usb_global)
s_EpCommandStatusList1 0x40101c00 Data 96 usb_device_lpcip3511.o(m_usb_global)
m_usb_global 0x40101c60 Section 112 usb_device_dci.o(m_usb_global)
s_UsbDevice 0x40101c60 Data 112 usb_device_dci.o(m_usb_global)
m_usb_global 0x40101d00 Section 128 usb_device_class.o(m_usb_global)
s_UsbDeviceCommonClassStruct 0x40101d00 Data 16 usb_device_class.o(m_usb_global)
s_UsbDeviceSetupBuffer 0x40101d40 Data 64 usb_device_class.o(m_usb_global)
m_usb_global 0x40101d80 Section 40 usb_device_hid.o(m_usb_global)
s_UsbDeviceHidHandle 0x40101d80 Data 40 usb_device_hid.o(m_usb_global)

3)what's going on.

The memory location that triggers the hard fault (usb_host_ohci.c::USB_HostOhciAddToPeriodicList()::line #769) is being sourced from data structure "s_UsbHostOhciHcca" at 0x40100000. At the time of the hard fault the memory is corrupted and contains pointers outside of the valid memory range. 

The first 8 bytes starting from 0x40100000 is the actual setup packet from the USB get device descriptor request (mouse from USB1). 

Coincidence ? no. The USB device controller (USB1) is actually corrupting this memory.

This is a race condition in usb_device_lpcip3511.c. The code is actually violating the contract with HW:

-It erases the SETUP entry of the endpoint command/status list (see offset 0x04  in section 39.7.1 from the spec) while DEVCMDSTAT->DEV_EN is enabled.

-DATABUFSTART->DA_BUF is 0x40100000.

so, If the SETUP packet comes in before the controller had a chance to initialize SETUP entry to a valid offset then the hardware (USB1 device block) store the 8 bytes at  0x40100000 (s_UsbHostOhciHcca) belonging to USB0 device block.

You can actually reproduce the hard fault w/o any breakpoint. Unplug/replug J2 (USB1) a couple of time and you eventually hit the race condition window.

The standalone version always worked because it is corrupting memory in OSA section not in use in bm. So the corruption is hidden from main view.

See attached file for my fix (see #ifdef _HSDEVICE_SIGSEGV_FIX_).

[victorjimenez]

Hello bob, 

Thanks for the reply and the information. 

I couldn't reproduce the error without the breakpoint by disconnecting/connecting the USB1 as you mentioned. 

For what I can see you are correct, the memory is being corrupted when you put a breakpoint due to USB0 and USB1 are using the same space in memory. However this behavior is in the application layer of the example. The driver works correctly because without the breakpoint the example works as expected. 

With the workaround you shared the problem of the corrupt memory is fix when you put the breakpoint. Thanks for providing the workaround. 

Regards, 

Victor. 

[belmontbob59]

Hello Victor,

What do you mean by the "However this behavior is in the application layer of the example.The driver works correctly because without the breakpoint the example works as expected. ". 

By driver you mean LPC54608's interval driver (part of the silicon) ? the fix is in "usb_device_lpcip3511.c" which seats in between the MCU and USB device stack. This is as low as you can be in the architecture. So this file technically belongs to the driver section of the firmware and not the application.

[victorjimenez]

Hello bob, 

I ran the application using keil MDK 5.21.1.

I  set JP9, JP11, JP12, JP13 in position 2-3, and leave JP10 open to have working application (and keyboard powered).

I placed the breakpoint in the line 360/ while(1), however the application stops in the following row USB_HostTaskFn.

while (1)
{
USB_HostTaskFn(g_HostHandle);

USB_HostHidKeyboardTask(&g_HostHidKeyboard);
}

However application still works well doesn't matter how many times and for how long I stop it on USB_HostTaskFn()

Also I tried to disconnect/connect mouse and also keyboard like 20 times and everything worked well. 

Debug probe internall set to CMSIS-DAM LPC LINK2

Regards,

Victor.