Отправлено DP 31 мая 2004 г. 14:10

Цитата из "PIC18FXX8 Rev. B4 Silicon/Data Sheet Errata":
""""""""""""""""""""""""""""""""""""""""""""""""""
Under certain conditions, the execution of some
control operations may yield unexpected results.
This has been observed when the following
instructions vector code execution across the
4000h program memory address boundary:
• CALL
• GOTO
• RETURN
• RETLW
• RETFIE
There are no known issues related to any of these
instructions when execution occurs strictly above
or below the 4000h address boundary.
Work around:
Two possible solutions are presented. Others may
exist. It is recommended to implement either or
both as needed.
1. Insert a data word of value FFFFh as the first
instruction in the destination of a CALL or GOTO.
2. Insert a data word of value FFFFh immediately
following any RETURN, RETLW, or RETFIE
instruction.
In either case, the literal data behaves as a NOP
instruction when executed. Using the actual NOP
instruction instead of a literal FFFFh may not have
the same results.
""""""""""""""""""""""""""""""""""""""""""""""""""""
Краткий перевод сути:
Если переход совершается с пересечением границы 4000h,
то есть вероятность не попасть в точку назначения
"при определённых условиях".
Чтобы увеличить вероятность попадания рекомендуется
расширять точку назначения вставлением туда лишнего NOP,
но не абы какого, а 0xFFFF.

Практический опыт:
Версия компилятора - 8.30.
Тип процессора - 258/458.
Программа состоит из двух частей:
- Kernel. Находится в младших адресах. Точки входа векторов прерываний
перенаправлены с помощью goto.
- Application. Загружается Kerneloм в верхние адреса.

Пока всё это работало на 16 МГц не было никаких проблем.
Затем перевели на 32 МГц - работать перестало.
Расследование привело к выводу, что это происходило потому что
забыли вставить этот самый 0xFFFF перед goto, который перенаправлял
вектора прерываний.
При этом пролёт точки входа в прерывание наблюдался даже в пошаговом
прохождении под эмулятором ICD2.
Кстати в erratе явно не упомянуто, что вектор прерывания тоже своего рода goto.
После вставки 0xFFFF всё заработало лучше прежнего.

Из чего можно сделать вывод:
"При определённых условиях" может означать повышенную тактовую частоту.
Т.е. другими словами, если переход совершается далеко и быстро,
то попасть в точку назначения проблематично. :).

После этого решили посмотреть, что же делает в точках векторов
прерываний компилятор, который постоянно успокаивает нас фразой:
"Errata for 18F458 Rev B4 issues 4 & 5 applied".
Оказывается - ничего!
При этом часть девайсов работает нормально, часть - глючат раз в час,
а попадаются экземпляры которым данная ситуация конкретно не нравится.

В качестве workaround предлагается вставлять такой кусок перед функцией обработчика прерываний:

#ifdef HI_TECH_C
#asm
psect intcodelo // или intcode (для высокоприоритетного вектора)
dw 65535
#endasm
#endif

И смотреть при этом что получилось.

• "Заработало лучше прежнего" - это как ? Точность повысилась или скорострельность ? :-) — Крок   (31.05.2004 19:29, пустое)
• 16 мгц и 32 мгц это c PLL или DirectClock? — Romario   (31.05.2004 14:35, пустое)
  • 16 - Direct, 32 - из 8-ми через PLL. Но, похоже, это без разницы, хотя надо будет проверить. — DP   (31.05.2004 16:04, пустое)