STM32F07x USB and HSI48 Support

[M1Sports20]

Hello,

I have added USB and HSI48 support to the STM32F0 series. I was wondering what would need to be done to get this patchset merged. http://sourceforge.net/p/chibios/feature-requests/40/

I did the development against the stable_2.6.x branch and tested it on a custom board using the STM32F072CB processor. Overall the patch was pretty simple. The most invasive part was changing the USB driver to support both 16bit and 32bit accesses to USB packet memory, this was done through a c pre-processor. I also tested on the STM32F4Discovery to make sure I did not break USB on existing STM32 parts. By default the USB driver uses the existing access mode, 32-bit. Switching to 16bit access mode requires enabling the c pre-processor.

Sorry, if I am spamming you but I was not sure if you actually use the sourceforge ticket system.

Thanks,
Michael

[Giovanni]

Hi,

I already saw the ticket, I am not sure if it will be merged in 2.6.x because that branch is only modified for bug fixes, I will consider it for sure in 3.0.

Giovanni

[M1Sports20]

There are a couple patch files that fix bugs on the stable_2.6.x branch. You may want to pull those in.

• Fixed typo HSE14 to HSI14
• STM32F0 medium device do not support USB (I guess this one doesn't need to be changed, if USB support is not going to be added on the 3.0 branch

I have not tried version 3.0, if it is somewhat stable maybe I will give it a try. I am at the beginning of a hobby project anyways.
I can then rebase my changes on this branch if it helps.
--
Michael

[Giovanni]

Hi,

3.0 is very stable and is nearing release now.

Giovanni

[M1Sports20]

Alright, I am moving to the 3.0 trunk. I will be using NIL.
Ignore the previous patches. I didn't realized that the STM32F0_MD line was the one you intended to have USB support for.
I will deliver a new set of patches soon.

[M1Sports20]

Hello,

I updated the ticket with a set of patches based off of 3.0 trunk (svn://svn.code.sf.net/p/chibios/svn/trunk@7504). I tested with NIL on my custom board(STM32F072xB) and the STM32F4 Discovery. Let me know anything I could do to help you get this in the mainline.

Thanks,
Michael

[Giovanni]

Hi,

I applied patches 1 to 2 (good work), I have doubts about the last one:

1) It does not update all registry files.
2) I am not sure about this part:

Code: Select all

  /* Last byte for odd numbers.*/
  if ((n & 1) != 0) {
    *pmap = (uint16_t)*oqp->q_rdptr++;
    if (oqp->q_rdptr >= oqp->q_top)
      oqp->q_rdptr = oqp->q_buffer;
  }

First why the cast to uint16_t instead of the type you introduced?
Second, probably the code should take care of the case where there are 1,2 or 3 bytes left when the type is 32 bits.

Giovanni

[M1Sports20]

As for part "last byte for odd numbers" and checking for 2 3 4 with uint32:

To summarize what I have read from the ST reference manuals:
The USB data in ST parts is always 16 bits wide. This patch just accounts for the difference between how ST packs the data differently between modes(different chips support different modes). There is always a mirror of the data. The mirror is used for the USB peripheral block while the Cortex uses the original location. A hardware arbitrator handles keeping the PMA data in sync between the locations.

For example, on the STM32F4 USB(access scheme 1x16 bits / word) data looks like this(x is not used):
XXXX XXXX AAAA BBBB (cortex accesses this)
XXXX XXXX AAAA BBBB (usb block accesses this)
XXXX XXXX CCCC DDDD (cortex accesses this)
XXXX XXXX CCCC DDDD (usb block accesses this)

on the STM32F0 USB(access scheme 2x16 bits / word) data looks like this:
AAAA BBBB AAAA BBBB (upper 16 bits are usb block, lower 16 bits are for cortex)
CCCC DDDD CCCC DDDD (upper 16 bits are usb block, lower 16 bits are for cortex)

I believe this is why the newer mode(2/16 bits / word) has twice as much PMA memory as they are not wasting the upper bits. I am showing you these data structures as you can see that we only ever have to handle the last odd byte(if one exists). There can never be 2-3 bytes of odd data.
Another unrelated fact: the access scheme "1x16 bits / words" must be accessed with 32 bit alignment, where as "2x16 bits / words" can be accessed by 32/16/8 bit alignment.


As for not applying the update to all register files:
I wasn't sure how you handled this, the default mode is the old mode(FALSE), I only updated the chip that had the new mode so I only changed that registry file. I can go through and add it to each registry file if you like. I will have to check and see which product lines support which modes.

[Giovanni]

Hi,

I will adjust the other registers but keep in mind that changes can affect other things, I don't necessarily know what.

Giovanni

[M1Sports20]

Thanks for this open source project and working with me. Your easy to work with and make working with this project an enjoyable experience.

When the new #define flag is set to FALSE there should be no changes to existing products, but yes I understanding when changing existing code there is a risk of breaking existing functionality. If you have any problems related to this fee free to email me and I can take a look at it. Thanks.

There are more than one product that support the new mode. From looking at a few technical reference manuals I see that chips STM32F072xB and STM32F373xx support only the new mode(2 x 16 bits / word) while chips STM32F303 and STM32F407 support only the old mode (1 x 16 bits / word).