1887ВЕ3Т

Модераторы: ea, Alis, pip, gurzzza, _sva_

KonstantinNIITM
Сообщения: 3
Зарегистрирован: 16 июн 2015, 09:45

Re: 1887ВЕ3Т

Сообщение KonstantinNIITM »

Вопрос по работе с прерываниями.
Среда "uVision 4", язык "C"
Когда программа была < 32k и располагалась с адреса 0x0 - проблем с прерываниями не было.
Сейчас программа превышает 32k, я располагаю её во внутренний FLASH с адреса 0x18000 (в регистре SYSCON бит ROMS1=1), таблица векторов прерываний перенесена на адрес 0x18000.
При попадании в обработчик прерывания в этой конфигурации - перестаёт работать JTAG.
Как правильно работать с прерываниями в таком случае?

P.S. Если не работать с прерываниями и не переносить таблицу прерываний, то программа работает.
dvs
Специалист
Сообщения: 86
Зарегистрирован: 03 фев 2011, 15:03
Откуда: Воронеж
Контактная информация:

Re: 1887ВЕ3Т

Сообщение dvs »

KonstantinNIITM писал(а):Вопрос по работе с прерываниями.
Среда "uVision 4", язык "C"
Когда программа была < 32k и располагалась с адреса 0x0 - проблем с прерываниями не было.
Сейчас программа превышает 32k, я располагаю её во внутренний FLASH с адреса 0x18000 (в регистре SYSCON бит ROMS1=1), таблица векторов прерываний перенесена на адрес 0x18000.
При попадании в обработчик прерывания в этой конфигурации - перестаёт работать JTAG.
Как правильно работать с прерываниями в таком случае?

P.S. Если не работать с прерываниями и не переносить таблицу прерываний, то программа работает.
При установке бита SYSCON.ROMS внутренняя память программ будет перемещена из сегмента 0 в сегмент 1 (01`0000h - 01`7FFFh). В это же пространство перемещается и таблица векторов прерываний.
dvs
Специалист
Сообщения: 86
Зарегистрирован: 03 фев 2011, 15:03
Откуда: Воронеж
Контактная информация:

Re: 1887ВЕ3Т

Сообщение dvs »

Если объем программы превышает 32к, то переносить память не обязательно, линкер сам должен разместить программу по адресам внутреннего ПЗУ, разбив ее на две части - одна будет размещена в сегменте 0 по адресам 00`0000h - 00`7FFFh, а оставшаяся часть во второй области ПЗУ по адресам 01`8000h - 04`FFFFh.
Если у Вас есть вопросы, пришлите их на ящик wex собака niiet точка ru
yrk
Сообщения: 12
Зарегистрирован: 05 май 2014, 13:47

Re: 1887ВЕ3Т

Сообщение yrk »

Если объем программы превышает 32к, то переносить память не обязательно, линкер сам должен разместить программу по адресам внутреннего ПЗУ, разбив ее на две части - одна будет размещена в сегменте 0 по адресам 00`0000h - 00`7FFFh, а оставшаяся часть во второй области ПЗУ по адресам 01`8000h - 04`FFFFh.
Если у Вас есть вопросы, пришлите их на ящик wex собака niiet точка ru
Согласен. Чтобы компоновщик выполнил эту работу, в среде должны быть прописаны все области внутреннего ПЗУ. Если конфигурация микроконтроллера сделана неудачно, то, возможно, это придется сделать вручную в одном из полей ROM (туда компоновщик разместит код и константы, объявленные как const, а в области RAM он размещает переменные).
А таблица векторов прерываний в любом случае начинается с нуля. Бит ROMS на это не влияет, этот вопрос целиком в ведении компилятора и компоновщика. Бит ROMS выполняет лишь отображение внутренней Flash в то или иное окно адресного пространства. Keil не следит за манипуляциями с этим битом. В случае, если в настройках проекта Keil указать ненулевой адрес, то по этому адресу, конечно, будет создана таблица, в нее будут занесены все истинные JMPS на обработчики прерывания. Но обработчики прерываний имеют стандартные вектора, указанные в документации (у каждой периферии свой), и эти вектора указывают на таблицу, начинающуюся с нуля. Программист в случае переноса таблицы ОБЯЗАН побеспокоится как именно программа попадет в перенесенную таблицу прерываний, потому что аппаратно переход будет выполнен на нулевую таблицу. Побеспокоиться - это значит прошить заранее в память таблицу, начинающуюся с нуля, куда будут занесены переходы на Вашу новую таблицу. Допустим, Вы разместили таблицу по адресу 0х18000, тогда по адресу 0х0 должен быть JMPS 01H, 08000H. И так далее. Такой двойной прыжок перешел по наследству из предыдущих версий Keil, когда монитор-отладчик MON166 прошивался в ПЗУ вместо того, чтобы загружаться через bootstrap. Этот монитор прописывал всю "настоящую" таблицу прерываний, размещенную с нулевого адреса. Она заполнялась переходами по адресу VECTAB + такое же смещение, за исключением векторов, которые перехватывались. VECTAB - это адрес таблицы прикладной программы. Это позволяло монитору перехватывать управление как по вектору сброса, так и по прерываниям ASC0 и NMI, и одновременно избавляло от необходимости перепрошивать монитор при изменении программы (так как компилятор изменяет лишь дополнительную таблицу и не лезет в истинную).

Но, вообще-то, я зашел на форум с иной целью. Хочу рассказать о своих впечатлениях от АЦП...
Удивительно, но и здесь есть баги, несмотря на то, что это hard-блок от фабрики. Причем баги очень солидные. Прямо диверсия какая-то. Ну, например, режимы сканирования каналов лучше не использовать, есть риск получить непредсказуемое поведение. Сделать изящный вариант с PEC не получилось... жаль. Каналы лучше переключать в "ручном" режиме в обработчике прерывания. Кстати, если кто-то использует сканирование, имейте в виду, баг проявляется случайно, и может стать причиной непонятного поведения системы. Выражается он в том, что цикл обрывается, не закончившись. Выше на форуме уже указывали на эту проблему, говорилось, что виноват бит ADWR. У меня вышло, что и без установки в 1 этого бита беда не уходит.
Дальше. В документации на странице 325 есть таблица времен преобразования. Они почти правильные. Ну то что в последнем столбце перепутаны местами две последние строки сразу понятно, это мелочь. Важнее то, что к указанному времени (это собственно время преобразования) нужно добавить время на обработку результата конечным автоматом - 12 циклов fadc. Например, на частоте fadc = 20МГц, получится не 2,4мкс (48 циклов), как указано, а 3 мкс (60 циклов). Что касается времени выборки (sample time), то, судя по всему, она все-таки есть и установлена на минимум, как если бы поле ADSTC (см. документацию Infineon) было установлено в ноль. Так что следите за выходным сопротивлением источника сигнала. На всякий случай сняли характеристики АЦП. Они успокоили: погрешности такие же, как у инфинеоновских. Кстати, непонятно откуда взят прообраз этой версии АЦП,- это и не С167, и не ХС167, есть режим двойного АЦП (еще руки не дошли проверить в самом деле есть или нет), но это и не кортекс. Так что свойства блока приходится выяснять экспериментально.
Больше всего удивил режим инжектированного преобразования. Какая это была полезная вещь в С167! Но в данной реализации именно оно и подвигло меня потратить вечер на этот пост. Я пока в процессе исследования этого феномена, и не знаю, хватит ли сил и времени дойти до конца, и, главное, хватит ли терпения у Заказчика... Или лучше сразу отказаться и от этого, пользуясь "просто АЦП". Вы думаете, что инжектированное преобразование не работает? А вот и не угадали. Работает. Смущает только два момента:
1) Если Вы не успели прочитать быстренько регистр ADC_DAT2, то есть шанс не узнать номер инжектированного канала, так как он будет перезаписан номером канала стандартного. К счастью, сам результат в поле ADRES остается достоверным! А номер канала и сами знаем, не баре.
2) При старте инжектированного преобразования по завершении преобразования будет выставлен не только флаг завершения инжектированного преобразования, но и стандартного. Так что, если Вы сами переключаете номера каналов в обработчике стандартного преобразования (см. выше), то будьте готовы к очень сложному поведению системы и долгому следствию. Я пока на 100% не установил, происходит действительный запуск стандартного преобразования вместе с инжектированным или это только флаг прерывания выставляется. Но подозреваю, что только флаг. Во-первых, биты ADST и ADC_ADBSY не выставляются, хотя это не аргумент. Но дело в том, что флаги готовности возникают одновременно. А мне не хочется думать, что 2-ой АЦП добавлен в систему специально для того, чтобы параллельно инжектированному преобразованию выполнять непрошенное стандартное. Есть ощущение, что в режиме инжектированного преобразования какие-то мультиплексоры переключаются на аппаратуру, привязанную к регистрам инжектированного преобразования. При этом входы регистров стандартного преобразования брошены плавающими и реагируют на наводки.
noatime
Сообщения: 13
Зарегистрирован: 16 янв 2015, 12:04

Re: 1887ВЕ3Т

Сообщение noatime »

Уважаемые форумчане,

Проблема стирания программы на мк при включении питания меня уже достала, кто-нибудь с этим вплотную сталкивался?
Я уже писал, что если убрать рекомендуемую производителем часть стартапа, то стирание не происходит, но похоже, что я сильно ошибался (но при этом частота отказов уменьшается) и проблема кроется в чем-то другом.

В общем описываю ситуацию:
В программу была добавлена инициализация порта P6 в режиме открытого стока, после чего почти при каждом включении либо очищался (заполнялся 0хFF), либо заполнялся какой-то кашей сектор с началом по адресу 0х0, понятно, что после такого МК становится нерабочий. Более того, когда я решил осциллографом посмотреть импульсы сброса от внешнего супервизора (вход RSTIN), при касании щупом данного вывода происходили случайные зависания и сбросы мк :shock:
После того, как я удалил инициализацию порта P6, все заработало без проблем, в том числе и с осциллографом.
Раз происходит повреждение сектора 0х0 - 0х7F, то я решил дополнить программу функцией проверки данного сектора и в случае повреждения функцией восстановления из копии по адресу 0х24F00, применив немного фантазии удалось сделать так, чтобы эта функция запускалась при каждом старте, даже если нету векторов прерываний в секторе 0х0. Все работало хорошо, пока после одного сбоя не стерся сектор, в котором находилась сама проверка :shock:

В общем, это я к тому, что
СТАВЛЮ БУТЫЛКУ КОНЬЯКА ТОМУ, КТО СМОЖЕТ ОБЪЯСНИТЬ КАКОГО ЧЕРТА ПРОИСХОДИТ И КАКОЙ МЕХАНИЗМ У ДАННОГО СБОЯ!!!

Еще бы хотелось, чтобы Изготовитель выложил результаты испытаний по сбоям МК в зависимости от фаз Луны.
dvs
Специалист
Сообщения: 86
Зарегистрирован: 03 фев 2011, 15:03
Откуда: Воронеж
Контактная информация:

Re: 1887ВЕ3Т

Сообщение dvs »

noatime писал(а):Уважаемые форумчане,

Проблема стирания программы на мк при включении питания меня уже достала, кто-нибудь с этим вплотную сталкивался?
Я уже писал, что если убрать рекомендуемую производителем часть стартапа, то стирание не происходит, но похоже, что я сильно ошибался (но при этом частота отказов уменьшается) и проблема кроется в чем-то другом.

В общем описываю ситуацию:
В программу была добавлена инициализация порта P6 в режиме открытого стока, после чего почти при каждом включении либо очищался (заполнялся 0хFF), либо заполнялся какой-то кашей сектор с началом по адресу 0х0, понятно, что после такого МК становится нерабочий. Более того, когда я решил осциллографом посмотреть импульсы сброса от внешнего супервизора (вход RSTIN), при касании щупом данного вывода происходили случайные зависания и сбросы мк :shock:
После того, как я удалил инициализацию порта P6, все заработало без проблем, в том числе и с осциллографом.
Раз происходит повреждение сектора 0х0 - 0х7F, то я решил дополнить программу функцией проверки данного сектора и в случае повреждения функцией восстановления из копии по адресу 0х24F00, применив немного фантазии удалось сделать так, чтобы эта функция запускалась при каждом старте, даже если нету векторов прерываний в секторе 0х0. Все работало хорошо, пока после одного сбоя не стерся сектор, в котором находилась сама проверка :shock:

В общем, это я к тому, что
СТАВЛЮ БУТЫЛКУ КОНЬЯКА ТОМУ, КТО СМОЖЕТ ОБЪЯСНИТЬ КАКОГО ЧЕРТА ПРОИСХОДИТ И КАКОЙ МЕХАНИЗМ У ДАННОГО СБОЯ!!!

Еще бы хотелось, чтобы Изготовитель выложил результаты испытаний по сбоям МК в зависимости от фаз Луны.
Уважаемый потребитель изделия 1887ВЕ3Т!
Для решения Вашей проблемы (отмечу, крайне редкой настолько, что она встретилась только Вам, а мы, к сожалению, не смогли воспроизвести ее на своей отладочной плате) просим предоставить нам следующие сведения:
1. Схему устройства. Если это отладочная плата производства НИИЭТ, то укажите, пожалуйста что это она.
2. Предоставьте программу, при исполнении которой возникает проблема. Если программа не может быть предоставлена из-за соображений секретности, то сократите ее до минимума, при которой проблема сохраняется и отправьте ее нам.
3. Укажите отладочную среду, используемую при работе с контроллером. Если это Keil, то сообщите, как Вы осуществляете ее настройку и вышлите проект, на котором наблюдается данная проблема.
4. Какое оборудование и программное обеспечение Вы используете для прошивки программы во внутреннюю память микроконтроллера. Если Вы используете адаптер производства НИИЭТ, то сообщите номер версии ПО адаптера (указан на наклейке, размещенной на плате адаптера)
5. Укажите начальную конфигурацию МК во время эксперимента.
6. Передайте прочие сведения (осциллограммы, напряжения, уровни и т.д.), которые могут помочь разобраться в сложившейся ситуации.

Для более быстрой и удобной работы отправьте, пожалуйста, все необходимые сведения на ящик wex собака niiet.ru.

Если Вы находитесь недалеко от Воронежа, то проблема может быть решена в более короткие сроки если Вы посетите НИИЭТ лично (с Вашим оборудованием: платой, адаптером и ПО), либо при выезде наших специалистов на Ваше предприятие.

В случае успешного решения проблемы коньяк оставьте себе.
Фазы луны на функционировании МК никак не отражаются, даже если эксплуатировать с открытой крышкой на корпусе и падающим на открытый кристалл светом полной луны.
Denis
Сообщения: 32
Зарегистрирован: 16 май 2013, 22:01

FIXDMU

Сообщение Denis »

Вопрос к разработчикам. Заметил, что функция с умножением и делением глючит при наличии прерывании. Поставил #pragma FIXDMU - глючить перестала. Прокомментируйте пожалуйста.
yrk
Сообщения: 12
Зарегистрирован: 05 май 2014, 13:47

Re: 1887ВЕ3Т

Сообщение yrk »

Так и не закрыл вопрос по нестабильному старту 1887ВЕ3Т. Очень многие факторы влияют на сброс: и скорость нарастания питания, и номиналы в RC-цепи на RSTIN, применяется внешний генератор или кварц...поведение сильно разнится. Причем без видимой логики. Например, получаешь стабильный старт по кнопке RESET, но не будет включаться при подаче питания, или наоборот - включается при подаче, но не всегда перезапускается по кнопке. В лучшем случае удавалось добиться, что контроллер не стартует при каждом 50-ом 100-ом сбросе. Может проблема в том, что у меня одна из ранних ревизий МК? Обнаружил, что если питание 5В медленно поднять до ~0.8В, то МК уже не входит в состояние сброса (на входах конфигурации не включается подтяжка), даже если потом до номинала 5В напряжение вырастает быстро (за пару миллисекунд). Не удалось добиться от производителя цифр об уровне на входе RSTIN, при котором МК должен выходить из состояния сброса (у меня по факту этот уровень крайне низок, что, возможно, и является причиной нестабильности). Также не понятны требования к источнику (скорость нарастания питания), если они есть. Странно, что при уже установившемся питании при подаче импульса на RSTIN длительностью 10мс и более МК не всегда удачно перезапускается. Не перезапускается - значит не выбирает ни одной инструкции. Это легко проверить, сделав EINIT первой инструкцией в коде. Выход RSTOUT должен перейти в лог.1, чего не происходит. Иногда казалось, что проблема решена, но она возвращается снова и снова (уже на 2-ом опытном образце; оба МК из одной партии) . Были подозрения на входы конфигурации, подтягивающие резисторы 10кОм были заменены на 7к5 (в документации на инфинеоновские МК указывалось не более 8к2). Уровень на конфигурационном входе, который подтягивается вниз, упал до 0,5В непосредственно перед выходом из режима конфигурации, но это не помогло. Были подозрения на вход в режим ADAPT, но и этот вариант отпал. Применение внешнего триггера Шмидта после RC-цепи, когда на вход RSTIN подается резкий фронт в момент, когда питание уже стабильно, заметно улучшает ситуацию, но не решает ее полностью. Совсем редко возникала ситуация, когда МК запускался с видимой задержкой (в пару секунд). Возможно, это рестарт от сторожевого таймера, который, кстати по умолчанию должен быть включен, но при неудачном старте обычно тоже не запускается, а может быть это связано с тем, что старт происходит не с нулевого адреса: МК делает круг и возвращается к нулю. Я теряюсь в догадках. Ответ от производителя был, если коротко, такой: "Вот на нашей макетной плате все работает". Возможно, но в момент, когда я получил бесплатные "образцы", ваша плата еще не была готова. Кроме того, я не могу использовать вашу плату в своем проекте. Схема сброса крайне проста. Где там могут быть ошибки? Я применял довольно большое количество МК, в том числе С167 и ХС167. И ни разу никаких проблем со стартом не было. Обращаюсь к форумчанам: не замечал ли кто, что МК иногда не стартует? Если да, то как вы обошли эту проблему? Интересно, что около года назад эта тема уже поднималась на форуме, и, отвечая на чужой вопрос, я сказал, что возможно с этой проблемой и мне еще предстоит столкнуться...напророчил.
Denis
Сообщения: 32
Зарегистрирован: 16 май 2013, 22:01

Re: 1887ВЕ3Т

Сообщение Denis »

yrk писал(а):Так и не закрыл вопрос по нестабильному старту 1887ВЕ3Т. Очень многие факторы влияют на сброс: и скорость нарастания питания, и номиналы в RC-цепи на RSTIN, применяется внешний генератор или кварц...поведение сильно разнится. Причем без видимой логики.
У меня тоже была такая проблема (надеюсь, что была). Помогли три шаманских шага:

1. Добавить в начала несколько нопов
2. Отказаться от записи в PLLCON, настройку делителя осуществлять резисторами
3. В цикле опрашивать бит PLLCON.15, пока не станет равным 1.

Если есть возможность - попробуйте, мне интересен результат.

Вот код:

Код: Выделить всё

               nop
               nop
               nop
               nop
               nop
               nop
               DISWDT
pllcheck:
                EXTR    #01H
                jnb PLLCON.15,pllcheck
yrk
Сообщения: 12
Зарегистрирован: 05 май 2014, 13:47

Re: 1887ВЕ3Т

Сообщение yrk »

Denis, спасибо за ответ. Настройку делителя всегда выполняю с помощью внешней конфигурации (резисторов), а добавление чего-либо в код не влияет, так как код вообще не выбирался из памяти. Конечно, если допустить какую-то магию...)))
В настоящий момент, кажется, удалось добиться стабильного старта. Похоже контроллер имеет следующие особенности, которые нужно принимать в расчет при организации схемы сброса, да и вообще всей обвязки. Обращаю внимание, что все, что перечислю ниже, высказываю в качестве предположений. 100% уверенности нет.
1) У МК низкий порог выхода из состояния сброса, поэтому если у вас источник с мягким стартом, то лучше использовать супервизор. Слишком большая постоянная RC - не решает проблему задержки #RSTIN в силу других причин
2) Если при подаче питания, у вас запитывается одновременно обвязка (внешняя логика, ОУ на входах АЦП), и при этом напряжение на внешних входах растет с той же скоростью, что и питание МК... возможны проблемы входа в состояние сброса
3) Если применяете супервизор или внешний триггер Шмидта, следите чтобы на выходе устройства (т.е. входе #RSTIN) уровень при нажатии на кнопку опускался до 0В. Если низкий уровень будет, скажем, 0.5В успех не гарантирован.

Я добивался относительного успеха применяя после RC-цепи инвертор 1564ТЛ2 с триггером Шмидта на входе (так как они оставались свободными на плате), затем сигнал дополнительно инвертировался на близлежащем (тоже свободном) 1564ЛП5, чтобы привести уровень в соответствие логике сброса. Такая схема неплохо работала, но не всегда гарантировала успешный старт. Поэтому я забросил ее, но недавно вынужденно вернулся...сделав лишь одну замену: в качестве второго инвертора применил тоже 1564ТЛ2. Теперь все хорошо. Не знаю надолго ли, но осциллограф говорит о разнице между двумя ситуациями: при подаче питания в силу особенностей 1564ЛП5 и 1564ТЛ2 их выходы, когда питание еще мало, ведут себя по-разному. Во втором случае #RSTIN дольше удерживается на 0В (<0.5В) перед тем, как начать расти вместе с питанием, когда питание вырастает до нормы серии 1564, формируется полноценный сигнал сброса...лучше один раз увидеть. Сейчас попробую приложить осциллограмму...так, bmp запрещено администратором...сейчас сконвертирую:
Старт МК с двумя ТЛ2 на входе #RSTIN
Старт МК с двумя ТЛ2 на входе #RSTIN
Старт МК.JPG (40.1 КБ) 6395 просмотров
Желтый - питание 5В, голубой #RSTIN после двух инверторов 1564ТЛ2. Вы, конечно, обратили внимание на тот факт, что питание растет не от нуля, а на #RSTIN все равно ноль. В этом отличие от варианта с 1564ЛП5. Почему растет не от нуля? Такая ситуация смоделирована нарочно. Она, например, может возникнуть если ваше устройство запитывается после подачи питания на другие изделия системы в целом (например, если вы в сети, по которой идут сообщения, и гальванически не изолированы от нее, то маленький плюс может прийти через ножку питания драйвера этой сети). И тогда через соединительные кабели в линию питания может приползти небольшой потенциал (до 0,8В). С этой проблемой обычно борются диодами (хотя не всегда успешно), сухими контактами реле и пр. Но часто это нежелательно увеличивает габариты и массу. Короче говоря, стартовать этот МК нужно так, чтобы сигнал на входе #RSTIN поднимался точно от 0В. Причина, думаю, кроется в низком пороге. Непонятным остается тот факт, что после того, как питание выросло, в случае с ЛП5 тоже формируется импульс сброса как на картинке, но он уже не спасает. Т.е. в МК что-то "залипает".
Прикреплю также картинку старта стандартной схемы сброса...
Стандартная схема.JPG
Стандартная схема.JPG (36.01 КБ) 6395 просмотров
Здесь желтый и голубой имеют тот же смысл (на вход #RSTIN подается сигнал непосредственно с RC-цепи). Фиолетовый цвет - вход конфигурации, который тянется вниз через 7к5. Видны моменты, когда подтяжка включается и выключается (это происходит, когда на #RSTIN 0,88В и 1,2В). На второй картинке также смоделирована ситуация старта не от нуля (подпор питания через сигнальные линии блока).
Надеюсь это кому-нибудь поможет
Ответить

Вернуться в «16-разрядные RISC микроконтроллеры»