[Turgenev 1]

Есть девайс на STM32H7. Связаться с этим контроллером через программатор ST-LINK V2 стало невозможно после того, как прошил его прошивкой, где по ошибке выставил не правильный делитель синтезатора:

Рабочие настройки:

Спойлер

void SystemClock_Config(void)
{
  RCC_OscInitTypeDef RCC_OscInitStruct = {0};
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

  /** Supply configuration update enable
  */
  HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);
  /** Configure the main internal regulator output voltage
  */
  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

  while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}
  /** Macro to configure the PLL clock source
  */
  __HAL_RCC_PLL_PLLSOURCE_CONFIG(RCC_PLLSOURCE_HSE);
  /** Initializes the RCC Oscillators according to the specified parameters
  * in the RCC_OscInitTypeDef structure.
  */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = 4;
  RCC_OscInitStruct.PLL.PLLN = 80;
  RCC_OscInitStruct.PLL.PLLP = 2;
  RCC_OscInitStruct.PLL.PLLQ = 2;
  RCC_OscInitStruct.PLL.PLLR = 2;
  RCC_OscInitStruct.PLL.PLLRGE = RCC_PLL1VCIRANGE_3;
  RCC_OscInitStruct.PLL.PLLVCOSEL = RCC_PLL1VCOWIDE;
  RCC_OscInitStruct.PLL.PLLFRACN = 0;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }
  /** Initializes the CPU, AHB and APB buses clocks
  */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2
                              |RCC_CLOCKTYPE_D3PCLK1|RCC_CLOCKTYPE_D1PCLK1;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.SYSCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_HCLK_DIV2;
  RCC_ClkInitStruct.APB3CLKDivider = RCC_APB3_DIV2;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_APB1_DIV2;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_APB2_DIV2;
  RCC_ClkInitStruct.APB4CLKDivider = RCC_APB4_DIV2;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2) != HAL_OK)
  {
    Error_Handler();
  }
  HAL_RCC_MCOConfig(RCC_MCO2, RCC_MCO2SOURCE_SYSCLK, RCC_MCODIV_8);
}

 Ошибку допустил в строчке:

"RCC_OscInitStruct.PLL.PLLP = 2;"

Вместо 2 написал 1. Попробовал прошить, на середине загрузка оборвалась, больше к контроллер не мог подключиться. Взял другое устройство на том же МК. Зашил прошивку с неправильным тактированием, программатор тоже  перестал ее видеть, но через ST-LINK Utilityудалось очистить память и контроллер дальше работает. В первой плате такое не прокатило и МК до сих пор не отвечает. 

В связи с чем вопрос: можно ли окирпичить STM32H7 не правильной настройкой тактирования? Где-то в мануалах читал, что если настройка тактирования не прошла успешно, то МК стартует на дефолтных частотах от внутренней Rc-цепочки, а тут что-то не получилось...

[nanorobot 5]

Вероятно поможет использование Hardware Reset при стирании  STLink-oм. Смотрите в настройках программатора. Я пользуюсь STM32CubeProgrammer.

[x893 45]

Connect Under Reset в помощь

[Turgenev 1]

14 минут назад, x893 сказал:

Connect Under Reset в помощь

Советы ST-LINK Utility выполнил в первую очередь: - выбрал Connect Under Reset;

- понизил частоту до 5 кГц. МК не завелся.

16 минут назад, nanorobot сказал:

Вероятно поможет использование Hardware Reset при стирании  STLink-oм. Смотрите в настройках программатора. Я пользуюсь STM32CubeProgrammer.

Т.е. физически подтянуть ножку ресета МК к земле и начать прошивать? В кейле есть похожая опция:

Спойлер

 

Да и в ST LINK Utility тоже:

Спойлер

У меня интерфейс программирования без ресета, завтра вытащу ресет от МК и подключу к программатору.

[Arlleex 160]

К слову забавный случай: как-то давно товарищ выставил (случайно) PLL на 400 с чем-то МГц на STM32F4, та сильно разогрелась и больше не ожила🙂

[x893 45]

58 minutes ago, Turgenev said:

Советы ST-LINK Utility выполнил в первую очередь: - выбрал Connect Under Reset;

 

58 minutes ago, Turgenev said:

У меня интерфейс программирования без ресета, завтра вытащу ресет от МК и подключу к программатору.

Первое противоречит второму

[Turgenev 1]

14 минут назад, x893 сказал:

Первое противоречит второму

Да, глупо... я это уже осознал😁 выбросил из головы что может не быть физического соединения ресета МК и программатора в законченном устройстве. Исправлю.

Изменено 18 июня пользователем Turgenev

[x893 45]

Just now, Turgenev said:

Да, глупо... я это уже осознал😁 выбросил из головы что может не быть физического соединения ресета МК и программатора в законченном устройстве. Исправлю.

 

Подтяните BOOT0 вверх, включите процессор и программатором сделайте Erase All

[jcxz 216]

1 час назад, x893 сказал:

Подтяните BOOT0 вверх, включите процессор и программатором сделайте Erase All

А можно и не делать Erase All. А просто подтянуть и ... дальше так и продолжать отлаживать в ОЗУ.

 

PS: В который уже раз поражаюсь людям, отлаживающим код во флешь контроллера, имеющего на борту аж 1376 КБ жирнейшего ОЗУ!

Это примерно то же самое, что имея дома электрическое освещение, продолжать пользоваться свечками и керосинками. 

[nanorobot 5]

6 hours ago, nanorobot said:

Вероятно поможет использование Hardware Reset при стирании  STLink-oм. Смотрите в настройках программатора. Я пользуюсь STM32CubeProgrammer.

>>> Т.е. физически подтянуть ножку ресета МК к земле и начать прошивать?  <<<

 

Нет, это опция программы программатора STM32CubeProgrammer, аналогичная Connect Under Reset для ST-LINK Utility .  Там еще есть выбор Core Reset, он, кажется, не требует соединения с ножкой NRST процессора. Пробуйте ...

[EdgeAligned 71]

Вообще-то, можно удерживать ножку сброса в нуле и в начале соединения поймать момент отпускания ножки. При старте МК работает на стандартной частоте без умножителей. 

Также, как советовали, можно загрузиться через системный загрузчик и через УАРТ подключиться утилитой Flash loader demonstrator и стереть флеш.

По поводу отладки через SRAM. Я тоже с удовольствием этим пользуюсь, однако, есть некоторые тонкости, в зависимости от МК, долго описсвввть

12 часов назад, Turgenev сказал:

 

  Показать контент

void SystemClock_Config(void)
{
  RCC_OscInitTypeDef RCC_OscInitStruct = {0};
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

  /** Supply configuration update enable
  */
  HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);
  /** Configure the main internal regulator output voltage
  */
  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

  while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}
  /** Macro to configure the PLL clock source
  */
  __HAL_RCC_PLL_PLLSOURCE_CONFIG(RCC_PLLSOURCE_HSE);
  /** Initializes the RCC Oscillators according to the specified parameters
  * in the RCC_OscInitTypeDef structure.
  */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = 4;
  RCC_OscInitStruct.PLL.PLLN = 80;
  RCC_OscInitStruct.PLL.PLLP = 2;
  RCC_OscInitStruct.PLL.PLLQ = 2;
  RCC_OscInitStruct.PLL.PLLR = 2;
  RCC_OscInitStruct.PLL.PLLRGE = RCC_PLL1VCIRANGE_3;
  RCC_OscInitStruct.PLL.PLLVCOSEL = RCC_PLL1VCOWIDE;
  RCC_OscInitStruct.PLL.PLLFRACN = 0;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }
  /** Initializes the CPU, AHB and APB buses clocks
  */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2
                              |RCC_CLOCKTYPE_D3PCLK1|RCC_CLOCKTYPE_D1PCLK1;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.SYSCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_HCLK_DIV2;
  RCC_ClkInitStruct.APB3CLKDivider = RCC_APB3_DIV2;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_APB1_DIV2;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_APB2_DIV2;
  RCC_ClkInitStruct.APB4CLKDivider = RCC_APB4_DIV2;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2) != HAL_OK)
  {
    Error_Handler();
  }
  HAL_RCC_MCOConfig(RCC_MCO2, RCC_MCO2SOURCE_SYSCLK, RCC_MCODIV_8);
}

ли настройка тактирования не прошла успешно, то МК стартует на дефолтных частотах от внутренней Rc-цепочки, а тут что-то не получилось...

Это если в программе так предусмотрено, то есть если вы это явно написали. А если нет, то последствия будут непредсказуемыми

[Turgenev 1]

12 часов назад, x893 сказал:

Подтяните BOOT0 вверх, включите процессор и программатором сделайте Erase All

Отработало как часы, МК ожил.

10 часов назад, jcxz сказал:

PS: В который уже раз поражаюсь людям, отлаживающим код во флешь контроллера, имеющего на борту аж 1376 КБ жирнейшего ОЗУ!

Можно поподробнее, что вы имеете в виду? Обвешать код printf и выводить через UART на ПК сообщения?

1 час назад, EdgeAligned сказал:

Это если в программе так предусмотрено, то есть если вы это явно написали. А если нет, то последствия будут непредсказуемыми

Думал в HAL это по дефолту.

[VladislavS 39]

2 минуты назад, Turgenev сказал:

Можно поподробнее, что вы имеете в виду?

С таким количеством RAM код на время отладки проще загружать в неё, а не во FLASH. 

[jcxz 216]

3 минуты назад, Turgenev сказал:

Можно поподробнее, что вы имеете в виду?

Отлаживать код в ОЗУ МК. Что и гораздо быстрее и не тратит ресурс флешь и в принципе не грозит такими сюрпризами, какой случился у вас.

[Turgenev 1]

12 часов назад, VladislavS сказал:

С таким количеством RAM код на время отладки проще загружать в неё, а не во FLASH. 

 

12 часов назад, jcxz сказал:

Отлаживать код в ОЗУ МК. Что и гораздо быстрее и не тратит ресурс флешь и в принципе не грозит такими сюрпризами, какой случился у вас.

Это что-то принципиально новое для меня. Изучил гайд от ST на эту тему:

Спойлер

https://community.st.com/t5/stm32-mcus/how-to-place-and-execute-stm32-code-in-sram-memory-with/ta-p/49528

Но я совсем не понял зачем это. Нет, ваши доводы и доводы в статье мне понятны, но... вот, например, экономия ресурса флеш. С ее ресурсом в тысячи циклов записи/стирания мне хватит за глаза. Бедная отладка блюпил, которая у меня лет 10 уже, которую я регулярно мучаю до сих пор не исчерпала этого лимита.

Окирпичивание МК не правильной инициализацией у меня вообще впервые. Может мало работаю с программированием, но из-за одного вот такого раза, да плюс есть способ реанимировать достаточно безболезненный (не как в МК AVR, когда фьюз не тот поставишь), по-моему, не стоит того.

По быстроте и сейчас доли секунд, секунды все интересующие меня операции и функции. 

Хотя. Вот есть у меня интерес узнать сколько загружается контроллер, не нравится что LWIP_INIT() в RAW конфигурации выполняется около 2 секунд, когда все остальное и 1 мс не занимает. Не совсем справедливо, но я записываю значение от выполнения функции HAL_GetTick() при входе в функцию main и записываю значение выполнения HAL_GetTick() перед while(1). Вычитаю второе из первого и получаю время загрузки в мс. Читать значение DWT_CYCCNT не вариант, так как этот счетчик переполняется.

Справедливо ли читать значения HAL_GetTick() в отладчике? По идее HAL_GetTick() основан на тактах ядра и значение должно быть верным. Но даже если не справедливо, я могу получить значение HAL_GetTick() единожды перед бесконечным циклом и отправить его на ПК через Ethernet или любой другой интерфейс не заходя в отладчик, так что и тут нет необходимости помещать прошивку в SRAM. 

P.S.: чтобы не создавать новой темы, был бы очень признателен, если бы вы поделились сколько у вас занимает инициализация RAW LwIP, чтобы понять нормально ли, что она грузится 2 секунды при 400 МГц тактовой ядра. В инете информации по оптимизации скорости загрузки этой библиотеки нет, как и вообще информации сколько она грузится.

 

Изменено 19 июня пользователем Turgenev