Posted by AvnerG on 2016-11-17 06:33

I was once again able to fix this by going back to the last version where the USB worked and then re-enter the changes I made. After entering all the changes it seem that the USB is still working....
This happened to me about 3 times during project development... please help me before it will happen agin...
Thanks,
Avner

Posted by diabolo38 on 2016-11-17 09:29

they use to be some bugs in the cdc i/f that coud hangs the com but those got fixed a while ago.

they are possible races condition between rx and tx if you handle them outside the interrupt handler context that can lead to strange issue. that is because ST midleware and HAL not proplery locking and disbaling interrupt to acess the usb ll.
if you’r using rtos such issue come even more easily.

I myslef faces lock-up using teraterm and other terminal emulator when mixing and doing concurent rx/tx (f4 h/w) .

You may have data and pointer corruption timing issues on added code causing trouble to the cdc side
could you share the cdc i/f code part where you hanlding new rx packet and where you do the tx  ?

Posted by AvnerG on 2016-11-17 10:35

Hi,
First of all thanks for the answer.
I can see what you mean about race conditions but I don’t think this is my case because I would expact the USB to work part of the times on the same version of FW.
In my case I have one “old” version of FW where the USB works always and one “new” version which is the old one with changes where teh USB is not working always.
Also I am not using an RTOS.
Can you please explain what you mean in: “I myslef faces lock-up using teraterm and other terminal emulator when mixing and doing concurent rx/tx (f4 h/w)” (sorry but I am still a beginner at this).

pointer corruption is more possible and I will check it.

those are my uint8_t CDC_Transmit_FS and CDC_Receive_FS:
static int8_t CDC_Receive_FS (uint8_t* Buf, uint32_t *Len)
{
/* USER CODE BEGIN 6 */
USBD_CDC_SetRxBuffer(hUsbDevice_0, &Buf0);
USBD_CDC_ReceivePacket(hUsbDevice_0);

memcpy(&USB_CDC_inBuffer,Buf,*Len);
newMessageExist = TRUE;

return (USBD_OK);
/* USER CODE END 6 */
}

uint8_t CDC_Transmit_FS(uint8_t* Buf, uint16_t Len)
{
uint8_t result = USBD_OK;
/* USER CODE BEGIN 7 */
USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*)hUsbDevice_0->pClassData;
if (hcdc->TxState != 0){
return USBD_BUSY;
}
USBD_CDC_SetTxBuffer(hUsbDevice_0, Buf, Len);
result = USBD_CDC_TransmitPacket(hUsbDevice_0);
/* USER CODE END 7 */
return result;
}

Thanks again for the help,
Avner

Posted by diabolo38 on 2016-11-17 18:36

if you did not read it yet i sugest you had a look at
http://stackoverflow.com/questions/33549084/stm32cubemx-usb-cdc-vcp/33555364#33555364

in your Transmit you shoud check that usb got connected basicaly that hUsbDevice_0 is not NULL.
also in between this 2 check and CDC_TransmitPacket use no CDC state change shoud hapen ie check and actions shall be atomic with respect to CDC events !
while executing CDC_TransmitPacket it’s best not new usb interrupt can occur or it may corrupt the internal USB controler state, i’m not sure if this happen how well the ST HAL and midleware behave

i remenber i could hangs terminal emulator (no more rx not tx) with simple loopback cdc f/w like yours why i suspect they are some races or tricky things going on the cdc class but i’m not to debug it .

I have a more complex cdc based app very stressing with free rtos i have critical section arround packet send and “shared critical” flag setup, This app brake or misbehave without the cirtical section so to me this where thing go wrongs.

vPortEnterCritical();
pDev->CurOutXFer=pXFer;
pDev->OutState=2;
status = CDC_Transmit_FS(pXFer->TxBuf, pXFer->TxLen);
vPortExitCritical(); //moving this before Tramsit cos races we get stuck

if you have 2 version one ok and not the 2nd is should be easy to spot where is the difference are no ?.