msp430f2254. Зависание и выполнение произвольного куска кода в условиях помех Опции

[emark]

Доброго времени суток!

Столкнулся со следующей проблемой. Есть автономное устройство, собранное на msp430f2254. Внешний WatchDog на устройстве отсутствует (сэкономили ). Питание аккумуляторное. От заказчика стали приходить претензии: зависает (лечится только переключением питания). Экспериментально было определено, что проблема в кварце (12 МГц). Но вопрос не в этом. Во время экспериментов я определил, что тыкая какой-нибудь железкой в ножки кварца на раз получаем такое зависание, а иногда (довольно часто) пыполнения кода программы, отвественного за стирания внутреннего программного Flash с понятным результатом. MCLK от кварца. Если MCLK сделать от DCO проблема исчезает.

Кто-нибудь сталкивался таким? Как решили?

[Obam]

Доброго времени суток!

Столкнулся со следующей проблемой. Есть автономное устройство, собранное на msp430f2254. Внешний WatchDog на устройстве отсутствует (сэкономили ). Питание аккумуляторное. От заказчика стали приходить претензии: зависает (лечится только переключением питания). Экспериментально было определено, что проблема в кварце (12 МГц). Но вопрос не в этом. Во время экспериментов я определил, что тыкая какой-нибудь железкой в ножки кварца на раз получаем такое зависание, а иногда (довольно часто) пыполнения кода программы, отвественного за стирания внутреннего программного Flash с понятным результатом. MCLK от кварца. Если MCLK сделать от DCO проблема исчезает.

Кто-нибудь сталкивался таким? Как решили?

Тыкать "…какой-нибудь железкой в ножки кварца…" не надо, он не для этого. Теоретически, если касанием XOUT колебания может и не будут сорваны, то касанием XIN - наверняка.
Рекомендации самые простые: дорожки до кварца как можно кроче, нагрузочные ёмкости должны соответствовать параметрам кварца, под кварцем только малосигнальная земля (ни какой сильноточной).
Аппаратный контроль за тактированием в MSP430 весьма развитый, отладчиком можно получить всё что нужно.

Сообщение отредактировал Obam - Jun 24 2016, 13:38

[emark]

Тыкать "…какой-нибудь железкой в ножки кварца…" не надо, он не для этого. Теоретически, если касанием XOUT колебания может и не будут сорваны, то касанием XIN - наверняка.
Рекомендации самые простые: дорожки до кварца как можно кроче, нагрузочные ёмкости должны соответствовать параметрам кварца, под кварцем только малосигнальная земля (ни какой сильноточной).
Аппаратный контроль за тактированием в MSP430 весьма развитый, отладчиком можно получить всё что нужно.

Тыча, я имитировал помеху. Результат был очень похожий.

Меня смущает другое, возможность (и даже легкость), с которой можно MSP заставить выполнять произвольный кусок кода в прошивке. Обработка прерывания от сбоев генератора мне не помогла.

Аппаратный контроль за тактированием в MSP430 весьма развитый, отладчиком можно получить всё что нужно.

ммм... про отладчик поподробнее. У меня JTAG отладчик сразу виснет, если я подобными издевательствами занимаюсь.

И уж если переразвести не удается, то можно сделать экраны из фольги и прикрыть ими от помех...

Мы этим и занимаемся (поскольку полностью от кварца отказаться не можем) + перевод MCLK на DCO

Сообщение отредактировал emark - Jun 24 2016, 13:59

[jcxz]

Тыча, я имитировал помеху. Результат был очень похожий.
Меня смущает другое, возможность (и даже легкость), с которой можно MSP заставить выполнять произвольный кусок кода в прошивке. Обработка прерывания от сбоев генератора мне не помогла.

Этим Вы не помеху симитировали. В нормально разведённом устройстве помеха не должна туда попадать.
Имхо - таким образом можно почти любой МК "заставить выполнять произвольный кусок кода в прошивке". Так как сбиваете тактирование, следовательно портится например выбираемый в данный момент код на произвольный.
С таким-же успехом можете замкнуть любые произвольные ноги МК и удивиться: "что-ж это он неправильно стал работать-то?"