STM32L412 hardfault while using minimal CubeIDE example.

[RKnoe]

I try to set up an USB CDC project for a STM32L412KB Nucleo32 board using CubeIDE.

I activated the USB connection and the USB middleware with the default USB CDC setup.

If I run this code, it ends in the hardfault handler with INVSTATE raised during the USB_EnableGlobalInt(hpcd) call (HAL_PCD_Start() at stm32l4xx_hal_pcd.c:1,014 0x8000d26).

The next items on the call stacks are: <signal handler called>() at 0xfffffff9, 0x0, <signal handler called>() at 0xfffffff1   and finally HardFault_Handler() at stm32l4xx_it.c:88 0x800432a.

Currently I ran out of ideas on what to do. USB CDC worked in projects set up for the STM32F072 and F103 - should we change from the L4 to another MCU?

[bitlischieber]

I had recently a similar issue. In my case the debug messages where activated and tried to printf() the messages in to the void.

Have you tried to deactivate the debug messages or redirect printf() to a serial port?

    #ifdef __GNUC__
      /* With GCC, small printf (option LD Linker->Libraries->Small printf
         set to 'Yes') calls __io_putchar() */
      #define PUTCHAR_PROTOTYPE int __io_putchar(int ch)
    #else
      #define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f)
    #endif /* __GNUC__ */
     
    /**
      * @brief  Retargets the C library printf function to the USART.
      * @param  None
      * @retval None
      */
    PUTCHAR_PROTOTYPE
    {
      /* Place your implementation of fputc here */
      /* e.g. write a character to the EVAL_COM1 and Loop until the end of transmission */
      HAL_UART_Transmit(&huart6, (uint8_t *)&ch, 1, 0xFFFF);
     
      return ch;
    }

[RKnoe]

Thank you very much for your answer! I would never expected something like this - but unfortunately, this doesn't seems to be the answer.

I set up __io_putchar and verified that it is usable by printing in the main loop (and disabling MX_USB_DEVICE_Init()), but if I enable this function the program still ends in the hardfault handler :(

[bitlischieber]

Have you tried to set the linkers min. heap size to at least 0x1000?

According to ST support "the default heap size is usually not big enough".

[RKnoe]

I tried it with even 0x2000 for stack and heap (which would have be a tremendous waste of RAM) - and it didn't work.

But this time I noticed the solution when single-stepping through the USB initialization:

USB_EnableGlobalInt() has been called by HAL_PCD_Init() and it results in the hardfault handler if it is called again in HAL_PCD_Start. If I comment out the second call, the initialization runs through and at least I get reenumeration attempts. Is there a way to notice ST of this problem and possible fix?

[lizerd]

Hi.

Did you ever find the solution to this problem ?

I have the exact same problem on the STM32L412CB (Rev A) chip.

Your error explanation is spot on the same problem that I have.

I have tested 10 diffrent setups, and all have the same problem.

When I do the same setup on a STM32L452RE there is no problem what so ever.

Hope you have any new info

The Cube FW is STM32Cube FW_L4 V1.14.0

Best // Mike

[Tesla DeLorean]

Some output from a Hard Fault Handler would be helpful.

For GNU/GCC based tools make sure the initial stack pointer is even, ie 0x20020000 and not 0x2001FFFF

For Keil make sure stack allocation is bigger in startup.s at least 0x1000

Make sure the RAM regions are correctly placed/sized, especially when moving between parts.

HardFault_Handler\
                PROC
                EXPORT  HardFault_Handler          [WEAK]
 
                TST     lr, #4          ; Determine correct stack
                ITE     EQ
                MRSEQ   R0, MSP         ; Read MSP (Main)
                MRSNE   R0, PSP         ; Read PSP (Process)
 
                MOV     R1, R4          ; Registers R4-R6
                MOV     R2, R5
                MOV     R3, R6          ; sourcer32@gmail.com
 
                EXTERN  hard_fault_handler_c
                B       hard_fault_handler_c
                ENDP

void hard_fault_handler_c(unsigned int * hardfault_args, unsigned int r4, unsigned int r5, unsigned int r6)
{
  printf ("\n[Hard Fault]\n"); // After Joseph Yiu
 
  printf ("r0 = %08X, r1 = %08X, r2 = %08X, r3 = %08X\n",
    hardfault_args[0], hardfault_args[1], hardfault_args[2], hardfault_args[3]);
  printf ("r4 = %08X, r5 = %08X, r6 = %08X, sp = %08X\n",
    r4, r5, r6, (unsigned int)&hardfault_args[8]);
  printf ("r12= %08X, lr = %08X, pc = %08X, psr= %08X\n",
    hardfault_args[4], hardfault_args[5], hardfault_args[6], hardfault_args[7]);
 
  if (__CORTEX_M >= 3)
		printf ("bfar=%08X, cfsr=%08X, hfsr=%08X, dfsr=%08X, afsr=%08X\n",
			*((volatile unsigned int *)(0xE000ED38)),
			*((volatile unsigned int *)(0xE000ED28)),
			*((volatile unsigned int *)(0xE000ED2C)),
			*((volatile unsigned int *)(0xE000ED30)),
			*((volatile unsigned int *)(0xE000ED3C)) );
 
  while(1);
}

[lizerd]

Hi.

I do not have any way to print the printf output right now.

So I checked with TrueStudio (Stm32CubeIDE)

I have tested this with both Truestudio 9.3 and Stm32CubeIDE with the same result.

I set the breakpoint at the position before the error accrue, and each picture is an step in assembly.

next

next

next

next

Hard fault

and assembly code at the error

I do not know ow to follow this, becuas from my perspective it looks well and fine before the error hits.

Hope there is a way to solve this.

btw, Thanks Clive for all your help, indirect (others post) and direct :)

[waclawek.jan]

> each picture is an step in assembly.

I'd say, you used "step over" rather than "step into" (I don't use eclipsoids so I don't know exactly which key does what). In other words, IMO you run the USB_DevConnect routine, and failed somewhere there.

Learn how to "step into" and step until the fault occurs.

JW

[lizerd]

Hi JW.

I am not a eclips guy my self, so I am no expert.

But I used "run to line" for each "step"

I culd not find another way to do it (Assembly step).