Debugging STM32F042 USB support.

[rew]

I'm trying to get USB to work on the STM32F042.

So far I've determined that:

Code: Select all

  40005c40  00009c00 00000000 00000000 00000080 

the module has 0x9c00 in the CNTR register and 0000 in the ISTR register. ISTR seems to indicate that no interrupts are pending, whereas CNTR has a few interrupts enabled.
My host reports:

Mar 26 17:04:41 getafix kernel: [5967910.876114] usb 6-2: new full-speed USB device number 114 using uhci_hcd
Mar 26 17:04:42 getafix kernel: [5967911.288022] usb 6-2: device not accepting address 114, error -71

so things are not working. And I've placed a breakpoint on "break VectorBC": no interrupts are triggered.

I'm assuming that the code is waiting for a

Code: Select all

Bit 15 CTRM: Correct transfer interrupt mask

correct?

How do I proceed from here?

[Giovanni]

If no interrupts are triggered it could be anything, from I/O setup, to clocks, to lack of pullup resistor on D+. The driver has been tested on the F072 Discovery board only (and F1, F3, L1 devices).

Giovanni

[rew]

There is no pullup on the D+ line on the board. This is consistent with my boards for the '072R chip (and the discovery and nucleo boards).

The PC detects the pullup on the D+ line. That's what triggers:

Code: Select all

Mar 28 13:22:08 assurancetourix kernel: [2427818.053757] usb 3-6: new full-speed USB device number 64 using xhci_hcd

(my home system tries a few times and gives up, my work system keeps trying).

(I have mis-wired boards by crossing D+ and D-. The symptom then is that it reports a "new low-speed USB device" when you expected a "full-speed" device.).

stm32_usb.h has a nice definition of struct stm32_usb_t. But when I do:

Code: Select all

(gdb) print (struct stm32_usb_t *) (0x40005c000)

I get:

Code: Select all

No struct type named stm32_usb_t.

Is there a way I can make GDB learn this structure? It makes debugging this a lot easier.


Edit: Would it help to enable the USB module?

Code: Select all

usb_lld.c:      rccEnableUSB(FALSE);

is the only reference (in a c-file) to rccEnableUSB... (and indeed the bit is off in the RCC).

Update: I was looking at the wrong bit. Sorry. Off-by-one. Even though I can't find the code that enables the USB module, it seems enabled.
Update2: the rccEnableUSB enables it, just not hte LP version (whatever that is) when given the "FALSE" argument.


Update3: Why does the manual have "USART4RST" sandwitched between IOPEEN and IOPCEN in the RCC register map? Confusing! The bit is called "IPDEN".

[rew]

Code: Select all

  SYSCFG->CFGR1 |= 0x10;

was missing.

I now have it in my "main".
Strategy question for Giovanni: Is this a "user needs to configure his device properly before enabling the USB"? or something chibios can/should do? In the case at hand USB CANNOT work without the remap because it is connected to pins that simply are not brought out onto the package. That would make an argument for putting this in chibios. On the other hand, other remap-choices are more of a choice that helps in avoiding DMA or IRQ conflicts.

On second thought...
#define STM32F042x6
does not specify that I have the "F" version with only 20 pins. The "not available" happens on the 20 and 28 pin devices, and the remap option becomes a "choice" on the bigger devices. (or maybe they disable the remap option).

[Giovanni]

Handling of remapping is missing entirely and. especially for DMAs, this is a problem.

Something for post 3.0 however, I have to draw a line or the 3.0 release will never happen.

Giovanni