"Hangs" can be caused by different reasons, a software-bug could be one. If you have got a miniprog3 and when you can connect it to your board, you might see what the reason is.
Bad Power supply is another frequent source of errors, check for noise & spikes with an oszilloscope.
This is a brute force debug effort I would think. If you can debug while in-situ all the better.
I would start by creating an "alive" pin that I periodically pulse, and start with minimalist code
acessable, and increase code routines used/called until I hit a non responsive pin toggling.
HW wise look at code on any port with mixed I/O and make sure you do not have an infinite
loop situation if you examine a port with floating pin configured in it, and your code stays in
a loop trying to test a pin with unknown state.
Re. Bobs suggestion, use DSO, set triggering V first to Vdd + .7, then Vss -4.7, looking for
any pin getting a transient outside allowable I/O pin levels. Then use infinite persistence
on scope and look at supply railsfor a few seconds to see if you have load transients causing
supply to drop out of spec.
This is tedious at best.
Lastly look at Capsense layout and compare to recomendations in Cypress Capsense
I assigned LED on condition on while loop[while(!USBFS_bGetEPAckState(1))] in my code. And kept it for running.
After 3 days running this LED was seen in ON state.
Thus the execution is staying in this loop. Which kind of ACK this function provides?
then why the ACK is not received?