cancel
Showing results for 
Search instead for 
Did you mean: 

Looking for GCC based CDC code for F107 that actually works

DiBosco
Senior
Posted on May 19, 2016 at 17:42

Folks,

I've spent almost two weeks trying to get a virtual com port (VCP) working on an F107 with FreeRTOS and am getting problems whichever thing I try.

I started with an old version of FreeRTOS with old libraries and tried to get my F103 code working on the F107 to no avail.

I then tried using Cube code which seemed to crack it, but then it crashes when you replug the USB cable.

I then found some run-to-complete software here:

https://github.com/znuh/STM32_VCP

This  echoes back what is sent to it and thought I'd cracked it as you can plug and unplug as much as you want and it still works. However, when I integrated that into FreeRTOS I realised that this continually jumps into the USB OTG interrupt routine amd starves all tasks (even though it does echo data back to the terminal which sends data *to* the F107).

Finally, I've spent the whole day getting this code to work:

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Attachments/23342/STM32_USB-FS-Device_Lib_V3.3.0.zip

Which is the official STM code, but this does exactly the same as the first lot of run-to-complete software, i.e. it just never clears the interrupt bits. I've spent hours and hours trying to work out how to make the software clear those bits and it is beyond me.

So, does anyone have some software for the STM32F107 that enables be to have a CDC/VCP going on the OTG port please?

Or maybe they could tell me how on earth to stop this ST official code from doing nothing but jumping in to its OT interrupt service routine?

My sanity awaits a reply!

Thanks!
8 REPLIES 8
DiBosco
Senior
Posted on May 20, 2016 at 01:23

I've now tried creating a Cube project for the F429 with a CDC class and FreeRTOS and that works just perfectly.

Does anyone from the Cube team actually read any of these messages? Is there any way to get in touch and chat about why the F107 version does not work properly?

I feel like I'm talking to myself on this forum!

Thanks!

Posted on May 20, 2016 at 02:00

Well it is monitored, but likely not directly by the designers/engineers, who aren't going to participate in an open forum for a number of key reasons. The FAE's don't do their work here either.

You should probably find an FAE at your local distributor, or ST sales region. Like the ones running the seminars most local to you, and create a relationship there. Most of the engineering for the STM32 is out of France and Tunisia.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
DiBosco
Senior
Posted on May 20, 2016 at 10:48

OK, thanks for the info, Clive.

I know from a previous job that unless you sell tens of thousands of units getting an FAE to show any sort of interest is pretty much impossible. Finding one that actually knows anything about anything other than how to present Powerpoint slides is equally as difficult. The way manufacturers and distributors are set up, actually supporting small to medium sized companies is just not something any of the silicon manufacturers care about, which is why these forums can sometimes be very useful.

I appreciate the info though and will give it a try just in case!

DiBosco
Senior
Posted on May 20, 2016 at 20:06

FWIW I coped across the USB files from the F429 Cube project into the F107 Cube project, fiddled with appropriate headers and it now works. No idea what the F107 Cube generation does differently to the F429, but there's something funky going on there.

Real shame it uses this awful, obfuscated, macro-ridden HAL monstrosity. The older libraries were a million times better and they weren't the most readable.

I'll post the project on the FreeRTOS web site at some point.

tsuneo
Senior
Posted on May 21, 2016 at 19:38

> The older libraries were a million times better and they weren't the most readable.

 

Flooded interrupts bug and its fix for USB OTG Driver/Library v3.3.0 was discussed on this topics

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Yet%20another%20STM32F1057%20USB%20OTG%20driver%20issue%20%28VCP%20device%29

Tsuneo

DiBosco
Senior
Posted on May 25, 2016 at 11:44

Many thanks, it does indeed look like exactly the issue I am seeing. I shall give that a go.

I did do loads of forum searches and couldn't find that, but the search facility on this forum is bobbins!

Many thanks again, that could be very useful!

DiBosco
Senior
Posted on May 27, 2016 at 10:24

Sadly, this was nothing to do with the issue I have. I'm just continually jumping in to the ISR for USB and going here (which is the start of frame interrupt):

    if (gintr_status.b.sofintr)

    {

      /* Update the frame number variable */

      bIntPackSOF++;

      

      retval |= OTGD_FS_Handle_Sof_ISR();

    }

It comes out of the interrupt, then just immediately jumps back into it, enters the same part of the code and so on ad infinitum.

DiBosco
Senior
Posted on September 13, 2016 at 19:56

I'm bumping this in case anyone might just stumble across it. I'll be back on this soon and need to get this to work. Would be very grateful if anyone can help.

Many thanks.