Dodgy MCU vendor code

[C]

AlfBaz,

Did not catch if you said which of the 3 stm32F4 discovery boards you have

This is for the STM32F401xB/C
USB on-the-go full-speed (OTG_FS)  RM0368
page 778/833
 
IN data transfers
?
 Packet write
This section describes how the application writes data packets to the endpoint FIFO when dedicated transmit FIFOs are enabled.

In polling mode, the application monitors the status of the endpoint transmit data
FIFO by reading the OTG_FS_DTXFSTSx register, to determine if there is enough
space in the data FIFO.

Think this is what you need to prevent an over run

I would first scan the library you have to see if this is used some place.

C

[AlfBaz]

In regards to your first post, I think you misunderstand my design requirements. I want to be able to communicate with the device from the PC. The intention has always been to create software on the PC side

I want to be able to either control the device, provide it with data or consume its data. I have no immediate plans to build some standard consumer gizmo such as a mouse, mass storage device or audio player. I simply want to use USB where in the past I may have opted for a 232 port and have the ability to transfer data/control in a fashion that best suites my custom application.

Did not catch if you said which of the 3 stm32F4 discovery boards you have

I have the F407 and F429

... Think this is what you need to prevent an over run

Thank you very much, I'll look for a reference to that in the library code although for some reason they have changed the names of the register names in the code as compared to the datasheet 

[C]

my post about the mass storage was just a great example of what you should expect when you apply it to what you are doing.
 
just replace mass storage for serial port. It should just work.

Just about all OS's have a terminal program like hyperterminal for windows.
You should work at this level with out adding code or any config on the host system.
Your usb serial port should just automatically show up in these programs serial port list just by you connecting your usb device to that new host.

although for some reason they have changed the names of the register names in the code as compared to the datasheet

I think the same is true for matching st's var names to var's defigned in usb doc's. I did notice that some of the usb orgs names are in the comments.

F407 and F429 are very nice

If it was me and I needed to write software for both the PC side and the stm32 side and I had a usb connection like this, I think I would save the first virtual serial for a simple serial console

send the needed data between the two(PC & F4) in packets and skip trying to encode/decode to a serial stream.
It is very easy to send and receive packets of data with USB. Once you have a good foundation in place it gets very simple in fact.   

C

[C]

Hi AlfBaz

If you are still having problems, I have an Idea but you probably already thought of this.
One thing I have found is quick and easy tests make it easer to put in quick test patches to assist in converting something you have to a new purpose.

One of the virtual serial port examples I looked at is the the EVAL board version of chip you have on the discovery board. A true USB to physical serial port example.

The discovery board does not have the driver chip of the eval version but still has that serial port. If that port & it's pins are not in use on the discovery board you could easily add and remove a jumper between Tx & Rx pins of the mpu which would cause an echo back to the PC while connected.
You could get a good idea that the example works on the discovery board doing this.

Next step could then be to add the software equal of a OR gate in the Rx data stream of the serial port just do not use the second port of the or yet. Still have the echo and the patch is good.

Add a Tee connection to the TX data stream of the serial port, leave the second port of Tee unused. Still have the echo and the patch is good.

Connect the second output of the above Tee to the second input of above OR. Now with jumper on the pins you have a double echo when in place and a single echo with it out.

When you have this, change the above Tee to not send data any longer to the serial port. This should drop you back to a single echo even with the jumper in place.

When you stop sending the data to the serial port you open up seeing bugs in your patches or original code to do with speed over runs or overwrites that would not happen with the serial port slowing the data down. I would try sending some big files out and capture the echo so that you could use PC software to look for errors at this point. Note here that there could also be problems created by a pause between two larger files.

When you get to this point just do the same steps to the control and status paths of the serial port.

I do not think you are currently in such a need for program space that you really need to remove the serial port part of the software but is would be good to compare your inserted patches to the standard serial port library and adjust the positions if different. I would guess that virtual serial port uses standard serial port library or a small change of it.

When you get to this point change the above Software OR and Tee above to a 4 pole double throw switch in software so that you have USB to physical serial port switched to internal software only serial port.  The four are control data, status data, Tx data & Rx data.

Just an idea, I have found a bunch of small steps that you can test is faster then the a big hack to get to what you want.

C

[AlfBaz]

Thanks for the tips C, I appreciate your help.

The reason I was using the virtual com port example wasn't so I could do usb to serial, its because it was the only example showing the use of the CDC class. The fact that the majority of the extra code on top of the standard libraries code was designed for USB to 232 and my subsequent stripping of the UART code is the cause of the issues I pointed out in the start.

It's all working fine at the moment but I haven't gotten around to "stress testing" the DataTx function to see if the USB port sends data slow enough that I can corrupt unsent data by sending to much, to quickly from the main application. If it does I'll look into adding another user call back function, triggered in the ISR, to the ones already there, using the register you suggested earlier to set or clear an "atomic" flag