Problems using USB on STM32F413 Topic is solved

[FXCoder]

Hi RM,
I think the issue was that I did the checkout on top of the old openocd directory.
Windows permissions silently prevented the checkout replacing all files it seems.
So I removed the openocd directory and then did the checkout again.

This time your latest version was copied in and starts when connecting to the ST-LINK on the Nucleo...

Code: Select all

Open On-Chip Debugger 0.10.0+dev-00146-g1025be363 (2017-06-11-20:37)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.org/doc/doxygen/bugs.html
Warn : Interface already configured, ignoring
Error: already specified hl_layout stlink
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v28 API v2 SWIM v18 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.269129
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

However, then when attempting to run the compiled test code binary under debug I get...

Code: Select all

Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x10006463
Warn : Cannot identify target as a STM32 family.
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected

So seems that the "cherry pick" patches from http://openocd.zylin.com/#/c/4045/ are perhaps not in your openocd build?

Thanks,

Bob

[FXCoder]

Hi Rocco & Giovanni.
Attached is a patch file for adding STM32F413.
This implementation works for the basic demo (3 x LED blink + Test Suite run by User Button).
The required CMSIS .h file is included, a .ld file, patched registry.h, etc.
Also board definition for STM32F413ZH-NUCLEO144 and a demo project.
I added the Flash Voltage table for F413 the calculation test of PLLR and other definitions including LPTIM (but not used anywhere yet in LLD)
More needs to be done for PLLR setting/use (similar to L4xx code it seems).

After getting the basic demo working I tried another demo which uses serial over USB.
However, that does not yet work and I have not had time to investigate in detail.
That project isn't in the patch file.

OpenOCD still needs updating to recognize the F413 chip ID.
I did not go into the task of doing that.
I just used ST-LINK UTILITY for flashing the NUCLEO-144 board for now.

Regards,

Bob

[FXCoder]

Hi Giovanni,
During testing Sven found DMA definition for SPI1TX was incorrect.
Updated patch file for registry.h is attached.

Cheers,

Bob

[FXCoder]

Hi Giovanni,
I have Serial over USB working on the F413-NUCLEO board with one problem (see below).
This required STM32_OTG_STEPPING to be set to 2 (not 1) in stm32_registry.h
Same change is required for F412.

I also see a possible bug in hal_usb_lld.c when handling wake-up.
The wake-up handler should clear RWUSIG but instead is setting it.

Line 548-549 currently...

Code: Select all

    /* Clear the Remote Wake-up Signaling.*/
    otgp->DCTL |= DCTL_RWUSIG;

Should be...

Code: Select all

    /* Clear the Remote Wake-up Signaling.*/
    otgp->DCTL &= ~DCTL_RWUSIG;

The problem I have is a hang when disconnecting the USB cable.
I'm looking through the USB driver suspend code for possible issues.
Using ST_LINK to view registers and check memory is a bit tedious so not much progress in pinpointing the problem at this stage.

Once openocd is updated to support F413 then that will help debugging a lot.

Thanks,

Bob

ps - I modified my F413 implementation a bit to account for the new CMSIS STM32F4xx.h file RM has added to trunk.
Before I just modified that file and used the same subtypes as the F412.
The official CMSIS header does not use subtypes for the F413 so I had to modify the board file and registry.h just to use xx.

[FXCoder]

Hi Giovanni,
USB demo is now working correctly.
It was an incorrect event index in the demo code that was causing the problem.
So I think USB is good enough for now to satisfy Sven's requirement.
I can create an updated patch file with latest changes and 2 x demo projects when you are ready.

Support for additional capabilities to be considered?
PLLR utilisation for SPI
FMI2C
LPTIM

Cheers,

Bob

[Giovanni]

RoccoMarco is thinking to create a separate hal_lld for F412 and F413, apparently there are too many differences compared to other F4s and the risk is to break things trying to support everything in the same file.

Giovanni

[FXCoder]

I agree with RoccoMarco's thoughts on creating a separate hal_lld.
The current F4xx family coverage versus the capabilities of F412-423 would make for a lot of conditional code.

So for the moment Sven can run with the interim implementation to continue his PecanPico9 development.

Cheers,

Bob

[Giovanni]

Hi,

Fixed the stepping issue as bug #861.

Are you sure about the suspend bit clearing? the manual is not very clear.

Giovanni

[FXCoder]

Hi Giovanni,
Regarding RWUSIG as described in RM0430, this is my reading...

OTG_DCTL RWUSIG (pg 1178) in device mode:
- RWUSIG will be cleared in hardware by the USB core 50 µs after being set by the application when exiting LPM.
- if RWUSIG is set by the application in Suspend state then the application must clear the bit within 1 ms to 15 ms.

Currently (apart from the one place in hal_usb_lld.c) RWUSIG is not set by the Chibios USB drivers.
The unusual/unlikely case of a Chibios user program setting RWUSIG would make the Chibios wakeup interrupt handler the logical place for RWUSIG to be cleared.
Hence I can see why the comment in hal_usb_lld.c says /* Clear the Remote Wake-up Signalling. */.
However, unless there is a need to cover that unusual case, then clearing RWUSIG in the Chibios wakeup interrupt handler appears to be redundant (perhaps a remnant?).
And setting RWUSIG, as is currently done, appears to be incorrect although somehow not obviously harmful.

The following seems to confirm that the wakeup interrupt is after the fact of Remote wakeup signalling either from the USB core or the setting of RWUSIG...

OTG_GINTSTS WKUPINT (pg 1146) occurs in device mode:
- during suspend(L2) in device mode when a resume is detected on USB.
- during LPM(L1) device initiated remote wakeup on USB.

Does the above help?

Cheers,

Bob

[Giovanni]

Implemented the change for USB wake-up (and a new API).

Giovanni