STM32 app not running sometimes, remains in DFU

问题

Update :

Problem with a STM32L4 board that sometimes won't run after DFU update, jump to Edit 2 for short story & example code.

I'm working on a project using a custom board based on a STM32L4. I've been having issues when formatting strings before sending them over USB.
The issue happens when updating the mcu using DFU over USB, everything works fine in debug mode (using STLink).
When passing more than 3 arguments to sprintf, the mcu leaves DFU mode but the app never starts (no init steps, no run, nothing).

I've tracked down the line that causes the issue:

    sprintf(tx_buffer, "Hello World: %ld/%ld/%ld\r\n", 1,2,3); // OK
    sprintf(tx_buffer, "Hello World: %ld/%ld/%ld, %ld\r\n", 1,2,3, 4); // NOK
    sprintf(tx_buffer, "Hello World: %d/%d/%d\r\n", 1,2,3); // NOK

tx_buffer is a simple char tx_buffer[255].

It seems that adding too many arguments and/or choosing certain types causes problem.

The issue is that for the NOK cases, the app won't even start, no init whatsoever whereas in other cases it works fine.
For any case, in debug mode, everything runs fine.

Is there a limit to the arguments or types that can be used with sprintf for STM32?
Has anyone experienced this issue or has ideas on how to solve this.

Note : There is only a LED that allows me to tell if I'm in init/running or not.
Error handlers or HardFault handlers make the LED blink to a specific pattern that I have never observe when the app does not seem to boot.

Thanks

Edit: After some digging, I tried to get rid of the printf and send a plain buffer.
I still have the same issues when adding one byte to my buffer makes it work, or makes it fail.

I noted that changing compiler optimisation also have effects on the behavior. Everything always works in Og but not always in Os. Also adding -mno-unaligned-access has effects too.
Maybe this is a memory alignment problem, stack size too ?

2nd edit: This seems things are going random, removing some led blink at the end of the main loop breaks the code, makes it work when it is there.

Edit 2: I started all over with a new blank project for this board.
Same things happen even with a minimal code :

#define LED_TOOGGLE() 

(HAL_GPIO_TogglePin(PWR_I2C_GPIO_Port,GPIO_PIN_4))
#define LED_BLINK(ntime) for(int i=0; i<ntime*2; i++) {LED_TOOGGLE(); HAL_Delay(100);}

uint8_t buff4[4] = {0, 1, '\r','\n'};
uint8_t buff5[5] = {0, 1, 2, '\r','\n'};
uint8_t buff6[6] = {0, 1, 2, 3, '\r','\n'};
uint8_t buff7[7] = {0, 1, 2, 3, 4, '\r','\n'};
uint8_t buff8[8] = {0, 1, 2, 3, 4, 5, '\r','\n'};

int main(void)
{
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();
  MX_AES_Init();
  MX_I2C1_Init();
  MX_SPI1_Init();
  MX_I2C3_Init();
  MX_ADC1_Init();
  MX_CRC_Init();
  MX_USB_DEVICE_Init();

  HAL_Delay(100);

  while (1) {

    LED_BLINK(1);
    HAL_Delay(10);
    CDC_Transmit_FS(buff6, 6);
  }
}

When I change buff6 (and size accordingly) for 5, the app won't start and the board go back to DFU mode. This is the same behavior as previously.
If anyone can reproduce and has insights on how to dig into this, that'll be a good start. Thanks

来源：https://stackoverflow.com/questions/55743813/stm32-app-not-running-sometimes-remains-in-dfu

标签

microcontroller

stm32