Dear Forum Readers and Visitors,
I'm seeking your advice with the USB VCom App.
I want to use it to send message from my RelaxKit ( USB client ) to a computer ( USB host ).
Depending on the rest of my program, USBD_VCOM_SendString function never exits.
This is not a general behaviour, but only occurrs after several messages have been sent successfully by calling USBD_VCOM_SendString .
In my current program this seems to depend directly on the number of messages I try to send - if I send one message less, everything is working fine, if I add the last message again, it doesn't return from the last call to USBD_VCOM_SendString.
It doesn't matter if I'm making this calls from the same function or move one call to a subfunction and try calling USBD_VCOM_SendString from there.
Using the debugger I see that the program never leaves Endpoint_Write_Stream_LE (const void *const Buffer, uint16_t Length, uint16_t *const BytesProcessed) in file [ \Dave\Generated\src\USBD\usbd\USBD_EndpointStream_XMC4000.c ].
In this function, in the while (Length) - loop, ep->InInUse evaluates according to the debugger to 1 which leads to the immediate skip of the rest of the loop-content because of the following if-clause:
if (ep->InInUse) continue;
.
A manual change of ep->InInUse didn't help either, this lead to a BusFaultException.
The behaviour doesn't strictly depend on the number of messages in general, just in this situation, because in the beginning of my program I can send many messages using USBD_VCOM_SendString ( until a button is pressed ) without any troubles.
Some details on my setup:
Development Board: Relax Kit
Dave Version: 3.1.10 , Installer build : 2014-02-26
USBD_VCOM version: 1.0.0
USBD version: 1.0.0
USBD_LLD version: 1.0.0
CLK001 version: 1.0.42
Any help, hints, possible solutions or investigations on that subject are highly appreciated.
Kind regards
dragol
PS.: Adding a big manual message fifo and sending only one message from a seperate output function each time the output function is called, is not the way I want to ( try to ) work around this issue, because I fear running out of RAM when deploying this in my final application, which probably will need quite much string parsing and buffering on its own.
