У нас есть продукт, который использует MSP430F5436A. Он был в производстве в течение нескольких лет. За последние несколько месяцев мы получили от производства сообщения о том, что несколько блоков не отключаются полностью, их индикатор питания горит постоянно. Индикатор питания управляется расширителем IIO C GPIO, он не подключен напрямую к MSP430.
Когда пользователь нажимает кнопку питания, MSP430 должен выключить много периферийных устройств, выключить индикатор питания и введите LPM2. Периодически прерывание таймера выводит его из LPM2, чтобы проверить, была ли нажата кнопка питания, чтобы снова включить устройство и выполнить другие домашние операции.
После того, как пользователь нажал кнопку питания, появляется задержка перед выключением устройства, которое запускается через таймер ISR. Я разорвал это и вставил задержку l oop. В пределах этой задержки l oop я быстро переключаю другой светодиод, подключенный напрямую к MSP430.
Если я уменьшу длительность l oop менее двух секунд, устройство сможет успешно войти в LPM и светодиод перестает переключаться. Если я установлю l oop дольше двух секунд, я смогу наблюдать поведение блокировки, которое вижу. Иногда светодиод остается включенным или выключенным, что является случайным.
Я пытался отключить все маскируемые прерывания перед вводом l oop. Это не имело никакого эффекта. Я также поместил код в векторы SYSNMI и UNMI, чтобы определить, срабатывает ли один из них и не запускается ни один. Также нет RTOS, это кооперативная многозадачная система. Таким образом, кажется, что он блокируется при выполнении самого l oop.
В конце концов мое устройство перезагружается из этой блокировки, но это происходит из-за сброса сторожевого таймера. Я печатаю источник сброса при запуске. Устройство также восстанавливается, если я вытащу и снова вставлю батарею. Тем не менее, устройство остается в заблокированном состоянии, если я потяну линию сброса на низком уровне. У меня также возникают проблемы с JTAGG-прошивкой на устройстве после его блокировки.
Я искал ошибки в MSP430F5436A для упоминаний о поведении блокировки, и единственное упоминание не имеет значения.
К сожалению, из-за упаковки и конструкции устройства некоторые зонды трудно исследовать, но не невозможно.
Я могу подключиться к устройству с помощью отладчика, но отладчика (CCS 7 + MSP-FET430UIF) теряет связь с устройством вскоре после запуска устройства. Это то, что всегда верно и является проблемой дизайна. У нас частые прерывания по таймеру, поэтому такое поведение невозможно избежать.
Источник питания устройства стабилен и работает на моем стенде, а не в среде с высоким уровнем электромагнитных и электромагнитных помех. Однако при возникновении этого l oop некоторые периферийные устройства и источники питания были бы отключены. Таким образом, возможно, что какая-то аномалия происходит на одной из силовых шин MSP430 или выводе GPIO.
Что может быть причиной этого поведения блокировки? Существуют ли какие-либо постоянные регистры, которые я могу прочитать при сбросе, которые могли бы дать мне подсказку, или есть какие-либо булавки / сети, которые я могу исследовать, чтобы дать мне подсказку?
Обновление: я проверял V CC для MSP430, рельсы для питания периферийных устройств, к которым подключен MSP430, и линия сброса. Я не вижу изменений ни в одном из них во время блокировки.
Редактировать: следующая задержка l oop, которую я добавил
dprintf(PRINT_LOG, "Entering delay loop");
__disable_interrupt();
enable_backlight();
for(uint16_t j = 4u; 0u < j; --j)
{
__delay_cycles(14680064/20); // ~50mS delay w/ 14.680064 MHz MCLK
toggle_backlight();
}
disable_backlight();
__enable_interrupt();
dprintf(PRINT_LOG, "Exiting delay loop");