STM32F07x USB and HSI48 Support

[Giovanni]

This new mode is exclusive for the F0 apparently so don't worry.

Giovanni

[M1Sports20]

Makes sense. Although, I believe the new L0 series also has the new access mode.

By the way, I believe I kind of found a bug in the USBv1 driver. BTABLE is multiplied by 2, looking at the datasheet I do not know why this occurs. Anyways, it doesn't matter because currently BTABLE is defined to be 0..

This was only by observation when looking at ST datasheets. I did not test it by changing BTABLE to a different value.

Just an FYI if you have future problems when/if BTABLE ever changes value.

[Giovanni]

Hi,

I will look into the BTABLE issue.

I have a problem with the PMA handling, from what I read on the F0 manual, the structure of the PMA is not different from all the other devices: F1, F3, L1. The change related to the PMA handling is not required in my opinion.

The differences that I found are others:
1) The PMA is 768 bytes long instead of 512 (this should become a registry key).
2) There are extra registers which are not currently handled: USB_LPMCSR and USB_BCDR (the presence of those should also be in the registry when support will be introduced).

Giovanni

[M1Sports20]

Hello,

Without this patch the F0 series USB won't work. I wonder if anyone on this forum has an STM32F072B-DISCOVERY to give you a second datapoint that this change needs to be made for the F0 series to support USB.

Unfortunately, the documentation shows this difference in a very subtle way and is not very clear. Here is the small difference:

In the STM32F37xx reference manual section 29.6, page 821:
All register addresses are aligned to 32-bit word boundaries although they are 16-bit wide. The same address alignment is used to access packet buffer memory locations, which are located starting from 0x4000 6000

In the STM32F072xx reference manual section 30.6, page 876:
The peripheral registers can be accessed by half-words (16-bit) or words (32-bit).
(They leave out the statement about "access to packet buffer memory must use the same alignment". They only mention peripheral registers can now be accessed by 16-bit or 32-bit.)

Again, it would be nice if someone had an F072 Discovery to give you a second datapoint.

Thanks,
Michael

[Giovanni]

It can be accessed at 32 bits but also at 16 bits like previous implementations, the memory layout seems to be the same, interleaved 16 bits words, why should it stop working?

Anyway, I will get one of those boards too.

Giovanni

[avrhack]

Again, it would be nice if someone had an F072 Discovery to give you a second datapoint.

Thanks,
Michael

I have the F072 Discovery - interested in the 072 and 042 because of crystal-less USB and also TSSOP20 in the case of the 042.

Will take a look as soon as I get some time; what exactly do you want me to re-test / confirm for this second datapoint?

[M1Sports20]

We will have to have a USB application that works on the STM32F072 Discovery. After that I would like to see if the application runs without applying a specific patch. I believe it will not work.
I can give more detailed instructions later, either sometime today or tomorrow.

I have created my own board and am using the Crystal-less USB. It works great, but currently I am manually setting the registers needed for crystal-less USB. Unfortunately, this is specific to ST and I don't think Giovanni likes to integrate specific drivers into the OS/HAL.(Is this true?).

I could provide a patch where if a flag is set in mcuconf.h(something like STM32_CRYSTAL_LESS_USB = TRUE), the USB driver would correctly setup CRS registers for this to occur.
It would be kind of ugly since the USB driver would modify CRS registers to tune off of the USB SOF packet and spin shortly while waiting for the clock to be corrected(similar to how spinning occurs waiting for HSI clocks to become in the rdy state).

This reason why it's kind of ugly is the CRS tuning source doesn't have to be USB it can also be MCO, PLL, etc. This solution would only work if the tuning source was USB. If we would like to support all tuning sources and other configurations we would need a CRS driver.

I do believe that 90% of people using CRS would tune it of off USB since that is the main selling point of the STM32[FL]0 series that support USB.

[avrhack]

We will have to have a USB application that works on the STM32F072 Discovery. After that I would like to see if the application runs without applying a specific patch. I believe it will not work.
I can give more detailed instructions later, either sometime today or tomorrow.

I have created my own board and am using the Crystal-less USB. It works great, but currently I am manually setting the registers needed for crystal-less USB. Unfortunately, this is specific to ST and I don't think Giovanni likes to integrate specific drivers into the OS/HAL.(Is this true?).

I could provide a patch where if a flag is set in mcuconf.h(something like STM32_CRYSTAL_LESS_USB = TRUE), the USB driver would correctly setup CRS registers for this to occur.
It would be kind of ugly since the USB driver would modify CRS registers to tune off of the USB SOF packet and spin shortly while waiting for the clock to be corrected(similar to how spinning occurs waiting for HSI clocks to become in the rdy state).

This reason why it's kind of ugly is the CRS tuning source doesn't have to be USB it can also be MCO, PLL, etc. This solution would only work if the tuning source was USB. If we would like to support all tuning sources and other configurations we would need a CRS driver.

I do believe that 90% of people using CRS would tune it of off USB since that is the main selling point of the STM32[FL]0 series that support USB.

There is lots of specific code for different ports so that shouldn't be a big problem although of course I'll let Giovani respond. I already asked about the 042 and 072 and he immediately integrated the CMSIS headers which was great.

That said, I think when there is a very specific feature like this there's no real issue configuring a few additional registers like the CRS for sync using the application itself - the key is whether ST is likely to bring in CRS on other STM32 and my guess is that they will and it will become common on all new ones, in which case it should go into the STM32 HAL

[M1Sports20]

Sorry for the delay,

Here is some test code that should work for STM32F072-Discovery. When USB is working this example should enumerate as a USB mouse device and move the mouse back and forth.
Here are the steps I suggest for showing that a patch is needed to support USB on STM32[F|L]0 devices.

0. Connect discovery board to host machine with both usb cables.
1. Download ChibiOS

Code: Select all

git clone https://github.com/mabl/ChibiOS ChibiOS-RT

2. Extract tarball attached to this forum into a directory next to Chibios.

Code: Select all

mkdir app; cd app
tar xzf stm32f072-discovery.tar.gz

3. Modify the following file: os/hal/ports/STM32/STM32F0xx/stm32_registry.h. Make sure "STM32_HAS_USB" on line 195 is set to TRUE
4. Patch ChibiOS to support USB for STM32F0 devices. Hunk #4 will fail, this is OK for this test.. It has to do with HSI48 and USB support, and I can rebase the change later if Giovanni needs me too.

Code: Select all

wget http://sourceforge.net/p/chibios/feature-requests/_discuss/thread/46a5a501/9e9b/attachment/0003-Add-USB-support-for-STM32F0-product-line.patch
patch -p1 < 0003-Add-USB-support-for-STM32F0-product-line.patch

5. Build project and flash on device. The mouse should NOT enumerate or be moving with this example. Also the discovery board should be in symbol _unhandled_exception.
6. Patch ChibiOS for multiple access modes. --

Code: Select all

wget http://sourceforge.net/p/chibios/feature-requests/_discuss/thread/46a5a501/9e9b/attachment/0004-USB-driver-support-both-1x16-and-2x16-access-modes.patch
patch -p1 < 0004-USB-driver-support-both-1x16-and-2x16-access-modes.patch

7. Build project and flash on device. USB mouse shoud enumerate and work.

Please let me know your results.
Giovanni, after people test this code, let me know if I need to take anymore actions to help you integrate the USB code into ChibiOS? Thanks for your time.

--
Michael

[Giovanni]

I have not forgot this, I am waiting for a board in order to be able to test the changes.

Giovanni