Skip to main content
hmc
hmc
Associate III
February 25, 2018
Question

CubeMX HID on Nucleo F042K6

  • February 25, 2018
  • 1 reply
  • 693 views
Posted on February 26, 2018 at 00:40

About 2 years ago, I played around briefly with CubeMX generated custom HID code on STM32F042K6.  D+/D- signals seemed to work fine, but my ''custom'' HID FW did not enumerate against Windows.  I got too busy with a new job, and did not pursue the problem.  This weekend, I picked up where I left off.  This time, I am trying to understand the USB HID better, so I just tried the CubeMX generated HID example.  Except for emitting a debug byte here and there, I ran the auto-generated code verbatim.  The voltage on DP/DM (PA12/PA11 pins connected to the header D2/D10 on the Nucleo F042K6) seems to show a setup problem: the DP doesn't seem to rise to 3.3 V!

0690X00000608VgQAI.png

Another thing I changed is the bmAttribute to bus powered (default is 0xE0, which is bus + self powered + remote wakeup) and increasing the max power to 250 (which means 500 mA).  I increased the current when I noticed the host complaining about over-current.  Strangely,  The only load I put on the USB VBus is an LED in series with a 220 Ohm; and I only measured 2 V drop across 220 Ohm, so I should only be pulling 10 mA.  Anyway, I shouldn't think that the current load on VBus shouldn't affect the DP/DM voltages, so the above waveform looks strange to me.

2 years ago, I never understood the ST's USB stack.  I just downloaded AN4711 and UM1717, to better understand.  Right away, it seems strange that CubeMX did NOT generate the DCD_xxx files being discussed in UM1717, but I'll keep reading.  If anybody knows right away anything I am doing wrong, I'd really appreciate a tip.

Thanks for reading!

    This topic has been closed for replies.

    1 reply

    hmc
    hmcAuthor
    Associate III
    February 27, 2018
    Posted on February 27, 2018 at 05:44

    I debugged the beginning of craziness to this CubeMX generated function

    HAL_StatusTypeDef

    HAL_PCD_Start(

    PCD_HandleTypeDef

    *hpcd)

    { 

     

    /* Enabling DP Pull-Down bit to Connect internal pull-up on USB DP line */

      hpcd->

    Instance

    ->

    BCDR

    |= USB_BCDR_DPPU;

      

     

    return

    HAL_OK

    ;

    }

    According to the ref manual, this is the DP pull-up enable, which is necessary to connect to the host (inferring here, because the documentation says to clear to 0 to disconnect from the host).  So why does this pull up not actually pull up to 3.3 V (which the DM is clearly at)?  It seems to me that unless this is pulled up to 3.3V, the host cannot talk to the host.  Maybe I need to get another copy of USB Complete to understand what's going on electrically.  I deliberately did not pull up DP to 3.3V, figuring the internal pull-up will take care of this.

    Does anyone know what's supposed to happen here please?

    Terms & ConditionsAccessibility statement