Problems using USB on STM32F413 Topic is solved

Use this forum for requesting small changes in ChibiOS. Large changes should be discussed in the development forum. This forum is NOT for support.
FXCoder
Posts: 48
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 6 times
Been thanked: 9 times

Re: Problems using USB on STM32F413  Topic is solved

Postby FXCoder » Sun Jun 25, 2017 5:20 am

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
Posts: 48
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 6 times
Been thanked: 9 times

Re: Problems using USB on STM32F413

Postby FXCoder » Fri Jun 30, 2017 12:05 pm

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
Attachments
add_STMF413_30-06-2017.zip
(130.45 KiB) Downloaded 10 times

FXCoder
Posts: 48
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 6 times
Been thanked: 9 times

Re: Problems using USB on STM32F413

Postby FXCoder » Sun Jul 02, 2017 12:56 am

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

Cheers,

Bob
Attachments
stm32_registry.h_02-07-2017.zip
(2.38 KiB) Downloaded 8 times

FXCoder
Posts: 48
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 6 times
Been thanked: 9 times

Re: Problems using USB on STM32F413

Postby FXCoder » Thu Jul 06, 2017 7:53 am

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
Posts: 48
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 6 times
Been thanked: 9 times

Re: Problems using USB on STM32F413

Postby FXCoder » Fri Jul 07, 2017 1:28 pm

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

User avatar
Giovanni
Site Admin
Posts: 10004
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 185 times
Been thanked: 168 times
Contact:

Re: Problems using USB on STM32F413

Postby Giovanni » Fri Jul 07, 2017 2:07 pm

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
Posts: 48
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 6 times
Been thanked: 9 times

Re: Problems using USB on STM32F413

Postby FXCoder » Sat Jul 08, 2017 7:19 am

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

User avatar
Giovanni
Site Admin
Posts: 10004
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 185 times
Been thanked: 168 times
Contact:

Re: Problems using USB on STM32F413

Postby Giovanni » Sat Jul 08, 2017 2:16 pm

Hi,

Fixed the stepping issue as bug #861.

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

Giovanni

FXCoder
Posts: 48
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 6 times
Been thanked: 9 times

Re: Problems using USB on STM32F413

Postby FXCoder » Sun Jul 09, 2017 3:53 pm

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

User avatar
Giovanni
Site Admin
Posts: 10004
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 185 times
Been thanked: 168 times
Contact:

Re: Problems using USB on STM32F413

Postby Giovanni » Sat Sep 09, 2017 12:24 pm

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

Giovanni


Return to “Small Change Requests”

Who is online

Users browsing this forum: No registered users and 1 guest