Jump to content

    

STM32L082 в спячке ест больше, чем на всем скаку

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

Без WFI и пин TEST2 не дергается? Там случайно нет каких подтяжек которые могут чтото потреблять?

Дык в том-то и дело, что у него при одинаковых условиях магия... Влияет только WFI().

Share this post


Link to post
Share on other sites
7 minutes ago, Arlleex said:

Дык в том-то и дело, что у него при одинаковых условиях магия... Влияет только WFI(). 

Я понимаю что условия одинаковые а еще нужно понимать что без WFI пин TEST2 будет практически всегда находиться в нуле, это единственное отличие(для приведенного кода) которое может повлиять на потребление,например не верной конфигурацией пина или наличием внешних подтяжек.
Хотя логично предположить что TEST2 уже появился в момент дебага, после обнаружения проблемы но уточнить этот момент думаю стоит.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
50 minutes ago, Сергей Борщ said:

Это потребление всей схемы с датчиками.

А как ведет себя WFI без инита датчиков и всего остального, что показывают такие примитивные тесты?
 

//Test run
int main() {
 
  for(;;) {    
  }
}

//Test sleep
int main() {
 
  for(;;) {
      __WFI();   
  }
}



Вообще, ооочень странная ситуация, может методику или оборудования измерения сменить?

Share this post


Link to post
Share on other sites

А вобще ктонибудь доки читает? Я нет и потому не сразу узнал что в stn32f3..4...7...h7 в LP регистрах RCC установлены биты всех устройств?

Edited by GenaSPB

Share this post


Link to post
Share on other sites
41 минуту назад, GenaSPB сказал:

в LP регистрах RCC установлены биты всех устройств

И в описании каждого бита написано, что тактирование включается только для тех модулей, которые включены битом EN в регистрах самой периферии. Я решил, что "у нас принято джентельменам верить на слово". Может и врут, надо проверить. Исключений очень мало, SYSCFG, DBG и порты я выключал - не помогло, ПДП я во сне использую. Из остального в регистрах периферии включаю только I2C и TIM6. Да и сильно маловероятно, что даже вся периферия в сумме будет кушать в несколько раз больше ядра (оно по моим прикидкам должно есть 6 мА / 32 МГц = .188 мкА/МГц, каждая периферия в среднем 10 мкА/МГц). 

Тоже весь день думал об этих регистрах. Сейчас проверю, насколько изменится картина, если сбросить все биты неиспользуемой периферии.

Share this post


Link to post
Share on other sites
2 часа назад, Integro сказал:

А как ведет себя WFI без инита датчиков и всего остального, что показывают такие примитивные тесты?

Мне проще было сделать бесконечный цикл вместо опроса датчика. Пустой цикл с ногодрыгом ноги  - 8.85 мА. Пустой цикл с WFI - 3.05 мА. Хм. Тут тенденция с теорией сходится - с WFI потребеление меньше. Откуда такие огромные цифры - буду копать. В общем - чуда нет, надо трясти. Спасибо за подсказку. Надо разбираться, что там Semtech на пару с кубом в своем стеке наворотили: этот глубокий сон - часть их реализации стека LoRaWAN и что-то они там еще творят перед засыпанием и после просыпания. Просто поскольку в глубоком сне потребеление было вполне адекватное - я туда и не лез. Похоже, надо не датчики к стеку прикручивать, а стек понемногу к датчикам добавлять и смотреть, на каком этапе начнутся чудеса.

Share this post


Link to post
Share on other sites

Может быть при использововании WFI увеличивается общее время активной работы? Ведь на пробуждение после WFI ядру требуется время, не знаю точно сколько мкс. А если это повторяется в цикле...

Share this post


Link to post
Share on other sites
13 часов назад, piroman сказал:

Ведь на пробуждение после WFI ядру требуется время, не знаю точно сколько мкс. А если это повторяется в цикле...

Из Idle (когда спит только ядро) - не требуется.

 

Можно попробовать:

1. Заменить WFI на WFE.

2. Убрать проверку таймаута (по TIM6).

3. Построить работу как советует мануал на инструкции WFI/WFE: выполнять их в отдельном цикле ожидания, а не вместе с полезным кодом. Или вообще - вынести всю полезную работу в обработчики прерывания, а в фоновом процессе крутить только одну инструкцию WFI/WFE. Или вообще использовать режим работы с SCR.SLEEPONEXIT=1.

PS: Да - и какое у Вас состояние регистра SCR ядра?

Share this post


Link to post
Share on other sites
13 часов назад, piroman сказал:

Может быть при использововании WFI увеличивается общее время активной работы?

Буквально на доли процента. Если диаграмма (с WFI) в первом сообщении занимает 1.22 мс, то такая же без WFI - 1.15 мс

1 минуту назад, jcxz сказал:

2. Убрать проверку таймаута (по TIM6).

на потребеление оно не влияет, проверял.

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

Реализовать всю работу как советуют в мануале на WFI/WFE: выполнять их в отдельном цикле ожидания, а не вместе с кодом.

Что-то не видел я такого в документации. В какой именно документации это описано?

6 минут назад, jcxz сказал:

Или вообще - вынести всю полезную работу в обработчики прерывания, а в фоновом процессе крутить только одну инструкцию WFI/WFE.

Это мне не подходит.

12 минут назад, jcxz сказал:

PS: Да - и какое у Вас состояние регистра SCR ядра?

По нулям.

 

Беру паузу разобраться, кто же на плате жрет 3 мА во время сна в пустом цикле без опроса датчика.

Share this post


Link to post
Share on other sites
7 минут назад, Сергей Борщ сказал:

Что-то не видел я такого в документации. В какой именно документации это описано?

"ARMv6-M Architecture Reference Manual":

Because debug entry is one of the WFI wake-up events, ARM recommends that software uses Wait For 
Interrupt as part of an idle loop rather than waiting for a single specific interrupt event to occur and then 
moving forward. This ensures the intervention of debug while waiting does not significantly change the 
operation of the program being debugged.

 

Даже не касательно Debug в реализации WFI могут быть какие-то особенности оптимизированные на именно такой стиль работы. Там есть ещё про "IMPLEMENTATION DEFINED", допускаю что от исполнения WFI может идти какой-то сигнал контроллеру питания, что и может влиять на потребление.

 

Цитата

Это мне не подходит.

Почему?

Share this post


Link to post
Share on other sites
1 минуту назад, jcxz сказал:

Почему?

Потому что сейчас кроме опроса датчика программа иногда выполняет кубовый стек lorawan, а когда я напишу вместо него свой - программа будет работать под управлением ОС.

Share this post


Link to post
Share on other sites
10 минут назад, Сергей Борщ сказал:

Беру паузу разобраться, кто же на плате жрет 3 мА во время сна в пустом цикле без опроса датчика.

Хммм.... А мы тут все думали что Вы потребление только МК измеряете....  :wink:

Share this post


Link to post
Share on other sites
4 минуты назад, jcxz сказал:

Because debug entry

Ясно. В програмах под управлением ОС у меня так и сделано. Как это реализовать без ОС я слабо представляю.

Только что, jcxz сказал:

А мы тут все думали

"Отучаемся говорить за других". Это раз. Второе - как добавление WFI в цикл ожидания завершения прерывания может повлиять на потребеление чего-то за пределеами МК?

Share this post


Link to post
Share on other sites
7 минут назад, Сергей Борщ сказал:

Ясно. В програмах под управлением ОС у меня так и сделано. Как это реализовать без ОС я слабо представляю.

Не сложно:

Взять какое-нить прерывание от периферии (не используемое); назначить ему приоритет ниже приоритета любого прерывания от периферии; поместить полезную работу в его ISR; когда нужно выполнить полезную работу - активизировать это прерывание программно (через регистры NVIC); по исчерпании полезной работы - выходить из этого ISR (выход будет в фоновый процесс - в цикл while (1) __WFE(); или использовать SCR.SLEEPONEXIT=1).

Собственно этот программно-активизируемый ISR будет эмуляцией задачи РТОС. Можно даже всё делать на одном стеке так как вытеснение задач не нужно.

10 минут назад, Сергей Борщ сказал:

Потому что сейчас кроме опроса датчика программа иногда выполняет кубовый стек lorawan, а когда я напишу вместо него свой - программа будет работать под управлением ОС.

Ну так SCR.SLEEPONEXIT=1 не мешает РТОС. У меня например в РТОС фоновый процесс только WFE выполняет, да иногда ещё загрузку CPU считает. Если загрузку CPU считать не надо, то элементарно вместо фонового цикла 

while (1) __WFE(); поставить SCR.SLEEPONEXIT=1 и всё будет работать точно так же.

Да и стеку мне кажется - не должно мешать.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now