[ReAl 0]

чота с плюсами лажа какаето

А это не исходники.ру ;) тут этого баловства не особенно.

Судя по тому, что там написано было - надо попробовать ещё прошить старые платы прошивками, скомпилированными новым компилятором и наоборот.

Если где-то шалит какое-то прерывание (обработчик есть, но прерывание не сбрасывается и лупит дальше), то оно может очень сильно тормозить ход основной программы - грубо, в число тактов выполнения обработчика раз (в то время, когда глобально прерывания разрешены, между прерываниями будет проскакивать по одной команде основной программы).

Хотя... "1 из 10 штук завис" - это как-то не очень похоже на прошивку.

[Mozart 0]

вообще может быть из-за ресета по снижению напряжения питания (BODEN). надо его сбросить

[DogPawlowa 0]

вообще может быть из-за ресета по снижению напряжения питания (BODEN). надо его сбросить

Не нужно давать вредные советы - можно доиграться вплоть до потери программы во флэши.

[Mozart 0]

Не нужно давать вредные советы - можно доиграться вплоть до потери программы во флэши.

это как?... я тогда просто не понимаю что происходит при отключении питания... мне казалось, что просто прекращается работа генератора и сё... а как может потеряться программа во флэши??

[DogPawlowa 0]

это как?... я тогда просто не понимаю что происходит при отключении питания... мне казалось, что просто прекращается работа генератора и сё... а как может потеряться программа во флэши??

Не просто.

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

Поэтому контроллер должен быть обязательно сброшен при напряжении питания ниже критического.

[Mozart 0]

Не просто.

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

Поэтому контроллер должен быть обязательно сброшен при напряжении питания ниже критического.

у мну такого ещё не разу не было... учту... сенкс

[Laserr 0]

При снижении питания может произойти все что угодно...

 

ППКС. У меня дома лежит tiny со стертым ID :laughing:

[Yura_K 0]

Было такое же на ATmega8535. Правда стоял на плате в одной сборке с усилителями ШИМ (2 канала по 5 ампер) :). Решилось все экранированием платы (под ней силовые провода на нагрузку лежали).

[VladimirYU 0]

Не просто.

 

Поэтому контроллер должен быть обязательно сброшен при напряжении питания ниже критического.

Полностью согласен. При этом, из собственного опыта, не доверяю ни каким BODам, а ставлю внешний супервизор. +20 рублей, но про такие проблемы забываешь раз и навсегда.

[smalcom 0]

да, кстати, проблема была в том, что прогу скомпилил новым набором утилит - gcc-4.3.0, binutils-2.18, glibc-1.6; раньше были gcc-3.4.0, binutils-2.17, glibc-1.4

[Flasher 0]

Могу рассказать в чем секрет зависания устройства. Будете долго удивляться. - Это компьютерный блок питания. В большинстве случаев товарищи даже и не знают, что пытаются запитать свою технику от драндулета, на корпусе которого в незаземленном варианте присутствует 110 Вольт, и касание отверткой заставляет стекать заряд с конденсаторов через корпус на отвертку и через внутренние цепи контроллера. Этот драндулет имеет ужасающе большой спектр помех. Плюс пульсации в ВЧ области вполне достаточные, чтобы процессор рестартанул (в лучшем случае) или начал выполнять вообще неизвестно что, пока напряжение просело ниже допустимого... Так что дерзайте- можно запитать девайс еще от велогенератора или пьезоподжигалки- и искать глюки в программе можно до посинения.

[ReAl 0]

да, кстати, проблема была в том, что прогу скомпилил новым набором утилит - gcc-4.3.0, binutils-2.18, glibc-1.6; раньше были gcc-3.4.0, binutils-2.17, glibc-1.4

И всё-таки, как это может влиять не на "тотальное" зависание, а на "1 из 10".

Что касается разницы между 3.х и 4.х, то 4.х гораздо агрессивнее оптимизирует работу с не-volatile-переменными, скажем,

#include <avr/io.h>

#include <avr/interrupt.h>

 

unsigned cnt;

 

unsigned foo(void)

{

int tmp;

uint8_t sr = SREG;

cli();

tmp = cnt;

SREG = sr;

return tmp;

}

 

Успешно компилируется в

foo:

/* prologue: frame size=0 */

/* prologue end (size=0) */

in r24,95-0x20

/* #APP */

cli

/* #NOAPP */

out 95-0x20,r24

lds r24,cnt

lds r25,(cnt)+1

/* epilogue: frame size=0 */

ret

Т.е. по сути в

uint8_t sr = SREG;

cli();

SREG = sr;

return cnt;

Что вполне соответствует стандарту :), cnt тоже надо объявить volatile, чтобы сохранился интересующий порядок операций.

 

 

 

Могу рассказать в чем секрет зависания устройства. Будете долго удивляться. - Это компьютерный блок питания.

Удивляюсь :) Вот чего не знал, того не знал... :)

И как дурак уже 15 лет на столе держу в качестве источника для отлаживаемых плат компьютерные блоки питания :) Если место позволяет - часто даже на плате кроме штатного разъёма ещё штыри заложены под флопарный разъёмчик, чтобы переходник не был нужен.

И ничего не "рестартует в лучшем случае", включая сам комп, внутри которого стоит такой же блок питания. И изделия серийные выпускаются в компьютерном корпусе и с компьютерным блоком питангия - там и микроконтроллеры, и ПЛИС, и АЦП горстями (ну да, по питанию АЦП фильтры дополнительные).

Может это? Прокладочку поменять?

[Samsony 0]

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

контроллер - ATMega128-16AU. Программа раньше работала, проблеиы появились только в текущем месяце на новых устройствах. Не знаю на кого грешить((

 

PS. менял кварц - непомогло

PPS. частота - 14.7456МГц

 

Попробуйте выяснить кто виноват. Для это:

- Запитайте устройство не от БП (господин Flasher правильно высказал свое мнение по поводу компьтерного БП - помойка там конкретная);

- Если не полегчает, то отключите от источника питания платы все, что может приводить к "просадкам" питания (в идеале - оставить только проц и светодиод какой нибудь)

- Правильно выставьте бит CKSEL. Посмотрите осцилом на амплитуду на кварце - должна быть не менее 1,5В...

- Отключите супервизор, RESET повесьте прям на ногу питания МК

 

Кстати, как схема питания реализована?

 

Было у нас такое дело - производили устройство, все было ОК....

Затем пошел серийный брак - устройство вроде работает, но после установки на транспорт - сбойт... Виснет, перестает работать, перезапускается....

Думал долго, перепахал всю плату - не помогло. А дело было вот в чем. Использовали программатор ChipProg который стоял на компьютере с которого прошивались изделия. В один прекрасный или ужасный день наши герои - радиомеханики переставили винду, поставили какую то "тюнингувую модель ручной сборки WinXP. С этого дня брак и пошел. Хотя все отлично прошивалось и тестировалось...

[smalcom 0]

старый набор avrtools и новый генерят разный код, предположительно изменена схема работы с переменными и прологи/эпилоги(в новом) засим вполне вероятно предсказанная ReAl ситуация с постоянной обработкой прерывания(честно еще досконально листинги ассемблера неразбирал). Программы скомпиленные новым набором(замечено пока только в коде для m128) зависают.

[Igor26 0]

Это компьютерный блок питания.

Интересно знать, уважаемый, а как у тебя компьютер то работает от компьютерного блока питания? Он ведь сложней твоего девайса в десятки раз.