-
- +1 и это очень радует!!! - Aleksey_75(11.01.2019 16:53)
- Ну как сказать!) Есть устройство которое скажем так проблематично перепрошить программатором, но удаленно прошить возможно. В этом устройстве после рестартов может пару байт еепром портиться. Причины могут быть разными, но в том числе и этот фьюз Троешник(15 знак., 11.01.2019 17:03)
- Помнится первое что объясняли начинающим avr-водам: "никогда не использовать первые байты eeprom". Неужто досель не поправили? - LightElf(11.01.2019 17:07)
- Это не AVR надо исправлять, а мозги гавноАВРкодеров. Им не понять, что до набора нормального питания нужно АВР держать в ресете (BODEN должен быть активен), и что при старте EEAR = 0, что резко увеличивает шансы записать пургу в 0-ю ячейку EEPROM - MBedder(11.01.2019 17:55)
- Почему все считают, что портится при включении? При включении дополнительная задержка фусами может помочь. Выключение же длится дольше, вероятность сбоя больше, никакие задержки фусами не спасут. Бывает, на плате кварц 16МГц, а BODLEVEL установят maleon(49 знак., 12.01.2019 19:02 - 19:19)
- Чукча - явно не читатель --> - MBedder(12.01.2019 19:39, ссылка)
- Да ладно, оставлять в МК такую подлянку - это низко. Помнится, что-то похожее было с сайлабсами, в более поздних моделях пофиксили. - SciFi(11.01.2019 18:12)
- Это свойственно абсолютно всем МК, страдающим самоёбством. А от рукожопов, выключающих/не включающих супервизор, не спасет ничего, кроме регулярного битья по рукам - MBedder(11.01.2019 18:43)
- С обычными AVRами нормально все, если внутренний BOD включен или есть внешний вообще никаких проблем. Вот с Хмегами проблема есть - EEPROM очень редко, но слетает. Причина не выяснена, сделал пока троирование критичных данных. - AlexG(11.01.2019 18:17)
- Почему все считают, что портится при включении? При включении дополнительная задержка фусами может помочь. Выключение же длится дольше, вероятность сбоя больше, никакие задержки фусами не спасут. Бывает, на плате кварц 16МГц, а BODLEVEL установят maleon(49 знак., 12.01.2019 19:02 - 19:19)
- реально помогает установка этого фьюза на устройствах которые территориально рядом. то есть: фьюз взвели - нет проблем. Троешник(92 знак., 11.01.2019 17:11)
- А какие байты портятся? Как обычно первые? Может прошивку поменять, чтобы их не использовать? - LightElf(11.01.2019 17:40)
- По рекомендации Атмела : 1)не пользовать 0-ю ячейку EEPROM 2) после каждой операции чтения/записи обнулять регисрты EEARH, EEARL. если не соблюдать эти условия то велика вероятность порчи ячеек EEPROM адрес которых записан в EEARH:EEARL. - m16_home(11.01.2019 18:00)
- EARTH EARL? Типа "граф Земли"? Галактическая империя, йопта. - SciFi(11.01.2019 20:11)
- Ну вот я типа и намекаю топикстартеру, что если нет возможности прошить фьюз, то по крайней мере можно софтверными исправлениями снизить вероятность ошибки. Ну и постепенно перешить фьюзы. - LightElf(11.01.2019 18:27)
- память бьется одиночными байтами, в большинстве того что я видел. Троешник(310 знак., 11.01.2019 19:20)
- А что мешает программно сделать необходимую задержку перед чтением ЕЕПРОМ, если фусы недоступны? И перед выключением тоже запретить обращение к ЕЕПРОМ :-). - maleon(12.01.2019 19:10 - 19:52)
- Обращение к ЕЕПРОМ вообще должно быть запрещено всегда, кроме непосредственно обращения - MBedder(12.01.2019 19:41)
- А что будет, если МК не подозревая о предстоящем выключении, со всеми предосторожностями начал запись (необходимо несколько мсек), а тут его Brown-out сбросил через 1 мсек? Такое выключение теоретически можно спрогнозировать, если при помощи АЦП maleon(167 знак., 12.01.2019 20:12)
- Такие ситуации легко отлавливаются и исправляются при следующем включении с помощью CRC/КС. Не сошлась КС - заменяй данные на дефолтные. P.S. сносить не туда запощенное сообщение вовсе не нужно - есть функционал "прикрепить" - MBedder(12.01.2019 20:17 - 20:20)
- Правильные пацаны делают типа журнал, атомарность операций обеспечивается. Не записалось до конца - будет то, что было перед этим. - SciFi(12.01.2019 20:20)
- char RestoreSetupUntilSuccessful(void) VLLV(212 знак., 12.01.2019 20:25)
- А если 3, 4 и т.д.? :)) - MBedder(12.01.2019 20:27)
- А памяти больше нет :) - VLLV(12.01.2019 20:34)
- А если 3, 4 и т.д.? :)) - MBedder(12.01.2019 20:27)
- Именно поэтому Волга до сих пор и впадает в Каспийское море, а не куда-нибудь в Миссисипи :)) - MBedder(12.01.2019 20:22)
- char RestoreSetupUntilSuccessful(void) VLLV(212 знак., 12.01.2019 20:25)
- Правильные пацаны делают типа журнал, атомарность операций обеспечивается. Не записалось до конца - будет то, что было перед этим. - SciFi(12.01.2019 20:20)
- Такие ситуации легко отлавливаются и исправляются при следующем включении с помощью CRC/КС. Не сошлась КС - заменяй данные на дефолтные. P.S. сносить не туда запощенное сообщение вовсе не нужно - есть функционал "прикрепить" - MBedder(12.01.2019 20:17 - 20:20)
- А что будет, если МК не подозревая о предстоящем выключении, со всеми предосторожностями начал запись (необходимо несколько мсек), а тут его Brown-out сбросил через 1 мсек? Такое выключение теоретически можно спрогнозировать, если при помощи АЦП maleon(167 знак., 12.01.2019 20:12)
- Обращение к ЕЕПРОМ вообще должно быть запрещено всегда, кроме непосредственно обращения - MBedder(12.01.2019 19:41)
- Обычно память портится во время случайного старта функции записи из-за сбоя ядра при нештатном питании. - VLLV(11.01.2019 19:31)
- записи на старте нет. только чтение. одним блоком большим все вычитывается в озу - Троешник(11.01.2019 19:39)
- А что мешает программно сделать необходимую задержку перед чтением ЕЕПРОМ, если фусы недоступны? И перед выключением тоже запретить обращение к ЕЕПРОМ :-). - maleon(12.01.2019 19:10 - 19:52)
- память бьется одиночными байтами, в большинстве того что я видел. Троешник(310 знак., 11.01.2019 19:20)
- По рекомендации Атмела : 1)не пользовать 0-ю ячейку EEPROM 2) после каждой операции чтения/записи обнулять регисрты EEARH, EEARL. если не соблюдать эти условия то велика вероятность порчи ячеек EEPROM адрес которых записан в EEARH:EEARL. - m16_home(11.01.2019 18:00)
- А какие байты портятся? Как обычно первые? Может прошивку поменять, чтобы их не использовать? - LightElf(11.01.2019 17:40)
- Это не AVR надо исправлять, а мозги гавноАВРкодеров. Им не понять, что до набора нормального питания нужно АВР держать в ресете (BODEN должен быть активен), и что при старте EEAR = 0, что резко увеличивает шансы записать пургу в 0-ю ячейку EEPROM - MBedder(11.01.2019 17:55)
- там еще есть пару интересных фузов от которых погибла не одна сотня мк ))) типа rstdisbl )) - Aleksey_75(11.01.2019 17:06)
- погибла? ты не прав. есть дракон, есть режим High Voltage Serial Programming . погибших можно оживить. - m16_home(11.01.2019 17:14)
- Помнится первое что объясняли начинающим avr-водам: "никогда не использовать первые байты eeprom". Неужто досель не поправили? - LightElf(11.01.2019 17:07)
- Ну как сказать!) Есть устройство которое скажем так проблематично перепрошить программатором, но удаленно прошить возможно. В этом устройстве после рестартов может пару байт еепром портиться. Причины могут быть разными, но в том числе и этот фьюз Троешник(15 знак., 11.01.2019 17:03)
- +1 и это очень радует!!! - Aleksey_75(11.01.2019 16:53)