NUCLEO-L433 problem with USB

[JohnnyK (Jan Kamidra)]

Hello Lucas,
nice to see you here again.
Unfortunately not, for many reasons. I am usually lazy in my free time but currently I have a lot of work on house and I have also new job position + new project around electric vehicle drive.

About baremetal

• You have 256kb of flash but RAM is not so big, just 64kb.
• Mutex is related to RTOS that means full profile of MbedOS, with the bare metal profile there si no RTOS = no mutex.

About USBSerial

• the setting in mbed_app.json around USB looks OK.
• Keep in mind you need PC app what will drive DTR signal for the USBSerial, without this will see nothing in terminal anyway.

When set the first paramater false for non blocking, that mean then constructor will not wait for a connection and also you have to care the conection sequnce by your self.
For example we are using it for debugging like this.

USBSerial serial(false);

template<typename... Args> void debugPrint(const char *msg, Args... args){
    if(!serial.configured()){
        serial.connect();            
    }
    
    if(serial.configured()){
        if(!serial.connected()){
            serial.init();    
        }   
    }
    
    if(serial.connected()){
        serial.printf(msg, args...);
        serial.printf("\r");
    } else printf(msg, args...);
}

About console output
you can retarget the output out of UART, for eaxample to USBSerial like this

Hitchhiker's Guide to Printf in Mbed 6

As explained by @ boraozgen : #include "mbed.h" #include "USBSerial.h" FileHandle* mbed::mbed_override_console(int) { static USBSerial myConsole(false, 0x1f00, 0x2012, 0x0001); return &myConsole; } Edit: To make this work either create the myConsole as myConsole(true, 0x1f00, 0x2012, 0x0001); or call myConsole.connect(); before returning from the function. See below @ boraozgen’s tip.

Or to SWO

Hitchhiker's Guide to Printf in Mbed 6

Actually, no ITM initialization is needed for STM targets. It seems that it’s sufficient to define a dummy ‘itm_init’ function as below and redirect the Mbed CONSOLE to the SWO: #include "mbed.h" #include "SerialWireOutput.h" DigitalOut led1(LED1); extern "C" void itm_init() { } FileHandle* mbed::mbed_override_console(int) { static SerialWireOutput swo; return &swo; } int main() { printf("Hello, SWO!\r\n"); while (true) { led1 = !led1; printf("blink\r\n"); …

(SOLVED)Mbed-os 6 SWO viewer

Hello, Itried that I faced to same state like you wrote. However on line 40 of .cpp //May want to add initialisation stuff here So I found an init code for Nucleo/H743ZI2 from this discussion - Feed Detail (st.com) *(__IO uint32_t*)(0x5C001004) |= 0x00700000; // DBGMCU_CR D3DBGCKEN D1DBGCKEN TRACECLKEN //UNLOCK FUNNEL *(__IO uint32_t*)(0x5C004FB0) = 0xC5ACCE55; // SWTF_LAR *(__IO uint32_t*)(0x5C003FB0) = 0xC5ACCE55; // SWO_LAR //SWO current output …

BR, Jan

[MultipleMonomials (Jamie Smith)]

Hmm, a few other comments:

"platform.stdio-minimal-console-only": true,

"platform.stdio-buffered-serial": 1,

^ IIRC, these two options conflict with each other and will cause the buffered serial to not actually be used.

Regarding the ST-Link serial port, if your board has a 14-pin SWD connector and you connected the VCP pins from the connector to your MCU, then you can certainly redirect Mbed’s serial console to those pins and get debug output over them. If not, getting the debug output from the crash may be trickier. Is it completely out of the question to solder bodge wires to unused pins/traces and connect a USB-serial adapter to them?

Another option, which I have used for crash debugging in the past, is to set a breakpoint on the Fault_Handler symbol (defined in except.S). Then, once this symbol is hit, you can observe the stack trace to see where the fault happened. If the MCU is rebooting because of an assertion failure rather than an actual fault, then you will probably want to break on handle_error() instead.

I hope this is useful and let us know how things go!

[LukasBier]

Thanks all for your response.

@JohnnyK
I understand and congratulations on the new job position and the interesting project!

1. About baremetal
   Thank for the explanation. From this (Mbed OS bare metal profile - Mbed OS bare metal profile | Mbed OS 6 Documentation) I assumed that the core RTOS is also bare-metal and e.g. Mutex are enabled by default.
   I have tried to add it in configuration json: “requires”: [“bare-metal”, “events”, “rtos-api”, “drivers-usb”],
   but without change - the problem is not in mutex…

2. About USBSerial
   I tried to set up the console to my USB port as you recommend:

#include "USBSerial.h"

FileHandle* mbed::mbed_override_console(int)
{
   static USBSerial   USB_port(true, 0x1f00, 0x2012, 0x0001);
  // blocked true 
    return &USB_port;
}

I lost the ability to send myself my messages - I had to disable them.
It doesn’t go together, however the 1 minute from when it crashes I estimated using the signal LEDs on the board.

I guess that worked, right after connecting I got a message on the console “Cannot initialize UART with baud rate 9600”. (I honestly have no idea what this refers to.)

I was expecting to get some sort of crash report after that minute when I trigger a crash with an incoming UART message, but I received nothing

I tried to add to the mbed_app.json configuration

"platform.crash-capture-enabled": true,

but it is not possible:
Error: L6218E: Undefined symbol Image$$RW_m_crash_data$$ZI$$Base (referred from BUILD/NUCLEO_L433RC_P/ARMC6/mbed-os/platform/source/TARGET_CORTEX_M/TOOLCHAIN_ARM/except.o).

@MultipleMonomials

1. I changed the stdio setting to:

"platform.stdio-minimal-console-only": false,
"platform.stdio-buffered-serial": 1,

I hope that it is OK now.

2. Unfortunately I don’t have a full connector on the board for ST-Link connection. There is only SWDIO and SWCLK. However, it looks like as I write above I managed to redirect console to my USB, although I didn’t get the information I would have expected
   In a pinch of the highest I can unplug the chip on UART2 and use it for the console or from try just connecting to the UART2 testpads and hope that the chip doesn’t affect communication…

3. I managed (and I really have no idea what change in mbed_app.json led to this, because it didn’t work before) to make the ST-Link connection to MBED and set it as Target. And compile it without error - before that I always got a message that the target is not supported.
   
   This allowed me to run a debug and see what happens when an error occurs.
   The crash occurs at the end of the sequence when I return the value (in debug mode I even get it on the USB, in real mode I don’t).

                    }
                }
                USB_port.write(&TXbufferUSB, USB_buffer_TX_length);   
// HERE IT CRASH
                sprintf(systemUSBmessage, " \n");  USB_SendSystemMessage();
            }

But always only after a part of the

 if(flag_every_60s)    // every 60s
 {
// here I have the code as seen in the source above, 
// but I have tried to delete everything and leave only the empty part {}.
// The effect is the same - even passing the empty part leads to a subsequent crash.
}

Before that, it works 60 seconds without problem.

The Debug Console returns the information to me:

Program
received signal SIGSEGV, Segmentation fault.
0x080001a8 in HardFault_Handler ()

It’s better than nothing, but it didn’t help me much…

It may be some mismatch between RC and RC-P and the compiler after all? Respectively, how is it that with ST Link connected I can have Target STM32L433, when in the directories I only see the folder TARGET_STM32L433xC and the only subfolder TARGET_NUCLEO_L433RC_P.

BR Lukáš

[MultipleMonomials (Jamie Smith)]

I can be reasonably sure that using a -P variant of the chip will not cause anything like this, as it only affects the pinout of the chip, not the software interface. I’ve personally used the NUCLEO_L452RE_P target to build for the non-P variant of the chip and had 0 issues.

Are you able to get a call stack if you set a breakpoint inside HardFauld_Handler?

[LukasBier]

I’m not sure if I understand the message. Do you mean put the breakpoint exactly where it crashes in my main.c ?

[LukasBier]

Velmi děkuji za doporučení. Výsledky jsou v příspěvku níže.

[MultipleMonomials (Jamie Smith)]

I mean like, drop a breakpoint here, on the hardfault handler itself.