stm32f4-discovery USB examples don't work about libopencm3-examples HOT 18 CLOSED

In this case, the GPIO PA9 must be configured as vbus sensing function…

No, like I wrote in my first comment on this issue, OTG_FS_VBUS is not an AF and PA9 should for that reason not be configured to AF mode. The VBUS sense circuitry is directly connected to the pin and will sense it regardless of what mode it is in.

According to documentation, AF10 is not a valid AF for PA9, and as far as I can remember in practice will sink current. In other words, if you configure it like that, you'll be feeding 5V into a pin that's trying to output low. VBUS can generally source plenty of current to overcome the drive strength of the output, so it will still appear to work normally, but the chip will get noticeably warmer from all the power going into that pin.

from libopencm3-examples.

OTG_FS_VBUS being an AF was always a misconception. PA9 should be configured in analog mode when used to sense VBUS, and as such is not listed as an AF anymore.

I don't really think this is the root of your problem, but if it is, it should be fairly easy to diagnose with the debugger:

If the USB core is otherwise configured correctly, the BSVLD bit in OTG_FS_GOTGCTL will indicate whether VBUS is present or not. When BSVLD is set, the DP pullup is enabled.

You can disable VBUS sensing by setting the NOVBUSSENS bit in OTG_FS_GCCFG. Setting it will make the USB core always assume VBUS is present.

from libopencm3-examples.

Hmm, only bit16 is set. Forcing bit 21 of OTG_FS_GCCFG helps out, indeed. So, what do you want the proper fix to be here? Let users handle this or do we set the bit from within driver->init() ?

Seems like this bit is only valid for revisions < 0x200, so we'd have to check for that as well.

from libopencm3-examples.

Exactly right @felipebalbi the difference is the treatment of bit 21. New versions of the USB hardware need it set in order to work.

from libopencm3-examples.

@ChuckM Do you have a reference for that assertion?

I'm not aware of VBUS sensing not being available in newer parts, and if it's supposed to work, disabling it is just hiding the issue, not solving it.

from libopencm3-examples.

Is it just that https://github.com/libopencm3/libopencm3/blob/master/lib/usb/usb_f107.c#L65-L71 is missing from the usb_f207 file? So this is only noticed on boards that have the OTG_HS periph wired up?

from libopencm3-examples.

@karlp I can test that out later. But this begs the question: if they have the same USB IP, why two different drivers?

from libopencm3-examples.

they share a lot of code, but they have different numbers of endpoints and a few other things. I'm sure someone with infinite time could rewrite the driver layers to have less duplicated code.

I'm still a bit curious though, MB997D is the newest version of the original f4 disco, I've not checked the schematics, but if they really changed it to the OTG_HS periph instead of the OTG_FS periph that would be a breaking change for all the other existing demo code out there too (ie, not just libopencm3 exampl code). They're not even on the same pins.

if it is on the OTG_FS peripheral, then you should already have the code listed, and it should already be doing the right thing? Are you sure your local library is uptodate? I only have an earlier version of the board.

from libopencm3-examples.

As far as I can see, there's no relevant changes in the f4 disco schematics, it's still connected to OTG_FS.

Furthermore, latest revision of RM0090 still lists bit 21 of OTG_FS_GCCFG as being NOVBUSSENS, not VBDEN. I guess this could be checked by reading out OTG_FS_CID with the debugger.

Try checking the level on PA9 with a scope, check that you actually have 5V there.

from libopencm3-examples.

Any further updates here?

from libopencm3-examples.

No updates, closing.

from libopencm3-examples.

The stm32f4 examples is not workable because the vbus sensing is not proply configured.

Vbus sensing is enabled by default in the driver code.
https://github.com/libopencm3/libopencm3/blob/ff9664389bfb560145aa3b36ad8368900c57c3d8/lib/usb/usb_f107.c#L70

In this case, the GPIO PA9 must be configured as vbus sensing function, however, only PA11, PA12 is configured in all of the usb examples in stm32f4 directory.

This problem could be solved by properly configure PA9 pin or disable vbus sensing. By adding following code to disable vbus sensing, the example is workable for me.

OTG_FS_GCCFG |= OTG_GCCFG_NOVBUSSENS;
OTG_FS_GCCFG &= ~OTG_GCCFG_VBUSASEN;
OTG_FS_GCCFG &= ~OTG_GCCFG_VBUSBSEN;

from libopencm3-examples.

I have this problem too. This problem can be solved by just update the version of stink. With the old version of stink, the disc1 board can only be powered by the pc USB port. If you use other external USB port directly from adapter, then the stm32f4 mcc will not be powered. The new version of the stink firmware solve this bug.

from libopencm3-examples.

Following the discussion, I got the usb example on my stm32f4 discovery board to work with,

vim  ./libopencm3/lib/usb/usb_f107.c
70     // OTG_FS_GCCFG |= OTG_GCCFG_VBUSBSEN | OTG_GCCFG_PWRDWN;
71     OTG_FS_GCCFG |= OTG_GCCFG_NOVBUSSENS | OTG_GCCFG_PWRDWN; 

I would like to encourage re-opening the issue, to provide more visibility - even if it's not clear how to proceed with a generic patch to cover all use-cases.

It is quite possible to waste a lot of time, assuming user error, and buying and testing different boards, before discovering the solution.

from libopencm3-examples.

My god took me an hour to find this :P
Would it be at least useful to update the examples repo with some comments on this? The fact that PA9 does not require any initialization confuses the user in the examples, wrongly assuming that PA9 is not uses at all!

from libopencm3-examples.

Some comments to the original post:

• "because the USB IP doesn't realize that VBUS is above 4.4V" - I don't think the threshold is 4.4V. If you go through the reference manual and the USB OTG specification for "b-session valid" it should be between 0.8 V and 4.0 V. ST recommends in AN4879 (FAQ section or here) applying 0.7 * Vcc for their products (so 2.3V in this context) and not above 4.0V (to avoid breaking the Vcc+4V limitation if the chip is unpowered) and a super-user at the ST forums experimentally determined the threshold to be around 1.5V (like a Schmidt-trigger input) at 3.3V Vcc. I have been checking this because some boards have PA9 connected to Vcc instead of VBUS, which for a bus-powered device should therefore be fine.

• "this same failure on two different boards (stm32f4-discovery and stm32-h405 from Olimex)" - When it comes to the Olimex STM32-H405 the schematics show that PA9 is not connected to anything except header EXT1-4. It can easily be bridged to USB VBUS on EXT2-23 I guess, in case the firmware doesn't disable VBUSSENSE. This board also have the external D+ pullup circuitry needed for STM32F103, but I guess it won't help for the F407 USB if it is "stuck" on missing VBUS.

What remains unclear here is why newer STM32F4-Discovery boards don't work. In latest revisions of its reference manual, ST has removed the schematics. Can someone please verify (ideally providing schematics) that USB VBUS is no longer connected to PA9 like it was in earlier board revisions?

E.g the STM32Duino project has gone as far as disabling VBUSSENSE by default in their library, letting users enable it if PA9 has been hooked up correctly. This would be a good solution for libopencm3 also IMO. EDIT: See libopencm3/libopencm3#1256

from libopencm3-examples.

The current USB implementation in libopencm3 contains several bugs. The way VBUS sensing is implemented is close to a bug (unfortunate and undocumented default setting that cannot be changed with libopencm3 functions). Likely many people have wasted hours until they identified the root issue, or have never succeeded and turned away from libopencm3.

The main problem however is that the project seems to be unable to fix them. The last time a USB bug was "fixed" was more than 3 years ago (libopencm3/libopencm3@26ab78a). And it broke more than it fixed and should be undone. There are several PRs to address some of the bugs, with no progress.

I don't have any real insights into the project. I can see that @karlp has an active role. But he seems to be the only one, and he does not accept any USB changes - for reasons unknown to me. I also understand that there was a good system for integration testing the USB code. But - as far as I can tell - it's broken now.

I'm sorry to say so, but if you need USB functionality you are probably better off writing your own USB extension for libopencm3 or move to a different framework altogether.

from libopencm3-examples.

Maybe there is an assumption the issue pertains to just vbus sensing, when the default and undocumented behavior is to break all usb functionality for f4. It is easy to workaround - and usb functionality then works great from my experience. Tthe problem is one of visibility and having the wrong expectations about code presented as working examples.

from libopencm3-examples.