USBDevice not working on STM32H743, debug and trace problems #13641

JojoS62 · 2020-09-20T16:41:44Z

Description of defect

I tried to activate USBDevice on a custom target with Devebox H743 board. The USB code compiles for this target, but the host does not get a valid USB device information. The same issue is observed on a Nucleo H743ZI2 board and reported in the forum:
https://forums.mbed.com/t/mbed-nucleo-h7743zi2-doesnt-support-usbdevice/8241/7
So it does not look target hardware specific.
Tests with different sources for USB clock (HSI48, PLL3Q) were not successfull. So I tried to set breakpoints in the HAL_USB callbacks. These breakpoints were not hit. Only when I set a breakpoint in USBPhyHw::_usbisr(void) the target stops and after continue, also the bp in the SOF callback is reached.
Next step was to add tr_info() calls and enable mbed_trace. This did not work also. An initial printf("hello world\n") is printed, followed by a 0xff hex.

A test with the same program and modified USBPhy_STM32.cpp on a F401 MCU is working as expected. The USBMidi is recognized by the windows host and midi output from the sample code is generated. The trace outputs from the callbacks are pinted as well.

Don't know it it maybe related to this H743 issue:
#11422

Target(s) affected by this defect ?

STM32H743xI
NUCLEO_H743ZI2

Toolchain(s) (name and version) displaying this defect ?

GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.3.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli

How is this defect reproduced ?

use a simple USBDevice test program

#include "mbed.h"
#include "USBMIDI.h"
#include "mbed_trace.h"

DigitalOut led1(LED1);

int main() {
    mbed_trace_init();
    sleep_manager_lock_deep_sleep();
    printf("hello world\n");
    
    USBMIDI midi(false);
    midi.connect();

    while (1) {
        for(int i=48; i<83; i++) {     // send some messages!
            led1 = !led1;
            if (midi.ready())
                midi.write(MIDIMessage::NoteOn(i));
            ThisThread::sleep_for(250ms);
            if (midi.ready())
                midi.write(MIDIMessage::NoteOff(i));
            ThisThread::sleep_for(500ms);
        }
   }
}

An updated USBPHy_STM32.cpp with test traces can be found in this branch:
https://github.com/JojoS62/mbed-os/tree/test-USB-H743

ciarmcom · 2020-09-20T17:29:39Z

@JojoS62 thank you for raising this issue.Please take a look at the following comments:

We cannot automatically identify a release based on the version of Mbed OS that you have provided.
Please provide either a single valid sha of the form #abcde12 or #3b8265d70af32261311a06e423ca33434d8d80de
or a single valid release tag of the form mbed-os-x.y.z .
E.g. 'mbed-os-99.99.99' signifies master branch and is not a unique single snapshot.
NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered.
Please update the issue header with the missing information, the issue will not be mirroredto our internal defect tracking system or investigated until this has been fully resolved.

JojoS62 · 2020-09-21T08:15:52Z

I'm a step further, Debugging and tracing failed because PA9/PA10 was used for serial output and interferred with VBus/ID detection. These functions are not enabled in USBPhy init, but the AF functions in the PinMap_USB_FS are set.
But USB is still not working after this fix. Did the NUCLEO_H743ZI2 pass the USB tests?
The log looks now like:

hello world
[INFO][main]: main starting
[INFO][usb-stm32]: USBPhyHw::connect()
[INFO][usb-stm32]: USBPhyHw::process()
[INFO][usb-stm32]: HAL_PCD_SuspendCallback()
[INFO][usb-stm32]: USBPhyHw::process()
[INFO][usb-stm32]: HAL_PCD_ResumeCallback()
[INFO][main]: main looping
[INFO][main]: main looping
[INFO][usb-stm32]: USBPhyHw::process()
[INFO][usb-stm32]: HAL_PCD_SuspendCallback()
[INFO][main]: main looping
[INFO][main]: main looping
[INFO][main]: main looping
[INFO][main]: main looping

Excluding PA9/PA10 from PinMap_USB_FS makes no difference.

I tried again to use HSI48 as clock source, but in this case USB_CoreReset() runs into timeout when waiting for reset done. Increasing the timeout up to 10 s did not help. It looks also that CRS must be enabled for HSI48 USB clock, but still timeout in USB_CoreReset().
With PLL3Q as USB clock the USB is starting, but is going into PCD_Suspend state.

JojoS62 · 2020-09-22T15:54:26Z

After lots of testing, I found a sensible line in the HAL code in

mbed-os/targets/TARGET_STM/TARGET_STM32H7/STM32Cube_FW/STM32H7xx_HAL_Driver/stm32h7xx_ll_usb.c

Lines 1078 to 1086 in 6642394

    
           HAL_StatusTypeDef  USB_DevConnect(USB_OTG_GlobalTypeDef *USBx) 
        
           { 
        
             uint32_t USBx_BASE = (uint32_t)USBx; 
        
             USBx_DEVICE->DCTL &= ~USB_OTG_DCTL_SDIS; 
        
             HAL_Delay(3U); 
        
             return HAL_OK; 
        
           }

When stepped through this code, I got more communication. I increased the HAL_Delay from 3 to 200ms and now I'm getting the follwing trace:

Test STM32H743VI USB
[INFO][main]: main starting
[INFO][usb-stm32]: USBPhyHw::init() done.
[INFO][usb-stm32]: USBPhyHw::connect()
[INFO][usb-stm32]: HAL_PCD_ResetCallback()
[INFO][usb-stm32]: USBPhyHw::endpoint_add()
[INFO][usb-stm32]: USBPhyHw::endpoint_add()
[INFO][usb-stm32]: HAL_PCD_SOFCallback()
[INFO][usb-stm32]: HAL_PCD_SetupStageCallback()
[INFO][usb-stm32]: USBPhyHw::ep0_setup_read_result()
dataTransferDirection: 1
Type: 0
Recipient: 0
bRequest: 6
wValue: 256
wIndex: 0
wLength: 64
[INFO][usb-stm32]: HAL_PCD_SOFCallback()
get descr: type: 1
device descr
[INFO][usb-stm32]: USBPhyHw::ep0_write()
[INFO][usb-stm32]: USBPhyHw::endpoint_write()
[INFO][usb-stm32]: USBPhyHw::ep0_read()
[INFO][usb-stm32]: HAL_PCD_SOFCallback()
[INFO][usb-stm32]: HAL_PCD_DataInStageCallback()
ep0_in
[INFO][usb-stm32]: HAL_PCD_DataOutStageCallback()
[INFO][usb-stm32]: HAL_PCD_ResetCallback()
[INFO][usb-stm32]: USBPhyHw::endpoint_add()
[INFO][usb-stm32]: USBPhyHw::endpoint_add()
[INFO][usb-stm32]: HAL_PCD_SuspendCallback()

The delay after clearing the SDIS bit must be >=180 ms, strange long.

But the device is still not recognized correctly.

My MCU is a H743VI with Revision "V". I 've got same results on a NUCLEO_H743ZI with an older Rev "Y" MCU. A difference is, that on Rev "Y" I can use HSI48 as clock source for USB. On Rev V, HSI48 and PLL1Q do not work, USB is hanging in USB_CoreReset on wait for while((USBx->GRSTCTL & USB_OTG_GRSTCTL_CSRST) == USB_OTG_GRSTCTL_CSRST).

ciarmcom · 2020-10-02T15:59:13Z

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2305

JojoS62 · 2020-10-12T18:30:40Z

I've generated a simple USB program in STM32CubeIDE and it works fine. Initialisation is almost the same, but I couldn't find the difference that makes it working.

JojoS62 · 2020-10-14T19:11:18Z

Its driving me nuts, it seems to be related to the Mbed ticks.
With MCU_STM32, lse_enable=1 and LP_TICKER is used. Now USB enumeration works, but only for a short time, until a sleep is called. This sleep is running forever, the lp ticker is fired about 3 times and then no more.
When I remove LP_TICKER, then the USB enumeration fails, the PCD seems to hang and no USB Ints are fired. But the sleep_for() is working.
@jeromecoutant do you have any idea? I tried also the HAL update, there are some differences in SystemInit but it does not help either.

jeromecoutant · 2020-10-15T07:29:59Z

You could try to disable deepsleep to check if issue comes when MCU goes in STOP MODE 2 ?
(use debug profile for ex)

JojoS62 · 2020-10-15T07:55:57Z

thanks, I had added a DeepSleepLock already. But it seems to have no effect, It looks also like the deepsleep (deep power down) is disabled when a debugger is attached.

JojoS62 · 2020-10-15T08:04:15Z

But this seems to be the origin of the problem. Now I have removed "SLEEP" from the target and USB and timer is running.

JojoS62 · 2020-10-15T19:50:36Z

I have checked again lp_ticker. The configuration with LSE seems to be ok, but the wakeup interrupts are fired very slow and randomly, in a range of about 30 ... 150 s. Then I routed LSE to MCO1 and I have seen no clock here, so that was a hardware problem, something wrong with the 32k xtal.

Then I have changed lp_ticker to use LSI and now the MCU wakes up as intended. But with this config, USB does not work, ints are not fired. USB is only working with "target.device_has_remove": ["SLEEP"], what I still don't understand. Shouldn't be a call to sleep_manager_unlock_deep_sleep(); enough?

JojoS62 · 2020-10-16T08:10:37Z

I have checked again lp_ticker. The configuration with LSE seems to be ok, but the wakeup interrupts are fired very slow and randomly, in a range of about 30 ... 150 s. Then I routed LSE to MCO1 and I have seen no clock here, so that was a hardware problem, something wrong with the 32k xtal.

Then I have changed lp_ticker to use LSI and now the MCU wakes up as intended. But with this config, USB does not work, ints are not fired. USB is only working with
"target.device_has_remove": ["SLEEP"]
also
"target.macros_remove": ["MBED_TICKLESS"]
does not help.

Test STM32H743VI USB
[INFO][main]: main starting
LOCK: mbed-os\platform\source\DeepSleepLock.cpp, ln: 29, lock count: 1


Test STM32H743VI USB
[INFO][main]: main starting
LOCK: mbed-os\platform\source\SysTimer.cpp, ln: 112, lock count: 2
Sleep locks held:
[id: mbed-os\platfo, count: 2]
UNLOCK: mbed-os\platform\source\SysTimer.cpp, ln: 151, lock count: 1
LOCK: mbed-os\targets\TARGET_STM\USBPhy_STM32.cpp, ln: 192, lock count: 2
LOCK: mbed-os\platform\source\SysTimer.cpp, ln: 112, lock count: 3
Sleep locks held:
[id: mbed-os\platfo, count: 2]
[id: mbed-os\target, count: 1]
UNLOCK: mbed-os\platform\source\SysTimer.cpp, ln: 151, lock count: 2
LOCK: mbed-os\platform\source\SysTimer.cpp, ln: 112, lock count: 3
Sleep locks held:
[id: mbed-os\platfo, count: 2]
[id: mbed-os\target, count: 1]

jeromecoutant · 2020-10-16T09:42:08Z

Shouldn't be a call to sleep_manager_unlock_deep_sleep(); enough?

Call sleep_manager_lock_deep_sleep(), not unlock ?
But it is already done in USBPhyHw::init

JojoS62 · 2020-10-16T10:05:45Z

I think I've got it, that was really hard.
There I found the clue:
micropython/micropython#3639 (comment)

and adding this to USBPhyHw::init for USE_USB_OTG_FS is working now:

    __HAL_RCC_USB_OTG_FS_CLK_ENABLE();
    __HAL_RCC_USB2_OTG_FS_CLK_SLEEP_ENABLE();
    __HAL_RCC_USB2_OTG_FS_ULPI_CLK_SLEEP_DISABLE();

Its strange that ULPI clock must be disabled, but without it is also not working.

I found a comment above the HAL macros

@note By default, all peripheral clocks are ENABLEd during SLEEP mode.
but this is either not true or the USB clock is disabled somewhere else, haven't found it yet.

JojoS62 · 2020-10-16T10:14:19Z

Call sleep_manager_lock_deep_sleep(), not unlock ?

yes, I have used lock, not unlock. That was a copy error.

jeromecoutant · 2020-10-16T10:39:51Z

Made some grep...
Found __HAL_RCC_USB2_OTG_FS_ULPI_CLK_SLEEP_DISABLE() in
https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Projects/STM32H743I-EVAL/Applications/USB_Device/HID_Standalone/Src/usbd_conf.c#L74-L75
....
But not generated by CubeMx...

JojoS62 · 2020-10-16T11:04:22Z

yes, that works also, only disabling ULPI sleep clock. So the comment about default is clock enabled is true.
Maybe this hint about ULPI is somewhere in the reference manual...

I have used a CubeMX project as reference and it worked, but more likely because it does not use WFI for sleeping.

JojoS62 · 2020-10-16T14:23:21Z

I have tested this fix also for the new target H7A3 from your PR. It works also, but some devices have two USB interfaces and it is not clear for me which to use. Now I do

    #ifdef __HAL_RCC_USB1_OTG_FS_ULPI_CLK_SLEEP_DISABLE
        __HAL_RCC_USB1_OTG_FS_ULPI_CLK_SLEEP_DISABLE();
    #endif
    #ifdef __HAL_RCC_USB2_OTG_FS_ULPI_CLK_SLEEP_DISABLE
        __HAL_RCC_USB2_OTG_FS_ULPI_CLK_SLEEP_DISABLE();
    #endif

There are macros without interface number, but they were moved to the legacy hal folder.
I can prepare a PR, but I see there is a chain of PRs dependending on others.

jeromecoutant · 2021-02-23T16:40:40Z

@JojoS62 Could we close this issue now that #13780 is merged ?
Thx

JojoS62 · 2021-02-23T16:45:19Z

yes, fixed.

ciarmcom added type: bug Jira status: OPEN labels Sep 20, 2020

ciarmcom added Jira status: OPEN and removed Jira status: OPEN labels Oct 2, 2020

ciarmcom added the IOTOSM-2305 label Oct 2, 2020

JojoS62 mentioned this issue Oct 5, 2020

STM32H7: add NUCLEO_H7A3ZI_Q new target #13713

Merged

ARMmbed deleted a comment from ciarmcom Oct 6, 2020

JojoS62 mentioned this issue Oct 16, 2020

STM32 H7: fix USB in sleep mode #13780

Merged

0xc0170 added the devices: st label Nov 3, 2020

JojoS62 closed this as completed Feb 23, 2021

ciarmcom added Jira status: DONE and removed Jira status: OPEN labels Feb 23, 2021

ciarmcom removed IOTOSM-2305 labels May 18, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

USBDevice not working on STM32H743, debug and trace problems #13641

USBDevice not working on STM32H743, debug and trace problems #13641

JojoS62 commented Sep 20, 2020 •

edited

Loading

ciarmcom commented Sep 20, 2020

JojoS62 commented Sep 21, 2020 •

edited

Loading

JojoS62 commented Sep 22, 2020 •

edited

Loading

ciarmcom commented Oct 2, 2020

JojoS62 commented Oct 12, 2020

JojoS62 commented Oct 14, 2020 •

edited

Loading

jeromecoutant commented Oct 15, 2020

JojoS62 commented Oct 15, 2020

JojoS62 commented Oct 15, 2020

JojoS62 commented Oct 15, 2020

JojoS62 commented Oct 16, 2020 •

edited

Loading

jeromecoutant commented Oct 16, 2020 •

edited

Loading

JojoS62 commented Oct 16, 2020 •

edited

Loading

JojoS62 commented Oct 16, 2020

jeromecoutant commented Oct 16, 2020

JojoS62 commented Oct 16, 2020

JojoS62 commented Oct 16, 2020

jeromecoutant commented Feb 23, 2021

JojoS62 commented Feb 23, 2021

USBDevice not working on STM32H743, debug and trace problems #13641

USBDevice not working on STM32H743, debug and trace problems #13641

Comments

JojoS62 commented Sep 20, 2020 • edited Loading

Description of defect

Target(s) affected by this defect ?

Toolchain(s) (name and version) displaying this defect ?

What version of Mbed-os are you using (tag or sha) ?

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

How is this defect reproduced ?

ciarmcom commented Sep 20, 2020

JojoS62 commented Sep 21, 2020 • edited Loading

JojoS62 commented Sep 22, 2020 • edited Loading

ciarmcom commented Oct 2, 2020

JojoS62 commented Oct 12, 2020

JojoS62 commented Oct 14, 2020 • edited Loading

jeromecoutant commented Oct 15, 2020

JojoS62 commented Oct 15, 2020

JojoS62 commented Oct 15, 2020

JojoS62 commented Oct 15, 2020

JojoS62 commented Oct 16, 2020 • edited Loading

jeromecoutant commented Oct 16, 2020 • edited Loading

JojoS62 commented Oct 16, 2020 • edited Loading

JojoS62 commented Oct 16, 2020

jeromecoutant commented Oct 16, 2020

JojoS62 commented Oct 16, 2020

JojoS62 commented Oct 16, 2020

jeromecoutant commented Feb 23, 2021

JojoS62 commented Feb 23, 2021

JojoS62 commented Sep 20, 2020 •

edited

Loading

JojoS62 commented Sep 21, 2020 •

edited

Loading

JojoS62 commented Sep 22, 2020 •

edited

Loading

JojoS62 commented Oct 14, 2020 •

edited

Loading

JojoS62 commented Oct 16, 2020 •

edited

Loading

jeromecoutant commented Oct 16, 2020 •

edited

Loading

JojoS62 commented Oct 16, 2020 •

edited

Loading