У меня проблема с использованием программного сторожевого таймера на процессоре MPC875:
Таймер запускает сигнал сброса ОЧЕНЬ быстро: у меня меньше половины секунды между включением таймера и получением сигнала сброса, хотя я установил значение обратного отсчета (SWTC) на максимум с включенным предварительным масштабированием.
Вот как я это делаю (сценарий JTAG):
CF TAR 875
CF GRP 400F
INN
SR PLPRCRK 0x55CCAA33
SR PLPRCR 0x1A4D5000 ; Configure Phase-Lock Loop
SR SCCRK 0x55CCAA33
SR SCCR 0xF47F0002 ; Configure System Clock
SR SYPCR 0xFFFFFF87 ; Enable the Software Watchdog Timer
SR SWSR 0x556c ; Reset the timer
SR SWSR 0xaa39
SR SWSR 0x556c
SR SWSR 0xaa39
SR SWSR 0x556c
SR SWSR 0xaa39
SR SWSR 0x556c
SR SWSR 0xaa39
SR SWSR 0x556c
SR SWSR 0xaa39
SR SWSR 0x556c
SR SWSR 0xaa39
SR SWSR 0x556c
SR SWSR 0xaa39 ; The HRESET issued after few moments from this point
При включенном предварительном масштабировании (бит SWP в SYPCR) он устанавливает сигнал HRESET примерно через полсекунды после последнего сброса счетчика (последняя команда SR SWSR). И если я отключу предварительный делитель, сигнал HRESET будет выдан еще до первой модификации регистра SWSR (очень короткое время). Таким образом, кажется, что таймер каким-то образом реагирует на изменения настроек, но что-то не так с таймингом.
Системные часы и цикл фазовой синхронизации должны быть настроены правильно, потому что мы получаем такую же конфигурацию в уже установленном и работающем приложении (поверх VxWorks), но с выключенным сторожевым таймером.
Также я попытался очистить бит SWF в регистре SYPCR, чтобы предотвратить подсчет таймера, пока JTAG остановил процессор (путем подтверждения сигнала FRZ): тогда он работает только до тех пор, пока я не выйду из режима прерывания / пошагового режима, когда я запускаю приложение, сброс происходит в очень короткое время.
Согласно справочному руководству таймер работает следующим образом:
Имеется обратный счетчик, когда он достигает нуля, схема устанавливает сигнал HRESET или вызывает прерывание сброса системы. Счетчик имеет длину два байта и может быть предварительно масштабирован с коэффициентом 2048. Он уменьшается со скоростью, равной системным часам, деленным на 2048. Таким образом, ожидаемое время ожидания с включенным предварительным делителем и максимальным значением счетчика составляет 1 / (80MHz / 2048) * (65535 * 2048), что составляет примерно 3435 секунд. С отключенным предварительным делителем это должно быть около 1,7 секунды. Фактические значения намного меньше: около 0,5 секунды с предварительно масштабированным счетчиком и намного меньше (даже невозможно измерить) с выключенным предварительным масштабированием.
Согласно диаграмме SWT зависит только от Core Clock и регистра SYPCR, вот описание регистра:
Я установил значение 0xFFFFFF87 (на самом деле пробовал разные варианты), что означает:
- SWTC: 0xFFFF (счетчик таймера, максимальное значение загружается во внутренний счетчик с обратным отсчетом (см. Диаграмму) при записи магической последовательности в регистр SWSR).
- BMT: 0XFF (счетчик таймера монитора шины, максимальное значение)
- BME: 1 (Bus Monitor включен, и нет смысла выключать бит, потому что он всегда включен с JTAG, независимо от настроенного значения).
- SWF: 0 (таймер считает, даже когда JTAG устанавливает сигнал FRZ).
- SWE: 1 (сторожевой таймер включен).
- SWRI: 1 (настроен для подтверждения HRESET, переключение на NMI не помогло).
- SWP: 1 (SWTC предварительно масштабируется с коэффициентом 2048).
Какие-либо предложения?
