Приложение STM32 иногда не запускается, остается в DFU - PullRequest
Новая
       52

Приложение STM32 иногда не запускается, остается в DFU

0 голосов
/ 18 апреля 2019

Обновление:

Проблема с платой STM32L4, которая иногда не запускается после обновления DFU, перейдите к Edit 2 для краткого рассказа и примера кода.

Я работаю над проектомиспользуя пользовательскую плату на основе STM32L4.У меня были проблемы при форматировании строк перед отправкой их через USB.
Проблема возникает при обновлении mcu с использованием DFU через USB, все отлично работает в режиме отладки (с использованием STLink).
При передаче более 3 аргументовдо sprintf, mcu выходит из режима DFU, но приложение никогда не запускается (без шагов инициализации, без запуска, ничего).

Я отследил строку, которая вызывает проблему: 

    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 - это просто char tx_buffer[255].

Кажется, что добавление слишком большого количества аргументови / или выбор определенных типов вызывает проблемы.

Проблема в том, что для случаев NOK приложение даже не запустится, без инициализации, тогда как в других случаях оно работает нормально.
В любом случае, в режиме отладки все работает нормально.

Существует ли ограничение для аргументов или типов, которые можно использовать с sprintf для STM32?
Кто-нибудь сталкивался с этой проблемой или есть идеи по ее решению.

Примечание: Есть только светодиод, который позволяет мне определить, в данный момент я нахожусь в запущенном / запущенном состоянии.
Обработчики ошибок или обработчики HardFault заставляют светодиод мигать по определенному шаблону, который я никогда не наблюдал, когда приложение, похоже, не работает.boot.

Спасибо

Редактировать: После некоторых копаний я попытался избавиться от printf и отправить простой буфер.
У меня все еще остаются те же проблемы, когдадобавление одного байта в мой буфер приводит к тому, что он работает или дает сбой.

Я заметил, что изменение оптимизации компилятора также влияет на поведение.Все всегда работает в Og, но не всегда в Os.Кроме того, добавление -mno-unaligned-access также имеет эффекты.
Может быть, это проблема выравнивания памяти, размер стека тоже?

2-е редактирование: Кажется, что все идет случайным образом, убирая некоторые светодиодные блики в конце основногоцикл прерывает код, заставляет его работать, когда он там есть.

Редактировать 2: Я начал все с нового пустого проекта для этой доски.
То же самое происходит даже с минимальным кодом: 

#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);
  }
}

Когда я изменяю buff6 (и размер соответственно) для 5, приложение не запустится, и плата вернется в режим DFU.Это то же самое поведение, что и раньше.
Если кто-то может воспроизвести и понять, как в этом разобраться, это будет хорошим началом.Спасибо

...