STM32F07x USB and HSI48 Support

[Giovanni]

Hi,

I got my board and tested everything. I had to make few changes because the PMA RAM is shared with CAN and made other small changes in order to keep everything working with other devices.

I committed a demo for the STM32072B-DISCOVERY too.

Thanks for all the work done, the RM was not very clear for me.

Giovanni

[M1Sports20]

I agree that the RM is not clear about the change they made to the USB peripheral.
Sorry I forgot to mention that the USB RAM buffer is shared with the CAN memory. I knew this and did not implement it because I wasn't sure how you handled situations like this in ChibiOS.

Once again, thank you for allowing this project being easy to work with.
I will grab the latest source and try this with my project next weekend.

Thanks,
Michael

[rew]

I needed this patch for the demo-app to compile:

Code: Select all

diff -ur app_orig/mcuconf.h app/mcuconf.h
--- app_orig/mcuconf.h  2014-11-19 04:10:02.000000000 +0100
+++ app/mcuconf.h       2015-01-09 10:35:25.924230790 +0100
@@ -164,3 +164,4 @@
 #define STM32_USB_USE_USB1                  TRUE
 #define STM33_USB_LOW_POWER_ON_SUSPEND      FALSE
 #define STM32_USB_USB1_LP_IRQ_PRIORITY      3
+#define STM32_USB_USB1_HP_IRQ_PRIORITY      3

Does the discovery use "vbussense"? I'll have to patch that before it runs on my hardware.

Update: Hmm. Only the "OTG" version of the USB module has this vbussense feature? ... OK. seems that way.

Hmm. It causes an

Code: Select all

Jan  9 10:57:19 assurancetourix kernel: [3044947.915882] usb 3-4: new full-speed USB device number 21 using xhci_hcd
Jan  9 10:57:21 assurancetourix kernel: [3044949.501219] usb usb3-port4: unable to enumerate USB device

when I single step it past chSysInit, but it ends up in _unhandled_exception without any dectection on USB when I simply run it.

[Giovanni]

Hi,

Thanks for finding, I implemented a slightly different fix, there is no need to update all the mcuconf.h files.

Giovanni

[rew]

Is there a better way to debug the "unhandled exceptions"? As far as I can see there are a whole bunch of exceptions, knowing which one triggered might help me find the problem. Similarly being able to backtrace, or maybe int the unhandled exception handler:

Code: Select all

volatile void *where_it_happened;
where_it_happened = /* magic with the stack... */ ;

so that in the debugger I can see where the exception happened?

The last time I had an unhandled exception in MY code, I was able to single step until it crashed. I had allocated 3*4 bytes for a variable that required 3*8 bytes. But in this case, things happen in code I'm not familiar with, so I need any help I can get.

[rew]

I'm one step further..... (I bought an STM32F072 discovery board to make sure that I am using the same hardware as you).

It seems st-util's flash loader in RAM does something that causes the unhandled exception.... Before main is called! (It doesn't hit my breakpoint set as "break main").

If I issue a "reset" after loading the program in flash, it works and wiggles the mouse.

[update]: Also runs on my hardware. One wasted stm32F072 discovery boad.

[rew]

I now have STM32F042F USB hardware.... This doesn't work..... The USB part that is....

The STM32F0 "registry" defines the '042 as a LD device, but then puts the "if '72 or '42 then it has USB" in the MD section. I moved that....

My application, as well as the demo app above loads and runs, but:

Code: Select all

Mar 22 15:31:33 assurancetourix kernel: [1916752.578901] usb 3-6: new full-speed USB device number 56 using xhci_hcd
Mar 22 15:31:33 assurancetourix kernel: [1916752.579045] usb 3-6: Device not responding to setup address.
Mar 22 15:31:34 assurancetourix kernel: [1916752.783169] usb 3-6: Device not responding to setup address.
Mar 22 15:31:34 assurancetourix kernel: [1916752.987211] usb 3-6: device not accepting address 56, error -71
Mar 22 15:31:34 assurancetourix kernel: [1916752.987257] usb usb3-port6: unable to enumerate USB device

Maybe the USB module is slightly different between the two? Nope: they are documented in the same datasheet. Maybe the USB module or the RAM is at a different address? Nope: USB module at 40005c00, buffer RAM 1k higher on both processors.

What I do notice is that the registers in the USB module are completely different:
on the '072:

Code: Select all

> dumpm 40005c00
40005c00  00006220 00007021 00000622 00000000 
40005c10  00000000 00000000 00000000 00000000 
40005c20  00009c00 00002200 0000a3de 0000008f 
40005c30  00000000 00000000 00008000 00000000 

On the '042:

Code: Select all

> dumpm 40005c00
40005c00  00000000 00000000 00000000 00000000 
40005c10  00000000 00000000 00000000 00000000 
40005c20  00009c00 00000000 00000000 00000080 
40005c30  00000000 00000000 00008000 00000000 

(Note that at offset 0x20 we see a mirror of the registers at 0x40, becuase 0x20-0x40 are "reserved". So read ...40 where it says ...20).

Any suggestions to get this to work?

[Giovanni]

I don't have 042 HW, from the RM it should be exactly the same.

I fixed the registry, thanks.

Giovanni

[rew]

If you PM me an address, I'll fix that "hw problem".

[Giovanni]

Hi,

I committed the changes to the F0 registry, now it is more detailed. Could everybody give it a try?

Giovanni