LPC4357 Multicore USB Problem

[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??

Thanks,

[lpcware]

Content originally posted in LPCWare by GTA on Sun Aug 11 19:02:48 MST 2013
Hello again,

after some more looking at this, now incl. analysis of the actual data output on the USB buses (which did not make sense all of the time), another option came to mind:

4. The memory maps used for the M0 and M4 builds could lead to that the linker put data into the same memory regions for both the M0 and M4, leading to funky stuff during execution.

I have used the wiki suggested LPC43x7-M0_BankB.xml for the M0, but that still contains RamAHB32 etc, just as the default LPC4357 memory map does (which I used for the M4 - the wiki did not say anything in particular regarding not using the default here). So, theoretically 4. could be a problem.

I edited the memory map settings for both the M0 and M4 not to list RamAHB32 etc, but just the necessary (M4: flash bank A and B plus RamLoc32; M0: flash bank B plus RamLoc40).

This seems to have done the trick. Now both the M0 and M4 enumerate OK in the tests I have done.
USB1 outputs some odd data though, regardless of if it is driven by the M0 or M4 - I will take a look at that (probably the LPCUSBlib code for USB1 which is not all OK).

Re. the multicore memory maps, it could be good if Code Red clarified this a bit more in the wiki to avoid these types of issues for users starting up their multicore projs.

BR,