STM32 защита от сбоев клока?, Фейерверк в силовом контроллере. Опции

[khach]

Добрый день, или вернее не очень.
Вот возник вопрос в результате фейерверка. Контроллер STM32 управлял трехфазным силовым мостом. Все прекрасно работало, но в результате внешних воздействий произошел срыв захвата внутренней петли ФАПЧ клокового генератора. В результатае изменились времена задержки в таймерах, возник сквозной ток моста и пиротехнические эффекты. Теперь вопрос. Как можно диагностировать наступление такой ситуации и как от нее защитится? Clock Security System был активирован, но не спас (вернее, не спас в этот раз). Как можно мониторить приближение к опасному пределу по помеховой обстановке? В других кристаллах, у которых был вывод аналогового фильтра PLL, его мониторили с помощью АЦП и по спектру делали выводы о приближении к опасному пределу. В STM32 это невозможно- нет вывода фильтра.
Что еще можно реализовать для контроля ПРИБЛИЖЕНИЯ к опасной ситуации?

[shreck]

Неужели clock failure event не помогает выполнить break функцию advanced таймера. Или вы его не задействуете?

[etoja]

ШИМ на силовые ключи нужно подавать через микросхему программируемой логики, например типа CPLD от Altera или Xilinx, которая и устранит такую ситуацию при любом состоянии процессора STM32.

[KnightIgor]

ШИМ на силовые ключи нужно подавать через микросхему программируемой логики, например типа CPLD от Altera или Xilinx, которая и устранит такую ситуацию при любом состоянии процессора STM32.

Совершенно согласен. Микроконтроллеры общего назначения не подходят для прямого и безопасного управления (предположительно) H-мостами, т.к. выходы портов могут принимать самые непредсказуемые значения, поскольку все конфигурируется программно. Необходимо вставлять жесткую логику перед мостами с блокировкой в ней нелицеприятных состояний. Не знаю, о каких напряжениях идет речь, но есть целый ряд HV драйверов (например, от IRF.COM или ST.COM), которые справляются с задачей, внося даже deadtime.

[khach]

Совершенно согласен. Микроконтроллеры общего назначения не подходят для прямого и безопасного управления (предположительно) H-мостами, т.к. выходы портов могут принимать самые непредсказуемые значения, поскольку все конфигурируется программно. Необходимо вставлять жесткую логику перед мостами с блокировкой в ней нелицеприятных состояний. Не знаю, о каких напряжениях идет речь, но есть целый ряд HV драйверов (например, от IRF.COM или ST.COM), которые справляются с задачей, внося даже deadtime.

А кто сказал, что STM32 - общего назначения? Он специально "заточен" под силовое управление, умеет регистрировать случай сбоя системы синхронизации с помощью Clock Security System и переводить (или оставлять) свои выходы в безопасном состоянии.
К слову сказать, описанная авария произошла при тестировании устройства на воздействие помех - брутальным напильником с электрическим разрядом. Со снятой экранировкой модуля процессора. Т.е в очень жестких условиях.
И несколько раз схема CSS вполне штатно выключила источник. Но вот один раз -не повезло. Притом не до конца понятно, что же случилось- дуга сожгла холловские датчики тока и высокое поперло в процессор- лог до конца не записался. Поэтому ищется механизм выключения "на подходе" к аварийной ситуации, а не в ее момент.

[KnightIgor]

А кто сказал, что STM32 - общего назначения? Он специально "заточен" под силовое управление, умеет регистрировать случай сбоя системы синхронизации с помощью Clock Security System и переводить (или оставлять) свои выходы в безопасном состоянии.
К слову сказать, описанная авария произошла при тестировании устройства на воздействие помех - брутальным напильником с электрическим разрядом. Со снятой экранировкой модуля процессора. Т.е в очень жестких условиях.
И несколько раз схема CSS вполне штатно выключила источник. Но вот один раз -не повезло. Притом не до конца понятно, что же случилось- дуга сожгла холловские датчики тока и высокое поперло в процессор- лог до конца не записался. Поэтому ищется механизм выключения "на подходе" к аварийной ситуации, а не в ее момент.

Как бы STM32 не был "заточен", он остается устройством с непредсказуемым поведением (жертва гибкости) и с перепрограммируемой периферией (неопределенность состояний). CSS лишь только сообщает о пропадании внешнего такта, после чего управление передается по немаскируемому вектору. Это если до этого дойдет вообще. Более вероятно, что ядро при воздействии помехи прыгает в никуда, и начинается непредсказуемая котовасия внутри и фейерверк снаружи. Механизм распознавания ситуаций, близких к критическим, предполагает незыблемость исполняемой программы и быстродействие на порядок выше помехи. Поэтому святая вера в "заточенность" микроконтроллера бесполезна, т.к. результат - фейерверк - был достигнут.

Безусловно, включить механизм раннего распознавания критических ситуаций будет полезно. Хотя бы с точки зрения последующего анализа и протокола. И это сработает в 9 случаях из 10. Но я убежден, что существенное повышение надежности возможно лишь привнесением в систему компонентов с меньшей гибкостью и большей предсказуемостью (жесткая логика), что я и предложил ранее.

Сообщение отредактировал KnightIgor - Jan 15 2011, 12:49