LPC4357 Multicore USB Problem

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
Content originally posted in LPCWare by GTA on Sat Aug 10 18:51:02 MST 2013
Hello All,

As you may have seen from my earlier threads I am using an Embedded Artists LPC4357 dev kit, and I am currently working on having the Cortex-M4 to use one USB port and the Cortex-M0 to use the other USB port. I am using LPCOpen v1.03, which includes the LPCUSBlib USB stack.

I have built separate libs for the M4 and M0 respectively for the board and LPCUSBlib code. As USB application code I use the lpcusblib_GenericHIDDevice example, which I link with the board and LPCUSBlib libs. To deal with the multicore part of building etc I have followed the Code Red guide, http://support.code-red-tech.com/CodeRedWiki/LPC43MultiCoreProjects .

So far I have checked whether the two HID devices running off the M4 and M0 enumerate correctly, and they almost do... There is a rather interesting little issue:

If I connect the USB port controlled by the M4 first, then connecting the M0 controlled USB port always fails with a "This device cannot start. (Code 10)" in Windows. It does not matter which core controls which USB port, the result is the same: the M0 controlled port fails to "start". If I however connect the M0 controlled USB port first, it enumerates OK - and connecting the M4 controlled USB port afterwards also yields a successful enumeration for the M4 controlled USB port.

The question is now what the cause for this behavior is. A few things that came to mind was:

1. The fact that in my code the M4 sets up its USB port hardware before releasing the M0 from reset could cause some issue with the M0 USB port.
2. The M4 interferes with the M0 USB port interrupts (due to buggy startup code, LPCUSBlib or LPCOpen).
3. The LPCUSBlib code the M4 runs accidently makes changes to the M0 controlled USB port registers (bug in LPCUSBlib or LPCOpen).

I have investigated the above, and for:

1. I changed the order of the code so that the M0 is released before the M4 does its USB port setup, but the problem was still there (I set a breakpoint in the M4 code before it entered its USB port setup to make sure the M0 had completed its USB port setup first)

2. The IRQ handler of the M0 controlled USB port (USB1 in my test) is never entered at all by the M4, which is expected since LPCUSBlib only enables IRQ for the configured USB port in NVIC (In HAL_EnableUSBInterrupt(uint8_t corenum) in HAL_LPC18xx.c).

3. This I have unfortunately not been able to fully check. Is there a way in LPCXpresso using an LPC-Link debugger to montor R/W access to a specfic memory range? In this case the memory range of the M0 controlled USB port registers. It does not seem so.
What I have done for 3. is to manually check LPCUSBlib code for any place where it accidently manipulates register(s) of the wrong USB port, but so far I have not been able to spot any issues. Anyway, if this would have been the problem, the M0 should have caused problems for the M4 if USB ports were switched - but it does not.

So, any ideas guys??