LiVit

STM32F030R8 греется - кто сталкивался?

7 posts in this topic

LiVit    12

Приветствую, коллеги!

Ситуация такая: есть серия устройств на STM32F030R8, на некоторых время от времени начинает греться микроконтроллер. 
Вся логика работает, всё вроде в порядке, кроме потребления в 250мА. И перегретого корпуса микроконтроллера.

В прошивке изначально отсутствовала инициализация неиспользуемых ног, кроме того, проц сначала старается завести внешний кварц, и только потом переходит на внутренний генератор.
Нога BOOT0 притянута к земле напрямую, без резистора.

На проце который уже начал перегреваться, я сделал инициализацию всех ног на вход, с подтяжкой ног к земле. Сразу завожу внутренний тактовый генератор.
К сожалению, ему уже ничего не помогает, - даже будучи стертым, он жрет 200 мА. Как я понимаю, тут мои полномочия всё.

Хотелось бы услышать от коллег, что именно могло вызвать такую странную неисправность проца? Может кто сталкивался? В Errata ничего подобного не нашел.

Share this post


Link to post
Share on other sites
Lexter    399
6 минут назад, LiVit сказал:

В прошивке изначально отсутствовала инициализация неиспользуемых ног

Это не значит, что она отсутствовала. Была инициализация Default.

 

10 минут назад, LiVit сказал:

что именно могло вызвать такую странную неисправность проца?

Например, неподключенное "аналоговое" питание.

Share this post


Link to post
Share on other sites
mail_robot    1503

кмк для начала надо посмотреть схему, что и как спроектировано. Чудес не бывает. Не могут камни сами по себе время от времени умирать, да еще и пачками.

Инициализация ног по дефолту - цифровой вход. Производитель рекомендует на всякий пожарный инициализировать неиспользуемые как аналоговый вход, чтобы минимизировать энергопотребление. Но мне кажется это не ваш случай. Дело тут в другом.

Share this post


Link to post
Share on other sites

Старт складской программы по Wi-Fi/ Bluetooth-чипам от Espressif

На склад КОМПЭЛ поступили чипы, модули и отладочные платы от компании Espressif Systems на базе ESP8266 и ESP32. Стоимость всех изделий данной линейки – в 2-3 раза ниже ближайших аналогов, чипы занимают минимальное место на плате, энергоэффективны и универсальны в применении

Подробнее...

LiVit    12

Да, видимо проще схему приложить. scheme.PDF
Убрал со схемы всё, что не распаяно на плате.

На счет дефолтного конфига ног я в курсе, друзья. Я имел в виду, что они по дефолту к земле не подтянуты.
Остается только подозрение по поводу подключения LCD, но управляющие линии посажены на 5В толерантные ноги. Да и подтягивающие резисторы 10к - не тот ток, чтобы проц угробить.

Edited by LiVit

Share this post


Link to post
Share on other sites
optima    234

Проверьте инициализацию тактирования, не завышена ли у какого нибудь модуля частота! Был такой косячек на контроллерах с Али, при чем интересно после установки тактовых частот в предел нормы ток потребления  в норму уже не возвращался. Такое ощущение что чему то приходит кирдык. При всем при этом, ранее заказанные процы с элитана спокойно с этим справляются. 

Share this post


Link to post
Share on other sites

Видео вебинара «Уникальный подход MORNSUN к разработке DC/DC-преобразователей. Что на выходе?»

На сайте КОМПЭЛ доступны материалы вебинара, посвященные последнему поколению DC/DC преобразователей с фиксированным входом R3 от MORNSUN. Вы можете посмотреть видеозапись, ознакомиться с презентацией и ответами на вопросы.

Подробнее...

mail_robot    1503

схемка ни о чем конечно. Учебная

однако спроектирована все равно с ошибками. Линии данных дисплея в подтяжках не нуждаются, тем более к 5 вольтам. А вот включение последовательно ногам резисторов 220 Ом является хорошим тоном, особенно на линиях т.н. толерантных

DA4 вообще лишняя в схеме. А все что лишнее - потенциальный источник проблем

опять же, если есть DA4, для какого тогда фига стоит VT1? А если он таки есть, то зачем биполярный? Лишняя гальваника на цепи 12В

кнопки тоже по чукотски стоят

сдается мне что дело опять не в бобине...

Edited by mail_robot

Share this post


Link to post
Share on other sites
LiVit    12
22 минуты назад, optima сказал:

Проверьте инициализацию тактирования, не завышена ли у какого нибудь модуля частота! Был такой косячек на контроллерах с Али, при чем интересно после установки тактовых частот в предел нормы ток потребления  в норму уже не возвращался. Такое ощущение что чему то приходит кирдык. При всем при этом, ранее заказанные процы с элитана спокойно с этим справляются. 

А вот ваша идея мне нравится.
Проверю - отпишусь.

Share this post


Link to post
Share on other sites

Your content will need to be approved by a moderator

Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Similar Content

    • By LiVit
      Привет коллеги! Данная публикация - для тех, кто еще не все плюшки UARTA попробовал ))
      USART1 (и только он) микроконтроллеров серии STM32F030 предоставляет возможность принимать пакеты данных с неизвестной заранее длиной пакета.
      Для этого можно использовать овертаймер.
      Работает это так:
      Если в течение заданного времени не будет принят старт-бит очередного байта, генерируется прерывание.
      Время ожидания задается не физически (в секундах), а в количестве бит, которые могли бы быть приняты на данной скорости.
      т.е., если мы зададим число 16, то прерывание возникнет, если в течение времени эквивалентному приему 16 бит, на вход USART не поступит старт-бит.

      Как включить.
      1 разрешим прерывание - бит RTOIE регистра CR1
      2 зададим время (количество бит) в регистре RTOR
      3 разрешим работу овертаймера - бит RTOEN регистра CR2
      4 при возникновении прерывания от USART1, смотрим флаг RTOF в регистре ISR, - если есть флаг, значит это оно
      5 сбросим флаг прерывания - бит RTOCF в регистре ICR.
      Как я это использую.
      Включаю прерывание при инициализации порта и задаю количество бит для счетчика.
      Как только приходит первый байт сообщения - в прерывании разрешаю работу овертаймера.
      Все принятые байты сохраняю в буфер.
      Когда возникнет прерывание по овертайму - запрещаю овертаймер, и передаю пакет на парсинг.
    • By User_1
      Всем привет!
      Почему-то этот код работает: 
      void Send_to_UART(char* string) { char data = 0; while(*string) { while(!(USART_GetFlagStatus(USART1, USART_FLAG_TXE))); data = *string; USART1->TDR = data; string++; } while(!(USART_GetFlagStatus(USART1, USART_FLAG_TXE))); USART_SendData(USART1, 0x0D); while(!(USART_GetFlagStatus(USART1, USART_FLAG_TXE))); USART_SendData(USART1, 0x0A); while(!(USART_GetFlagStatus(USART1, USART_FLAG_TC))); } char hello[13] = {'H','e','l','l','o',' ','W','o','r','l','d','!'}; int main (void) { Init_Clock(); Init_USART1(); Send_to_UART(hello); while(1); } А если написать вот так:
      int main (void) { Init_Clock(); Init_USART1(); Send_to_UART("Hello World!"); while(1); } то не просто не работает - микроконтролер зависает даже до входа в main().
      В Си ведь, насколько я понимаю, строка - это тот же массив символов
      Объясните, пожалуйста, что я делаю не так?
      Камень stm32f030, среда CooCox CoIDE
    • Guest Максим
      By Guest Максим
      Всем светлым и умным головам привет!

      Никак не могу найти информацию о данном прерывании TIM1_BRK_UP_TRG_COM.
      Вопрос 1: Что это за стек или система прерываний? 
      Вопрос 2: Когда будет вызываться обработчик прерывания TIM1_BRK_UP_TRG_COM_IRQHandler, если также есть обработчик прерывания TIM1_CC_IRQHandler?
      Вопрос 3: период переполнения таймера равен 100 мкс. Сколько раз будет вызываться обработчик прерывания TIM1_BRK_UP_TRG_COM_IRQHandler до обработчика прерывания TIM1_CC_IRQHandler? По логике вещей, предполагаю, что 100 раз?
      Заранее благодарен!

      Всем радости))
    • By User_1
      Доброго времени суток!
      Вкратце: нужно после того, как я записал байт данных в SPI1->DR, отменить передачу этого байта и вместо него отправить 0х00
      Подробно: Смысл вот в чём: некий контроллер, с которым я пытаюсь наладить общение по SPI, запрашивает произвольный участок массива байт и считывает их сплошным потоком. Ну примерно как считывается микросхема EEPROM: задаёшь начальный адрес, а потом просто шлёшь сплошные 0xFF, а она сама инкрементирует адрес и прямо непрерывным потоком байт выдаёт содержимое памяти. Только тут в роли этой микросхемы мой stm32f030 и мне нужно следующий байт отправлять в SPI1->DR сразу после отправки предыдущего. Но когда поток заканчивается (а он каждый раз разной длины и длина эта заранее неизвестна), один байт остаётся не переданным и отправится первым при следующем запросе. А мне нужно, чтобы первым байтом всегда отправлялся 0х00
      Пином (ну то есть битом) NSS управляю программно, его выставление в единичку и снова в ноль, очевидно, не помогает вообще никак. Пока решил проблему так: деинициализирую модуль SPI и выключаю его тактирование, затем включаю тактирование и снова инициализирую. Работает, скорости хватает. Но должно же быть менее костыльное решение?)
      Может кто сталкивался с такой проблемой?
      Курение даташита, reference manual и результатов поиска в гугле, не особо помогло.
    • By LiVit
      Добрейшего всем времени суток!
      Случилось недавно моему заказчику захотеть защитить прошивку от считывания (да, я знаю, люди эту защиту сковыривают на раз, но это уже не моя беда). А так как делать это вручную, при прошивке каждого проца, довольно геморройно, было решено добавить в код "самозащиту".
      Почитав мануал на проц, погуглив, почитав комментарии в stm32F0xx_flash.h, я написал следующий код:
          #include "stm32F0xx_flash.h"     if (RESET == FLASH_OB_GetRDP())        //checking protection status     {         FLASH_OB_Unlock();    //unblock the Option Byte         if (FLASH_COMPLETE == FLASH_OB_RDPConfig(OB_RDP_Level_1))     FLASH_OB_Launch();         FLASH_OB_Lock();     } Казалось бы, всё сделано так, как рекомендовано. Тем не менее, этот код не работает.
      Гугль показал, что данная тема волнует не только меня, но и других камрадов. 
      В общем, правильное решение выглядит так:
          #include "stm32F0xx_flash.h"         if (RESET == FLASH_OB_GetRDP())        //checking protection status     {         FLASH_Unlock();    //unblock the FLASH (!!)         FLASH_OB_Unlock();    //unblock the Option Byte         if (FLASH_COMPLETE == FLASH_OB_RDPConfig(OB_RDP_Level_1))     FLASH_OB_Launch();         FLASH_OB_Lock();         FLASH_Lock();     } Обратите внимание, - перед тем, как разблокировать Option Byte, необходимо разблокировать саму флэшь.