NUCLEO-L433 problem with USB

I can’t get USB communication to work.

I am testing on NUCLEO-L433RC-P

In Embed studio I have a target NUCLEO-L433RC-P and I use the library mbed-os mbed-os-5.15 (I have the older version because of the MQTT communication libraries that work with this OS version)

I have the USB connected to the pins
D+ to pin PA12
D- to pin PA11
and of course the GND ground connected

I have tested all 3 versions of the sample programs from the link:

but in none of them did I get the computer to find the connected device.

Since the STM32L433 has an internal pull-up on the USB peripheral, I expect, that after connecting the USB cable to the PC, the device manager should at least find the unknown device…
It looks like the whole USB peripheral is not active for some reason.
I’ve checked the VDD_USB power pin, but it’s fine:
SWITCH SB25 VDDUSB power supply MCU pin48 = VDDUSB pin 48 powered by VDD_MCU

I also tried adding mbed_app.json and inserting the USB device into it

“target_overrides”: {
“*”: {
“target.device_has_add”: [ “USBDEVICE” ]

but then I got errors while compiling:
Compilation [ 97.9%]: USBPhy_STM32.cpp
[Error] USBPhy_STM32.cpp@46,31: no member named ‘DIEPTXF0_HNPTXFSIZ’ in ‘USB_TypeDef’
[Error] USBPhy_STM32.cpp@48,32: there is no member named ‘DIEPTXF’ in ‘USB_TypeDef’.
[Error] USBPhy_STM32.cpp@56,5: unknown type name ‘USB_OTG_GlobalTypeDef’
[Error] USBPhy_STM32.cpp@59,28: use of undeclared identifier ‘USBx_DEVICE’
[Error] USBPhy_STM32.cpp@59,48: use of undeclared identifier ‘USB_OTG_DSTS_FNSOF’
[Error] USBPhy_STM32.cpp@257,5: use of undeclared identifier ‘HAL_PCDEx_SetRxFiFo’; did you mean ‘HAL_PCDEx_GetTxFiFo’?
[Error] USBPhy_STM32.cpp@263,9: use of undeclared identifier ‘HAL_PCDEx_SetTxFiFo’
[ERROR] .\mbed-os\targets\TARGET_STM\USBPhy_STM32.cpp:46:31: error: no member named ‘DIEPTXF0_HNPTXFSIZ’ in ‘USB_TypeDef’

Do you have any idea how to do this correctly?
Thank you for your help.


yeah, it seems like the USB was not supported for STM32L4 family in MbedOS 5
What old library? Maybe some can help.

BR, Jan

Dear Jan,
I have tried it with latest OS 6.17.0

Without mbed_app.json I have got answer in debuger:
– MbedOS Error Info –
This board does not have a hardware USB driver

With mbed_app.json where I added the USB device it works fine. PC found the CDC device and after some work with INF file I have got the result what i want.

The reason I wanted to use OS5.15 was that I have a previous project under this version where I use the libraries for Wiznet W5500 and MQTT. Under the new OS version these libraries are already reporting bugs, so I will either have to go through the whole thing and fix them or find others that will work with OS6.17.0. I wanted to save myself some of this time… :slight_smile:

Yeah, it have to be in mbed_app.json because usually all STM32 targets what do not have onboard USB port have this feature disabled.

I understand but this is a magic circle what killing this eco system. People usually want to be consumers instead of contributors.

Please share links to exact libraries that you use and we can look together how complicated would be to modified them to Mbed OS6.

BR, Jan

Thank you for your offer.
I usually turn to the forum only when I have exhausted all ideas on how to solve the problem. So I don’t want to take up your time. I’ll spend some time getting the existing libraries up and running and see: if I’m successful then I’ll share the libraries - I’m sure they’ll help others and if not I’ll contact you…
PS I’m guessing that most of the problem in these libraries will be mainly in time loops, where features that OS6 no longer supports will be used. This should be solvable fairly easily.
Thanks again.

1 Like

I’m here again. I didn’t get to MQTT because I’ve been struggling with USB for a few nights now.
I have moved from Nucleo to my board equipped with STM32L433RCT6.
In the MBED_APP.JSON configuration I only added a clock source (which shouldn’t be related to USB - the USB peripheral has its own)

"target_overrides": {
    "*": {
        "target.clock_source": "USE_PLL_HSI",
        "target.lse_available": 0,
        "target.device_has_add": ["USBDEVICE"]

I created a simple test program:

#include "mbed.h"
#include "USBSerial.h"

// MBED OS 6.17.0
// clock source: HSI 16MHz

USBSerial USB_port(false, 0x1f00, 0x2012, 0x0001);          // USB port automaticky

bool USB_connected_flag = 0;

Ticker tick_1sec;                                           // casové priznaky
Ticker tick_60sec;

// vstupy a vystupy                                        
DigitalOut MCU_LEDG(PB_13);                                 // OK zelena LED
DigitalOut MCU_LEDR(PB_12);                                 // OK cervena LED
DigitalOut Rele(PB_5);                                      // OK rele (posun oproti MCU-P)
DigitalOut Beep(PA_15);                                     // OK pipak
DigitalOut RGB_Red(PC_2);                                   // RGB ledky
DigitalOut RGB_Green(PC_3);
DigitalOut RGB_Blue(PA_8);
DigitalIn Button(PB_14);                                    // OK tlacitko
DigitalIn USB_VCC(PA_0);                                    // detekce USB
DigitalOut MODBUS_EN(PC_12);                                // MODBUS prijem

DigitalOut W_RST(PA_1);
DigitalOut W_CLK(PA_5);
DigitalIn W_MISO(PA_6);
DigitalOut W_MOSI(PA_7);
DigitalIn W_INT(PB_0);

// Procedury a funkce
void every_second();
void every_60sec();
void MCU_LEDR_Blink();

int main(void)
    Watchdog &watchdog = Watchdog::get_instance();
    W_RST = 0;                                              // drzim wiznet v resetu
    MCU_LEDR = 0;
    MCU_LEDG = 0;
    RGB_Red = 0;
    RGB_Green = 0;
    RGB_Blue = 0;
    Rele = 0;
    Beep = 0;
    W_RST = 1;                                              // poustim reset wiznetu

    tick_1sec.attach(&every_second, 1000ms);
    tick_60sec.attach(&every_60sec, 60000ms);
    while (1) 

        if ((USB_VCC)&&(!USB_connected_flag))                   // detekuji USB_VCC a není jeste pripojeno
            USB_port.connect();                                 // pokusim se pripojit USB
            //USB_port.wait_ready();                              // Block until ready
        if ((!USB_VCC)&&(USB_connected_flag))                   // neni USB_VCC a bylo pripojene
            USB_port.disconnect();                              // odpojuji USB

void every_second() 
   if (USB_connected_flag)                                      // pripojeno USB
        MCU_LEDG = 1;                                           // svitim LEDG
        MCU_LEDG = !MCU_LEDG;                                   // neni pripojen - blikam

void every_60sec()                                              // preruseni kazdou minutu
   USB_port.printf("ABC");                                      // test 

void MCU_LEDR_Blink()
    MCU_LEDR = 1;
    MCU_LEDR = 0;

If I connect the board to the PC, the Device Manager finds my device correctly
and the green LED stops flashing - the “connection” flag
I open the corresponding virtual COM port in the terminal and wait for the test message “ABC”
So far everything is fine.

However, when the message arrives, the terminal only picks up the first character “A” and then the connection drops.
The board gets stuck and is only reset by the watchdog. Then it reconnects, but the terminal reports that the COM port does not exist.
(although the device is visible in the device report)

If I enable USB_port.wait_ready(); the board freezes and the watchdog resets it again.

I don’t foresee a hardware problem, given that

  • MCU USB peripheral is correctly powered with 3.3V
  • the computer is able to get data about the type of device
  • I am able to catch the first character of the test message
  • the same problem is on 2pcs of boards that I test and with different USB cables

Basically, I can’t think of much else…

The last attempt was to abandon USBserial and try USBCDC. It’s strange, but in this case I’m able to again catch the whole message and the connection is stable… One time!
After a while I went back and unplugged and reconnected the device I have the same problem as with the USBserial and I am no longer able to get the test message and stable connection. It seems to only work when first connection to the computer - once it recognizes the device, it doesn’t work.

I’m beginning to suspect that the problem is neither on my board nor in MBED, but in the Windows driver…

Last test: it really is in the windows or driver. If I uninstall driver and add it again, it works the first time I start it. Any further connection is not working…
(tried several drivers for VCP and all the same behavior)

Hello Lukas,

I see you are from same country :slight_smile:
USBSerial (not sure about CDC) you need manage DTR signal so it depends on your host APP if correctly manage it.

BR, Jan

Hello JohnnyK,

so I have successfully solved the USB. One problem was in the driver itself on the pC, the other in the call to the connect function, which is not needed at all, although it tempts you to use it.

Otherwise, exactly what I feared happened. By switching to OS6, I was unable to get the W5500 to work. There are a number of libraries designed for OS5 that, after modification (mainly waiting with the “wait” command), do not run under OS6, and after many tests I have to conclude that they actually do not run under OS5 combined with Nucleo L433 either.

Probably the furthest I got was with the WIZnetInterface-OS5 - For mbed OS-5 version for WIZnet Ethernet Interfa… | Mbed library, which was at least willing to share the PHY Link status with me after initialization, but I can only dream about connecting and getting an IP address. In addition, the connect function causes freezes despite the timeout parameter :slight_smile: And that’s another problem. Again, just to be safe, I switched from my board to Nucleo and a complete module with W5500 to rule out a possible HW bug.

My personal guess is that this is again somehow related to the TARGET configuration and environment, which is extremely opaque from my point of view with MBED. I am not sure what name (in mbed_app.json) of network interface is correct for my lbr… I have tested different names but without without visible change…

"config": {
        "help": "options are ETHERNET, ETHERNET_WIZNET",
        "value": "WIZNETINTERFACE"
"target_overrides": {
    "*": {
        "target.clock_source": "USE_PLL_HSI",
        "target.lse_available": 0,
        "target.device_has_add": ["USBDEVICE"]

Anyway, the rapid prototyping tool is becoming a time eating black hole for us. P.S. We are looking for a MBED programmer for occasional (paid) collaboration, do you know anyone? :slight_smile:

BR Lukas

Hello Lucas,

this is strange because how I see to the library uses just 4 things from Mbed

  • Timer
  • DigitalOut
  • SPI
  • wait functions

the rest seems to be Wiznet own implementation and I do not think these 4 APIs cause the problem.
But you are not alone - W5500 ethernet driver - #6 by xeenych

I do no know about any Mbed programmer and I can not call myself a professional programmer. But I can try help, then who know…

When we talk about W5500 module. What this mean? Original W5500 chip what you have on your PCB or about an Aliexpress clone? Can you share a link to exact product?

BR, Jan

Hello JohnnyK,
once again I spent a few late hours at the computer and did some tests to try to find a working library and verify my WIZ850io module…

1. Test
Test of the WIZ850io Ethernet module with the Bluepill board and source code from the Internet (GitHub - geekshow/mbed-os6-stm32-w5500-mqtt: Home MQTT ethernet controller using mbed os). For the source code I left the Wiznet and MQTT libraries and removed things related to sensors and display

- profile in mbed_app.json I left the original "requires": ["bare-metal"],
- I set the target as NUCLEO-F103RB (I know it's Bluepill compatible)
- the compilation went fine, only for
I got several [Warning]: 'read_ms' is deprecated......
- I threw a USB converter on the debug UART pins


The result is that the WIZ850io module with the bluepilll works just fine and gets the IP address without any problems. (and after I set up the broker it also connected to the broker)

2. Test
I connected the same LAN module to Nucleo-L433 and moved the same program I tested on Bluepill to Nucleo-L433:

- I left the original "requires": ["bare-metal"] profile in mbed_app.json,
- I set the target as NUCLEO-L433RC-P 
- I modified the pins where I have the LAN module connected to
	EthernetInterface wiz(PA_7, PA_6, PA_5, PA_4, PA_1);
- the compilation went fine, only at
I got several [Warning] as before: 'read_ms' is deprecated......

During the test, the board attempts to initialize the LAN module


But then it freezes and the watchdog resets board. The debug returns the following:


Error decoder says:
HardFault exception
Cortex-M HardFault exception has occurred.

This suggests that the problem is definitely not in the HW and not necessarily in the Wiznet library, but rather in the combination of the Target with this library. In this combination, MBED OS simply approaches either SPI or some timing in loops differently…

As you wrote: library uses just 4 things from Mbed
- Timer
- DigitalOut
- wait functions
but from my point of view it looks like the problem is somewhere in these 4 things and because the board freezes I would guess Wait functions or Timers.

Do you have any ideas on how to spot the problem better?

P.S. I am using original WIZ850io module with W5500 IC from Wiznet.

Best regards Lukas

Did you try to debug? For exact line where the code stops.

BR, Jan

Hello JohnnyK,
another tests with debug.
It frozen because the SPI communication is not working correctly- no valid answer from LAN module.
(and the connect function don’t have timeout in this case)

When I am using on Nucleo-L433 SPI1 on these pins - it is not working!

EthernetInterface wiz(PA_7, PA_6, PA_5, PA_4, PA_1);

But I have tried to reconnect the LAN module to another pins with SPI1 (below) and it is working without problem !!

EthernetInterface wiz(PB_5, PA_11, PB_3, PA_15, PA_1);

Now I know, it is the SPI problem .

I have also checked the mbed-os/targets/TARGET_STM/TARGET_STM32L4/TARGET_STM32L433xC/TARGET_NUCLEO_L433RC_P/PeripheralPins.c
and problematic pins are with note about SMPS:

MBED_WEAK const PinMap PinMap_SPI_MOSI[] = {
    {PA_7,       SPI_1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_NOPULL, GPIO_AF5_SPI1)}, // Connected to SMPS_SW [TS3A44159PWR_IN1_2]

a collision with SMPS may be the reason on Nucleo L433.

My PCB is designed to use SPI1 on pins PA_7, PA_6, PA_5, PA_4, PA_1, but not using external SMPS. So it might work - I will test it after weekend…

Best regards Lukas


Good to know my guess was close and Wiznet lib is working.

The external Smps is equipped on the Nucleo boards with -p suffix like on Nucleo-L433RC-P. According to user manual UM2206 there is a onboard jumper which will deactivate the Smps. So you can try to do it and test if the SPI_1 will work after that.

Back to your MCU. Do you have TM32L433RCT6 or TM32L433RCT6P? Because same like above, just MCU with suffix P has modified pinout for external SMPS.

BR, Jan