![]() USB_OTG_ReadPacket(pdev,ep->xfer_buff, status.b.bcnt) Status.d32 = USB_OTG_READ_REG32( &pdev->regs.GREGS->GRXSTSP ) * Get the Status from the top of the FIFO */ USB_OTG_MODIFY_REG32( &pdev->regs.GREGS->GINTMSK, int_mask.d32, 0) * Disable the Rx Status Queue Level interrupt */ (I've copied the actual function from usb_dcd_int.c below, with the troublesome lines pointed out.) static uint32_t DCD_HandleRxStatusQueueLevel_ISR(USB_OTG_CORE_HANDLE *pdev) This pointer is to the hardware interrupt configuration registers for the USB peripheral, so the actual data didn't disappear, however when the pointer is accessed, I get a fault, and I can see with my debugger that the pointer is invalid. The actual bug manifests as a pointer ( GREGS) becoming invalid even though the pointer had been used earlier in the same function. However if I compile with -O2, then the project will run for 10-15 minutes but then I'll get what looks like to me a stack overflow happening in ST's VCP driver code. If I compile the program with -O0 optimization, then it runs as expected indefinitely. I am porting an existing (working) project from the STM32F1 to the STM32F4, but I have added ST's standard peripheral library USB stack for VCP. I am working on an embedded project with the STM32F405 microcontroller, and have some really confusing behavior.
0 Comments
Leave a Reply. |