Я собственно это и делаю специальными макросамиDenis писал(а):Если нужно обрабатывать ошибки шины, то можно, наверно, налету XADRS1 перемапить.
1887ВЕ3Т
Модераторы: ea, Alis, pip, gurzzza, _sva_
Re: 1887ВЕ3Т
Re: 1887ВЕ3Т
CAN контроллер на 20МГц работает нестабильно. Снизил до 16 - нормально. Проявляется в том, что на внешних выводах нет сигналов, хотя регистры пишутся и читаются. Причем, если заработало после старта, то уже работает. Если сразу не запустился, то и не включится.
Но более важен другой момент. Есть подозрения на "странное" поведение XBUS. Крайне нежелательно делать запись в регистры по этой шины два раза и более подряд (двумя последовательными инструкциями). Результат может быть странным. Регистры пишутся, но что-то блокируется в конечном автомате CAN что ли? При этом не важно куда именно происходит запись: в CAN или CCU6. Пошаговая отладка "спасает" ситуацию, видимо благодаря вносимым задержкам. Запуск программы в обычном режиме блокирует CAN. Причем пошаговый проход важен только для тех мест, где есть много обращений к регистрам подряд. Когда пишешь на С, это неудобно, поскольку приходится управлять компилятором. Я добился устойчивой работы (ну пока во всяком случае), перейдя на уровень оптимизации ниже 6-го (constant propagation). Так как "распространение констант" ведет к циклам записи в регистры подряд.
Но более важен другой момент. Есть подозрения на "странное" поведение XBUS. Крайне нежелательно делать запись в регистры по этой шины два раза и более подряд (двумя последовательными инструкциями). Результат может быть странным. Регистры пишутся, но что-то блокируется в конечном автомате CAN что ли? При этом не важно куда именно происходит запись: в CAN или CCU6. Пошаговая отладка "спасает" ситуацию, видимо благодаря вносимым задержкам. Запуск программы в обычном режиме блокирует CAN. Причем пошаговый проход важен только для тех мест, где есть много обращений к регистрам подряд. Когда пишешь на С, это неудобно, поскольку приходится управлять компилятором. Я добился устойчивой работы (ну пока во всяком случае), перейдя на уровень оптимизации ниже 6-го (constant propagation). Так как "распространение констант" ведет к циклам записи в регистры подряд.
Re: 1887ВЕ3Т
У меня тоже были проблемы. CAN было дело не запускался, но я связал это с тем, что инициализация проходила после инструкции EINIT - хоть это и непонятно, но на фоне остального несущественно, я просто перенес вызов инициализации и вроде пока проблем не было.YRK писал(а):CAN контроллер на 20МГц работает нестабильно. Снизил до 16 - нормально. Проявляется в том, что на внешних выводах нет сигналов, хотя регистры пишутся и читаются. Причем, если заработало после старта, то уже работает. Если сразу не запустился, то и не включится.
Но более важен другой момент. Есть подозрения на "странное" поведение XBUS. Крайне нежелательно делать запись в регистры по этой шины два раза и более подряд (двумя последовательными инструкциями). Результат может быть странным. Регистры пишутся, но что-то блокируется в конечном автомате CAN что ли? При этом не важно куда именно происходит запись: в CAN или CCU6. Пошаговая отладка "спасает" ситуацию, видимо благодаря вносимым задержкам. Запуск программы в обычном режиме блокирует CAN. Причем пошаговый проход важен только для тех мест, где есть много обращений к регистрам подряд. Когда пишешь на С, это неудобно, поскольку приходится управлять компилятором. Я добился устойчивой работы (ну пока во всяком случае), перейдя на уровень оптимизации ниже 6-го (constant propagation). Так как "распространение констант" ведет к циклам записи в регистры подряд.
Поставил XBCON4 = 4BDh и все работало два дня, по крайней мере передача по CAN шла и синус на выходе CAPCOM6 был. При XBCON4 = 4BEh вскоре затыкается, при XBCON4 = 4BFh затыкается сразу. Уровень оптимизации - 7, восьмой не ставлю принципиально - кейл в этом случае был неоднократно пойман на руку.
Re: 1887ВЕ3Т
Я уже писал на форум, но ответа так и не получил, может все-таки кто-нибудь что-то подскажет?
Обнаружилась проблема с МОП для контроллера: при отключенном jtag, контроллер не стартует сразу по включению питания платы, а только после нажатия кнопки reset, более того на части контроллеров происходит повреждение внутренней памяти, после чего программу надо прошивать заново. Могут ли разработчики как-нибудь это прокомментировать?
И существует ли способ прошить чистый контроллер без внешней памяти? А то получается, что в случае сбоя в конечном изделии, единственный вариант восстановить работоспособность - выпаять контроллер, поставить его на плату с внешней флешкой, записать программу и потом запаять обратно.
Обнаружилась проблема с МОП для контроллера: при отключенном jtag, контроллер не стартует сразу по включению питания платы, а только после нажатия кнопки reset, более того на части контроллеров происходит повреждение внутренней памяти, после чего программу надо прошивать заново. Могут ли разработчики как-нибудь это прокомментировать?
И существует ли способ прошить чистый контроллер без внешней памяти? А то получается, что в случае сбоя в конечном изделии, единственный вариант восстановить работоспособность - выпаять контроллер, поставить его на плату с внешней флешкой, записать программу и потом запаять обратно.
Re: 1887ВЕ3Т
Как я понял шить можно через OCDS, FlashWriter-ом подключив выводы OCDS блока контроллера к соответствующим выводам LPT порта, как в этой теме -> viewtopic.php?f=8&t=115. И шить можно без внешней флешки, если я не ошибаюсь(сам ещё не пробовал, хотя тоже волнует этот вопрос). Проблема в том, что LPT нужен нативный, который днём с огнём не найти уже, всякие USB->LPT не катят. И работает это раз через пять.
Re: 1887ВЕ3Т
Можем дать программку(на стадии тестирования) для программирования контроллера через COM-порт.
Но для этого нужно спаять адаптер на ATTINY2313(для него же можно использовать переходник USBtoCOM).
Напишите куда выслать(если интересно).
Но для этого нужно спаять адаптер на ATTINY2313(для него же можно использовать переходник USBtoCOM).
Напишите куда выслать(если интересно).
Re: 1887ВЕ3Т
Подскажите, в чём может быть проблема.
Подключил порт OCDS к LPT. Смотрю осциллографом, есть импульсы на TDI/TDO/TCK и ТМС. Но Flash Writer выдаёт "Превышено время ожидания бита IO_SUPERVISOR", на попытки стереть или записать данные во FLASH. При это работает чтение блока(но с той же ошибкой в логе), читает нули по всем адресам.
Tester OCDS выдает следующее
Подключил порт OCDS к LPT. Смотрю осциллографом, есть импульсы на TDI/TDO/TCK и ТМС. Но Flash Writer выдаёт "Превышено время ожидания бита IO_SUPERVISOR", на попытки стереть или записать данные во FLASH. При это работает чтение блока(но с той же ошибкой в логе), читает нули по всем адресам.
Tester OCDS выдает следующее
В чём может быть проблема?Тест №1:
Инициализация отладочной системы OCDS...
>>>>>Превышено время ожидания стартового бита при команде IO_SUPERVISOR
Ошибка инициализации Supervisor
0xFF12 0000
Re: 1887ВЕ3Т
Для этого потребуется наличие какой-то специальной прошивки (загрузчика) на ВЕ3? А можете FlashWriter для lpt выложить, а то в соседней теме по ссылкам битые архивыSanek писал(а):Можем дать программку(на стадии тестирования) для программирования контроллера через COM-порт.
Но для этого нужно спаять адаптер на ATTINY2313(для него же можно использовать переходник USBtoCOM).
Напишите куда выслать(если интересно).
Re: 1887ВЕ3Т
Да, есть такой способ через среду Keil. И я указывал на него разработчикам. Странно, что они молчат. Мы тогда долго переписывались. Я составил себе целую папку рекомендаций по работе с ВЕ3Т, включая текстовый файл с порядком установки Keil и т.п. Возможно, Вы для себя что-то там найдете. Могу выслать, не жалко. Вот надо было еще себе errata тоже составить, а то уже некоторые тонкости применения ВЕ3Т забываются . Особенно CAPCOM6 "порадовал" в этом смысле: "половинная" генерация deadtime, некорректная теневая пересылка, и запрет на ноль в регистре скважности. Если что, пишите на rubish собака pochta.runoatime писал(а):Я уже писал на форум, но ответа так и не получил, может все-таки кто-нибудь что-то подскажет?
Обнаружилась проблема с МОП для контроллера: при отключенном jtag, контроллер не стартует сразу по включению питания платы, а только после нажатия кнопки reset, более того на части контроллеров происходит повреждение внутренней памяти, после чего программу надо прошивать заново. Могут ли разработчики как-нибудь это прокомментировать?
И существует ли способ прошить чистый контроллер без внешней памяти? А то получается, что в случае сбоя в конечном изделии, единственный вариант восстановить работоспособность - выпаять контроллер, поставить его на плату с внешней флешкой, записать программу и потом запаять обратно.
По поводу старта контроллера. У меня тоже такие подозрения были, и перепрошивать приходилось. Но с уверенностью сказать, что проблема в ВЕ3Т не могу. Со 100% вероятностью пойман не был. Я обычно сначала сам себе очень долго доказываю, что проблема в МК, а не, например, в обвязке. У меня пока всё в стадии отладки, то есть плата лежит на столе, и нажать reset мне не трудно. После включения источника действительно часто не стартует, но перепрошивать приходилось раза три в самом начале работы, потом как-то прошло (возможно из-за того, что отлаживаю из ОЗУ, а в ПЗУ сидит постоянно небольшой код). Возможно проблема в медленном источнике (плавный пуск и т.п.). Если Вы используете ВИП от Александр-Электрик, так они обладают кучей недостатков. Например, при включении могут включаться и выключаться несколько раз. Мы от них отказались в пользу Ирбис с ВП. Возможно, стоит подумать в сторону полноценного супервизора питания? В общем, это я к тому, что эта проблема, возможно, встанет остро для меня в будущем. Так что если что разузнаете, дайте и мне знать, договорились?
Re: 1887ВЕ3Т
Только добрался до форума, жаль не увидел сообщение раньше:) пару дней потратил на поиск решения и нашел, интересно такое же или нет.YRK писал(а): Да, есть такой способ через среду Keil. И я указывал на него разработчикам. Странно, что они молчат.
В общем, проблема перепрошивки чистого контроллера без внешнего ПЗУ решается так:
1. В Keil открываем Target options
2. Открываем вкладку utilities
3. В качестве файла инициализации выбираем тот, что прикреплен к сообщению
4. Все! Контроллер шьется без проблем.
Данный файл инициализации перед тем как запустить операцию загрузки прошивки сперва стирает полностью сектор с началом в адресе 0х0, затем туда прописывает две команды: отключение сторожевика и прыжок по адресу 0хFA40. Таким образом контроллер может запустить процедуру прошивки.
По поводу затерания программы я заметил, что это проявляется не с любой программой и не у каждого контроллера, так что баг, видимо, программно-аппаратный, но больше пока так ничего и не выяснил.
По поводу обмена errata - хорошая идея, собираюсь в ближайшее время составить документ с описанием всех проблем и особенностей, с которыми пришлось столкнуться, как составлю можно будет обменяться.
Смотрю, много народу столкнулось с проблемами блока CAN, я уже использовал его в нескольких проектах и сталкивался с подобными проблемами пока не нашел рабочую конфигурацию: тактовая частота МК - 40 МГц (коэффициент PLL x2), инициализируются ВСЕГДА оба узла CAN, если второй узел не нужен, то его можно подключить на внутреннюю шину, запись данных в поле сообщения ВСЕГДА производится с помощью ассемблерной вставки вида
Код: Выделить всё
__asm{
mov R10, #данные
mov R11, #адрес_поля
mov [R11], R10
}
Надеюсь, моя информация будет кому-то полезна.
- Вложения
-
- restore_startup.ini
- (795 байт) 178 скачиваний