Showing results for 
Search instead for 
Did you mean: 

PSoC™ 4

Contributor II

I'm using USB Audio code similar to the CY8CKIT_046_USB_Audio example project, in CY8C4246AZI-L433, and when the IN/OUT bandwidth is high, on one computer, in particular, the code will consistently lock up inside this loop:

/* Request for dynamic re-configuration of endpoint. */


/* Wait until block is ready for re-configuration */




This register is at memory location 0x402c0050, and when the PSoC is locked up in this loop, that location reads 0x00000003 = 0b00011:

  • DYN_RECONFIG_RDY_STS = 0b0 = not ready for reconfiguration
  • DYN_RECONFIG_EPNO = 0b001 = Endpoint 2 ("Use 0 for EP1, 1 for EP2, etc.")
  • DYN_CONFIG_EN = 0b1 = enable the dynamic re-configuration for the selected EP

So we've enabled re-configuration on EP2 (IN audio) but it's not entering the ready state.  Any idea why?

Before this happens:

  • Data is flowing normally IN (EP2) and OUT (EP1), with feedback IN packets regularly (EP8)
  • The IN packets start to become identical. Buffer is not being updated?  This might actually be the root of the problem.  They are still changing length, though, to maintain the correct sample rate.
  • The feedback packets stop
  • After another ~35 OUT packets on EP1, the OUT packets stop
  • After another ~35 IN packets on EP2 (all of which are now identical), the IN and OUT interfaces are both put into zero-bandwidth mode
  • The OUT interface is put into active mode
  • OUT packets are transmitted on EP1
  • Feedback packets are transmitted on EP8, all zeros
  • After ~40 OUT packets on EP1, the firmware locks up in that loop, seemingly during reconfiguration of EP2.
2 Replies

Hello JoBr_1593366 ,

Can you please attach your project as well as the steps to recreate this issue.

This will help us to get a better understanding of the issue.

Best Regards


Contributor II

No, I can't post the project here.  It is the same project I have been asking you about by email.

I have noticed that the IN packets sometimes contain data from the preceding OUT packet, after the first 32 bytes, which must be because the data is still in the USBFS component's common area:

For IN transfers the DMA tries to fill the common area as much as possible to provide the USB block with data to send. The DMA also pre-loads 32 bytes into the endpoint buffer before allowing the host to start reading it. This action adds time for the DMA to write next chunks of the data while the host reads the pre-loaded data. In case the DMA fails to load data in time (before the host reads it), the old data which resides in the common area will be sent on the bus.

That explains why the first 32 bytes of the IN packet are being updated, but the remaining bytes are copied from the previous OUT packet:



next IN:


So there is a problem with the DMA failing to load data from inRam to the USB component in time for the host to read it.  Do you know any reason why that might happen?