lpcware

USB interrupts causing AES (DMA) freezes on LPC18S37

Discussion created by lpcware Employee on Jun 15, 2016
Content originally posted in LPCWare by chishm on Wed Jun 17 04:03:02 MST 2015
I am trying to use the LPC18S37 chip to do AES encryption at the same time as using the USB bus. I am driving the AES engine using DMA (through the Chip_AES_OperateDMA and related functions). I have tried using both nxpUSBlib and the ROM USBD API (at different times) to create a USB Mass Storage Device (UMSD).

There is an issue where USB interrupts cause the AES engine to freeze. The DMA stops transferring and any API calls that affect the AES hardware will not work. This state persists even with a software reset, and I have to hard reboot the board to get the AES engine working again.

To illustrate this, I've modified the LPCOpen 2.18 usbd_rom_msc_ram example to do some AES processing. See the attached msc_main.c file for the changes (between "New code" and "End new code" comment blocks). All other files are the same as in the example. This code is meant to run the AES engine repeatedly, and blink an LED to indicate that it is working. The USB portion operates via interrupts, so it will still function as a UMSD like in the original example.

The LED will blink for a few seconds, then freeze. With a debugger attached I can see that when this happens Chip_AES_GetStatusDMA always returns busy. If I comment out the line
NVIC_EnableIRQ(LPC_USB_IRQ);
then the AES engine never freezes.

Things I have tried so far:
[list=1]
  [*] Operating the AES engine without DMA. The engine doesn't freeze but this method of operation is not suitable. I need the DMA to work so I can continue processing other tasks on the CPU while encryption takes place.
  [*] Changing how USB interrupts are handled. If I make the USB interrupt handler take longer to run (by adding a delay loop, for example) then the AES engine is more likely to freeze sooner. If I make the handler take less time (by not actually doing anything) then the AES engine runs for longer before freezing. So there seems to be a correlation between interrupt processing time and AES engine freezing.
  [*] Using the other USB port. Freezing occurs no matter whether I use USB0 or USB1 on the chip.
  [*] Using a different USB stack. Freezing occurs with both the nxpUSBlib and with the USBD ROM API.
[/list]

I have run out of ideas on how to fix this, and would appreciate any help.

If this is a silicon issue, are there any workarounds?

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

Outcomes