Skip to main content
Explorer II
January 21, 2022
Question

Powering NUCLEO-L412KB from +5 V

  • January 21, 2022
  • 6 replies
  • 1597 views

STM32L412KBUx on NUCLEO-L412KB, STM32CubeIDE, Version: 1.8.0.

I'm trying to power my NUCLEO-L412KB from an external +5 V power source.

I have removed SB9 (connected NRST signal of ST-LINK to the NRST pin of the

STM32). SB1 (USB power through CN1) is OFF (default).

When I connect my external source to CN4 pin 4, red LED LD2 turns on, but the STM32L412KB doesn't run (as far as I can tell; I put a HAL_GPIO_WritePin in main() after USER CODE BEGIN 2). If I then connect a USB cable, it comes up.

When powered only by the external +5 V, I see:

  • CN4 pin 4 (5V): 4.96v
  • CN4 pin 3 (RST): 3.17v
  • CN4 pin 14 (3V3): 3.29v
  • U2 pin 1 (VDD3): 3.29v

What could be keeping it from running on the external +5 V?

    This topic has been closed for replies.

    6 replies

    Technical Moderator
    January 21, 2022

    What clock is the STM32L412KBT6 being clocked from after doing these modifications?

    Regards

    /Peter

    CKugl.1Author
    Explorer II
    January 21, 2022

    I've got:

    • SB4: OFF
    • SB17: OFF
    • SB6: OFF
    • SB8: OFF
    • SB5: ON
    • SB7: ON

    which should give me an OSC clock configuration of 32K LSE mounted on X1 (default configuration) according to UM1956: User manual; STM32 Nucleo-32 boards (MB1180).

    P.S. I think the chip is actually a STM32L412KBU6U, based on Data brief; STM32 Nucleo-32 boards. It's hard to read the etching on the chip itself, but it looks like the first line is "L412B6U" or "L41286U"

    Technical Moderator
    January 21, 2022
    Ok, but the LSE provides the clock for the RTC, it cannot clock the Cortex-M core.
    The embedded ST-LINK feeds its clock into the STM32L412 target, without powering the ST-LINK and/or by removing this clock connection, the target needs another clock, e.g. the HSI.
    Regards
    /Peter
    CKugl.1Author
    Explorer II
    January 22, 2022

    I don't understand. If I look at Table 6. OSC clock configurations, in UM1956: User manual; STM32 Nucleo-32 boards (MB1180), there is a different solder bridge configuration for MCO from ST-LINK connected to CKIN (PA0). I just got a new (viritual) oscilloscope, and I've started probing around with that. With USB power, I can definitely see the MCO from ST-LINK on one side of SB4, but SB4 is open.

    In STM32CubeIDE Clock Configuration, I've tried all three options for PLL Source Mux. HSE fails at runtime with an ASSERT, probably because I don't have an HSE. With HSI or MSI, it will continue to run after I unplug the USB cable, even though I see nothing but noise on MCO, but if I hit reset, it fails to come up.

    CKugl.1Author
    Explorer II
    January 22, 2022

    More information: I went back to a simple blinky LED project, and that runs OK from the external 5 V supply (no USB connection necessary). So, it seems my application is failing early in startup, but only when on external power, and I have no idea why. I'm going to try hitting the "Reset Clock Configuration" button.

    EDIT: Well, that "Reset Clock Configuration" button didn't seem to do anything useful. So, I manually made the configuration match that of my brand new Blinky project (did my best, anyway; can't find a way to bring up two .ioc files at the same time, side by side):

    • MSI RC 32000
    • PLL Source Mux: MSI
    • System Clock Mux: MSI
    • everything ends up at 32 MHz.

    It still doesn't run from external power unless I start it on USB first.

    CKugl.1Author
    Explorer II
    January 22, 2022

    EDIT: I think I have found it. It seems my USART2_IRQHandler was getting wrapped around the axle when nothing was connected to USART2. I added some error handling:

    /**
     * @brief This function handles USART2 global interrupt.
     */
    void USART2_IRQHandler(void)
    {
     /* USER CODE BEGIN USART2_IRQn 0 */
     
    	bool proceed = true;
    	if (LL_USART_IsActiveFlag_FE(USART2)) {
    //		framing error
    		LL_USART_ClearFlag_FE(USART2);
    		proceed = false;
    	}
    	if (LL_USART_IsActiveFlag_PE(USART2)) {
    		LL_USART_ClearFlag_PE(USART2);
    //		parity error
    		proceed = false;
    	}
    	if (LL_USART_IsActiveFlag_NE(USART2)) {
    //		noise error
    		LL_USART_ClearFlag_NE(USART2);
    		proceed = false;
    	}
    	if (LL_USART_IsActiveFlag_ORE(USART2)) {
    //		overrun error
    		LL_USART_ClearFlag_ORE(USART2);
    	}
     
    	/* Check RXNE flag value in ISR register */
    	if (LL_USART_IsActiveFlag_RXNE(USART2)
    			&& LL_USART_IsEnabledIT_RXNE(USART2)) {
    		if (proceed) {
    			/* RXNE flag will be cleared by reading of RDR register (done in call) */
    			/* Call function in charge of handling Character reception */
    			USART_CharReception_Callback();
    		} else {
    			// Clear RXNE flag:
    			LL_USART_ReceiveData8(USART2);
    		}
    	}
     /* USER CODE END USART2_IRQn 0 */
     /* USER CODE BEGIN USART2_IRQn 1 */
     
     /* USER CODE END USART2_IRQn 1 */
    }

    This seems to work, but I'd be interested in any suggestions for improvement.

    I need to be able to use the USART when a USB cable is connected, but I don't care about it otherwise.

    Explorer
    January 31, 2025

    Waiting 2 seconds before setting the system clock may resolve the issue.

    Example)

    /* Reset of all peripherals, Initializes the Flash interface and the Systick. */

    HAL_Init();

     

    /* USER CODE BEGIN Init */

    HAL_Delay(2000); <- insert

    /* USER CODE END Init */

     

    /* Configure the system clock */

    SystemClock_Config();

     

    /* USER CODE BEGIN SysInit */

     

    /* USER CODE END SysInit */