реклама на сайте
подробности

 
 
3 страниц V   1 2 3 >  
Reply to this topicStart new topic
> АЦП LPC1758 (недопустимое значение регистра ADTRIM)
jcxz
сообщение Jun 28 2016, 03:31
Сообщение #1


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Столкнулся с проблемой с АЦП в давно выпускаемом устройстве на LPC1758.
Модифицировали прошивку и перестало работать АЦП - выдаёт всё время 0xFFF (АЦП 12-битный).
Заливаешь старую прошивку - АЦП работает, значения меняются, новую - не работает.
Код инициализирующий периферию (ноги, PLL, другие порты и т.п.) - в новой прошивке абсолютно без изменений, код работающий с АЦП - тоже старый (файлы исходников байт-в-байт одинаковы).
После разборок выяснилось, что при старте ПО содержимое регистра ADTRIM разное: при старте старой прошивки там как и указано в даташите ==0xF00, при старте новой прошивки там почему то ==0.
Т.е.: ставлю процедуру инициализации АЦП в ассемблерный стартап-файл, третьей командой (первые две - запреты прерываний), в этой процедуре включаю тактирование АЦП и сразу считываю регистр ADTRIM - и вижу что в старой прошивке там опять как должно быть ==0xF00, а в новой =0. wacko.gif
Про этот регистр в даташите говорится, что он записывается boot-кодом и после записи калибровочных значений в младшие 8 бит, boot-код должен в биты 8-11 записать единицы, заблокировав тем самым модификацию этого регистра.
Получается, что boot-код каким-то образом определяет какая прошивка (старая версия или новая) и записывает или не записывает туда эти единицы в биты 8-11. wacko.gif
Много раз перешивал то старую прошивку, то новую (и размер их сделал одинаковыми на всякий случай) - после каждой перепрошивки в ADTRIM было 0xF00 для старой и 0 - для новой.
Бред какой-то!!!
Если при старте устройства, обнаружив что в битах 8-11 нули, записать туда единички (что должен делать boot-код), то АЦП начинает работать нормально.
Даташиты и ерраты все перерыл - на этот счёт там тишина.
Пока сделал костыль: если в битах 8-11 нули - пишу туда сам при старте ПО единицы. Но не понятно что писать в биты 0-7 (там калибровочные значения). И непонятно что будет дальше в других экземплярах МК?

Кто-нибудь сталкивался с этой проблемой?
Go to the top of the page
 
+Quote Post
ViKo
сообщение Jun 28 2016, 05:28
Сообщение #2


Универсальный солдатик
******

Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362



Может быть, вы не выдерживаете какие-то времена, прежде чем обращаться к АЦП? Тстартап, или что там есть у NXP... В спецификации нужно посмотреть.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 28 2016, 05:53
Сообщение #3


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(ViKo @ Jun 28 2016, 11:28) *
Может быть, вы не выдерживаете какие-то времена, прежде чем обращаться к АЦП? Тстартап, или что там есть у NXP... В спецификации нужно посмотреть.

Про этот регистр не указаны никакие времена. Всё, что про него написано в даташите:
This register will be set by the bootcode on start-up. It contains the trim values for the DAC
and the ADC. The offset trim values for the ADC can be overwritten by the user. All 12 bits
are visible when this register is read.

Как я понимаю - это просто конфигурационный регистр, к которому можно получить доступ как только включено тактирование периферии ADC.
К тому же я написал уже:
Вставил один и тот же код инициализации АЦП в одно и то же место исходников (в самом начале асм-стартапа, через две команды от вектора сброса) старого и нового. В старом ПО - считывает правильные значения (и содержимое ADTRIM == 0xF00), в новом ПО - считывает всё время 0xFFF (и содержимое ADTRIM = 0). Повторил опыт много раз, перезапуская, пересбрасывая питание, перешил несколько раз ПО туда и обратно....
Go to the top of the page
 
+Quote Post
Alechek
сообщение Jun 28 2016, 06:11
Сообщение #4


Профессионал
*****

Группа: Свой
Сообщений: 1 241
Регистрация: 15-11-05
Из: Челябинск
Пользователь №: 10 882



Значит, запукать дебагер с брякой на запись даных по адресу ADTRIM.
Возможно, кто-то пишет туда нечаянно.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 28 2016, 06:45
Сообщение #5


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Alechek @ Jun 28 2016, 12:11) *
Значит, запукать дебагер с брякой на запись даных по адресу ADTRIM.
Возможно, кто-то пишет туда нечаянно.

Предлагаете bootcode отлаживать? А смысл? Он и должен писать.
Go to the top of the page
 
+Quote Post
ViKo
сообщение Jun 28 2016, 08:02
Сообщение #6


Универсальный солдатик
******

Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362



У STM есть datasheet, в нем все времена описаны. Где искать у NXP, не знаю. Где-то есть. Предлагаю удостовериться, что все в пределах нормы. Перенесите инициализацию на позже...
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 28 2016, 08:18
Сообщение #7


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(ViKo @ Jun 28 2016, 14:02) *
У STM есть datasheet, в нем все времена описаны. Где искать у NXP, не знаю. Где-то есть. Предлагаю удостовериться, что все в пределах нормы. Перенесите инициализацию на позже...

Я же уже несколько раз написал:
В старом ПО - работает. В новом - нет. Код включающий АЦП и считывающий - один и тот же, что в старом что в новом ПО. Место его вызова - одно и то же. От точки старта ПО до места этого вызова и в том и в другом ПО выполняются всего две ассемблерные команды (запреты прерывания), на эти команды переход происходит с вектора сброса из таблицы прерывания. Повторяемость - 100%-ная.
Времён для этого регистра в принципе нет, и единственное что про него написано - что его содержимое инициализируется в bootcode.
Более того - это код (чтения с АЦП) проходил и по шагам тоже под JTAG-ом, т.е. - задержки между шагами огромные, и симптомы остались те же.
И ещё раз повторю: регистр ADTRIM нигде у меня в ПО не считывается не пишется, да и в принципе не может писаться так как от вектора сброса до точки включения тактирования периферии АЦП прошагал под JTAG-ом (много раз причём) - сразу как только включается АЦП и его регистры оказываются читаемыми JTAG-ом, из ADTRIM считывается или 0 или 0xF00. И очень похоже, что именно значение 0 приводит к неработоспособности АЦП.
Go to the top of the page
 
+Quote Post
ViKo
сообщение Jun 28 2016, 08:56
Сообщение #8


Универсальный солдатик
******

Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362



Цитата(jcxz @ Jun 28 2016, 11:18) *
Я же уже несколько раз написал:

Я прочитал столько же несколько раз. Но лучше один раз увидеть. Это не "Top secret", несколько ассемблерных команд, до и после "перестройки"?
Да не для регистра времен...! Для всего АЦП!
Понятно, что 0 приводит к неработоспособности. Это же, типа, масштаб опорного напряжения. 0 откуда взялся?
В-общем, новая прошивка портит ADTRIM. Неважно, когда, главное, как.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 28 2016, 09:38
Сообщение #9


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(ViKo @ Jun 28 2016, 14:56) *
Понятно, что 0 приводит к неработоспособности. Это же, типа, масштаб опорного напряжения. 0 откуда взялся?
В-общем, новая прошивка портит ADTRIM. Неважно, когда, главное, как.

Код
AppStart:
  CPSID    i
  CPSID    f
  BL InitADC
  ...
InitADC:
  PUSH     {R7,LR}
  MOVS     R0,#+12
  BL       _Z17PeripheralPowerOn12PERIPH_PCONP;включение тактирования периферии ADC
  LDR.N    R0,??DataTable2_7;; 0x40034000
  LDR.N    R1,??DataTable2_8;; 0x206110
  STR      R1,[R0, #+0];разрешаем АЦП установкой бита разрешения и конфигурим частоту и канал
;здесь периферия ADC включена; читаем регистры АЦП, хоть программно, хоть через окно Watch отладчика (запсукаем преобразование записью соотв бита Старт)

Метка AppStart находится в векторе сброса. И на неё же становится PC при подключении JTAG.
Этот участок кода - абсолютно одинаков, что в старом ПО, что в новом (ну разве что адреса расположения различаются).
Процедура _Z17PeripheralPowerOn12PERIPH_PCONP - тоже абсолютно одинакова в обоих ПО. Она просто устанавливает бит включения тактирования АЦП через битбанд-область.
Но если в конце указанного фрагмента запустить преобразование, то результаты получаются разными. И если считать регистр ADTRIM - значения тоже разные.
Отсюда вывод - значение ADTRIM устанавливается bootcode-ом, почему то в разные значения. Каким-то образом bootcode для одной прошивки устанавливает значение ADTRIM=0, для другой - ADTRIM=0xF00.
Почему - вот вопрос??

mac-файл для подключения JTAG-а я тоже никакой не задавал.
Go to the top of the page
 
+Quote Post
ViKo
сообщение Jun 28 2016, 10:08
Сообщение #10


Универсальный солдатик
******

Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362



А если InitADC выполнить позже, поменять с чем-нибудь?
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 28 2016, 10:55
Сообщение #11


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(ViKo @ Jun 28 2016, 16:08) *
А если InitADC выполнить позже, поменять с чем-нибудь?

Оно и так позже стояло, это я в самое начало воткнул когда искал проблему. Думал может в коде который до неё выполняется где-то портится содержимое регистров управления АЦП или тактирования или ещё чего.
А в нормальном рабочем коде оно выполняется более чем через 130мс после старта, после кучи всякой другой инициализации (других драйверов железа).
И в рабочем коде чтение ADC идёт через DMA в burst-режиме. А когда искал баг я пробовал и в режиме программного запуска АЦП читать - значения одни и те же.

В даташите указывается что bootcode должен записать в ADTRIM значение некоего коэффициента, а потом установить lock-биты (8-11). Получается в каких-то случаях он этого не делает...... wacko.gif
Код
bits 3:0 - reserved. NA
bits 7:4 - ADCOFFS    Offset trim bits for ADC operation. Initialized by the boot code. Can be overwritten by the user.  reset value = 0
bits 11:8 - TRIM written-to by boot code. Can not be overwritten by the user. These bits are locked after boot code write. reset value = 1111
Go to the top of the page
 
+Quote Post
Alechek
сообщение Jun 28 2016, 13:27
Сообщение #12


Профессионал
*****

Группа: Свой
Сообщений: 1 241
Регистрация: 15-11-05
Из: Челябинск
Пользователь №: 10 882



Цитата(jcxz @ Jun 28 2016, 15:55) *
В даташите указывается что bootcode должен записать в ADTRIM значение некоего коэффициента, а потом установить lock-биты (8-11). Получается в каких-то случаях он этого не делает...... wacko.gif

Слабо верится в то, что содержимое рабочей области флэша влияет на загрузчик. Более верю в то, что выполняется рабочий код с ошибкой, поганит что-то, потом происходит сброс (переход на AppStart) и далее с вытекающими.
Совет поставить бряку на ADTRIM остается в силе. Даже если оно завязано на заводской загрузчик, по коду можно понять, в чем дело.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 28 2016, 13:40
Сообщение #13


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Alechek @ Jun 28 2016, 19:27) *
Слабо верится в то, что содержимое рабочей области флэша влияет на загрузчик. Более верю в то, что выполняется рабочий код с ошибкой, поганит что-то, потом происходит сброс (переход на AppStart) и далее с вытекающими.

Происходит сброс и что? После сброса должен выполниться bootcode, который должен проинитить этот ADTRIM.
Управление на AppStart само не попадает, его передаёт туда bootcode.
При подключении JTAG-а, он тоже выдаёт сброс (тип сброса: core and peripheral).

Цитата(Alechek @ Jun 28 2016, 19:27) *
Совет поставить бряку на ADTRIM остается в силе. Даже если оно завязано на заводской загрузчик, по коду можно понять, в чем дело.

Можно попробовать, хотя не знаю что это даст если внутри bootcode туда будет что-то писаться.
Go to the top of the page
 
+Quote Post
zltigo
сообщение Jun 28 2016, 14:49
Сообщение #14


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Абстрагируйтесь от этого несчастного ADTRIM - ADC, например, не смог откалиброваться и ADTRIM это уже следствие. Причина может быть вполне аппаратной. Например, есть errаtа по помехам приводящим к сбоям ADC.


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 29 2016, 04:04
Сообщение #15


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(zltigo @ Jun 28 2016, 20:49) *
Абстрагируйтесь от этого несчастного ADTRIM - ADC, например, не смог откалиброваться и ADTRIM это уже следствие. Причина может быть вполне аппаратной. Например, есть errаtа по помехам приводящим к сбоям ADC.

Согласен, всё как будто указывает на аппаратную причину. Но это происходит на одном и том же устройстве просто при смене прошивки на ту или другую
Просто на столе в одинаковых условиях, и повторяемость 100%-ая. wacko.gif
У меня единственная версия, какой бы не была она несуразной: после сброса, управление получает bootcode, который проверяет наличие валидной программы во флешь (подсчётом контрольной суммы первых нескольких векторов прерывания вроде), после чего инитит ADC. И по какой-то причине, в новом ПО, при проверке валидности прошивки происходит сбой (из-за содержимого таблицы векторов прерываний???), такой что инициализация АЦП не производится. Больше в голову ничего не приходит. Похоже нужно ждать обновления errata-ы, тем более что недавно она на этот МК как раз обновилась и в ней как раз добавилось описание ещё одного бага АЦП, на который мы наткнулись ещё несколько лет назад, а в errata его добавили только недавно.
Возможно в bootcode где-то есть баг.....
Go to the top of the page
 
+Quote Post
zltigo
сообщение Jun 29 2016, 04:27
Сообщение #16


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



QUOTE (jcxz @ Jun 29 2016, 07:04) *
Возможно в bootcode где-то есть баг.....

Только проявляется он не по той схеме которая Вами описана - уж совсем за уши притянута.



--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post
Alechek
сообщение Jun 29 2016, 04:40
Сообщение #17


Профессионал
*****

Группа: Свой
Сообщений: 1 241
Регистрация: 15-11-05
Из: Челябинск
Пользователь №: 10 882



Цитата(jcxz @ Jun 28 2016, 18:40) *
Происходит сброс и что? После сброса должен выполниться bootcode, который должен проинитить этот ADTRIM.
Управление на AppStart само не попадает, его передаёт туда bootcode.

Вторичный загрузчик есть?
WDT используется?

И да, заводской загрузчик ничего не знает о вашем APP_START. Он всего лишь подменяет адресное пространство с 0-го адреса на пользовательску флешь и выполняет сброс ядра (или его программную эмуляцию).
И запускается загрузчик _только_ при аппаратном сбросе. Сброс по JTAG сбросом не считатся, так как адресное пространство уже настроено на пользовательскую флешь.

Go to the top of the page
 
+Quote Post
KRS
сообщение Jun 29 2016, 06:07
Сообщение #18


Профессионал
*****

Группа: Модераторы
Сообщений: 1 951
Регистрация: 27-08-04
Из: Санкт-Петербург
Пользователь №: 555



Цитата(jcxz @ Jun 29 2016, 07:04) *
И по какой-то причине, в новом ПО, при проверке валидности прошивки происходит сбой (из-за содержимого таблицы векторов прерываний???),

Так пройдите бутлоадер по шагам - он прекрасно проходится... (возможно пару инструкций придется обойти, где JTAG отключается/подключается если это есть в LPC17xx, я только LPC21xx исследовал)
Или в IDA залейте...
Там небольшой кусочек исполняется, если контрольная сумма верная...




Цитата(Alechek @ Jun 29 2016, 07:40) *
И запускается загрузчик _только_ при аппаратном сбросе. Сброс по JTAG сбросом не считатся, так как адресное пространство уже настроено на пользовательскую флешь.

Поэтому, например у JLINK куча методов сброса для LPC, и например для LPC40xx лучше всего работает HALT after bootloader - потому что там еще настройки ROM прописываются иначе глючить IAP например начинает...
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 29 2016, 07:02
Сообщение #19


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Alechek @ Jun 29 2016, 10:40) *
Вторичный загрузчик есть?
WDT используется?

Нет и нет.

Цитата(Alechek @ Jun 29 2016, 10:40) *
Он всего лишь подменяет адресное пространство с 0-го адреса на пользовательску флешь и выполняет сброс ядра (или его программную эмуляцию).

Думаю он не выполняет сброс ядра, так как на его входе ядро уже сброшено.

Цитата(Alechek @ Jun 29 2016, 10:40) *
И запускается загрузчик _только_ при аппаратном сбросе.
Сброс по JTAG сбросом не считатся, так как адресное пространство уже настроено на пользовательскую флешь.

Да ну?! А зачем тогда среди сигналов JTAG есть сигнал nTRST? Для красоты что-ль? Он у нас разведён. И в свойствах подключения JTAG указываю стратегию сброса "core and peripheral" или "Reset PIN".

Цитата(KRS @ Jun 29 2016, 12:07) *
Поэтому, например у JLINK куча методов сброса для LPC, и например для LPC40xx лучше всего работает HALT after bootloader - потому что там еще настройки ROM прописываются иначе глючить IAP например начинает...

После множества проб, у меня сложилось впечатление что самое правильное подключение с типом сброса "core and peripheral". Иногда использую "Reset PIN".
Имхо - другие методы могут не задействовать сигнал nTRST JTAG-коннектора.
Go to the top of the page
 
+Quote Post
Obam
сообщение Jun 29 2016, 08:13
Сообщение #20


Знающий
****

Группа: Участник
Сообщений: 756
Регистрация: 14-11-14
Пользователь №: 83 663



" А зачем тогда среди сигналов JTAG есть сигнал nTRST? Для красоты что-ль? "


"3 - nTRST - Output - JTAG Reset. Output from J-Link to the Reset signal of the target JTAG port. Typically connected to nTRST of the target
CPU. This pin is normally pulled HIGH on the target to avoid unintentional resets when there is no connection."

"15 - RESET - I/O - Target CPU reset signal. Typically connected to the RESET pin of the target CPU, which is typically called "nRST", "nRESET" or "RESET"."


--------------------
Пролетарий умственного труда.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 29 2016, 08:17
Сообщение #21


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Obam @ Jun 29 2016, 14:13) *
" А зачем тогда среди сигналов JTAG есть сигнал nTRST? Для красоты что-ль? "
"3 - nTRST - Output - JTAG Reset. Output from J-Link to the Reset signal of the target JTAG port. Typically connected to nTRST of the target
CPU. This pin is normally pulled HIGH on the target to avoid unintentional resets when there is no connection."
"15 - RESET - I/O - Target CPU reset signal. Typically connected to the RESET pin of the target CPU, which is typically called "nRST", "nRESET" or "RESET"."

И...?
Go to the top of the page
 
+Quote Post
Obam
сообщение Jun 29 2016, 08:55
Сообщение #22


Знающий
****

Группа: Участник
Сообщений: 756
Регистрация: 14-11-14
Пользователь №: 83 663



Цитата(jcxz @ Jun 29 2016, 12:17) *
И...?


Ну… " А зачем тогда среди сигналов JTAG есть сигнал nTRST? Для красоты что-ль? "
Разницу и подчеркнул и выделил


--------------------
Пролетарий умственного труда.
Go to the top of the page
 
+Quote Post
Alechek
сообщение Jun 29 2016, 09:06
Сообщение #23


Профессионал
*****

Группа: Свой
Сообщений: 1 241
Регистрация: 15-11-05
Из: Челябинск
Пользователь №: 10 882



И
Цитата("UM10360")
The flash boot loader code is executed every time the part is powered on or reset.

\TRST сбрасывает только тестовую логику. ПЕРИФЕРИЯ НЕ СБРАСЫВАЕТСЯ!

По поводу сбросов все расписано тут.

Для сброса всей системы есть Application Interrupt and Reset Control Register. А как оно отрабытывает (влияет ли на Memory Mapping Control register (MEMMAP - 0x400F C040)) - неизвестно.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 29 2016, 09:36
Сообщение #24


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Alechek @ Jun 29 2016, 15:06) *
\TRST сбрасывает только тестовую логику. ПЕРИФЕРИЯ НЕ СБРАСЫВАЕТСЯ!
Для сброса всей системы есть Application Interrupt and Reset Control Register. А как оно отрабытывает (влияет ли на Memory Mapping Control register (MEMMAP - 0x400F C040)) - неизвестно.

Нашёл вроде причину: при изменении типа сброса в свойствах подключения JTAG с "Core and peripheral" на "Reset PIN" всё начинает работать (в ADTRIM появляется 0xF00).
Получается что при "Core and peripheral" после сброса не выполняется bootcode, а при "Reset PIN" или при "Normal" bootcode выполняется после сброса.
У нас nTRST с JTAG подключен к TRST МК.
Если "ПЕРИФЕРИЯ НЕ СБРАСЫВАЕТСЯ" почему такая разница между разными типами сброса подключения JTAG?

PS: Старый и новый мои проекты различались типом сброса при подключении JTAG.
Go to the top of the page
 
+Quote Post
Alechek
сообщение Jun 29 2016, 10:26
Сообщение #25


Профессионал
*****

Группа: Свой
Сообщений: 1 241
Регистрация: 15-11-05
Из: Челябинск
Пользователь №: 10 882



По \TRST периферия НЕ СБРАСЫВАЕТСЯ.
А вот далее по JTAG у Вас сбрасывались, согласно вышеприведенным настройкам, "Core and peripheral". Каким образом - остается за кадром. Возможно, через Application Interrupt and Reset Control Register.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 29 2016, 10:37
Сообщение #26


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Alechek @ Jun 29 2016, 16:26) *
По \TRST периферия НЕ СБРАСЫВАЕТСЯ.
А вот далее по JTAG у Вас сбрасывались, согласно вышеприведенным настройкам, "Core and peripheral". Каким образом - остается за кадром. Возможно, через Application Interrupt and Reset Control Register.

Возможно что при "Core and peripheral" IAR при подключении отладчика посылает сброс через этот "Application Interrupt and Reset Control Register" не проходя bootcode.
В разъёме от JTAG нашёл ещё один сигнал сброса, который у нас заведён на RESET МК. Наверное при выборе "Reset PIN"-варианта сигнал сброса JTAG подаёт на него с проходом bootcode и инитом ADTRIM....
Go to the top of the page
 
+Quote Post
Alechek
сообщение Jun 29 2016, 18:34
Сообщение #27


Профессионал
*****

Группа: Свой
Сообщений: 1 241
Регистрация: 15-11-05
Из: Челябинск
Пользователь №: 10 882



Сейчас занимаюсь с LPC1754. В настройках JLINK стоит тип сброса "Normal". Для интереса, попробовал поставить "Core and peripheral" - у меня не только ADTRIM в 0 стал, у меня вообще весь проект раком встал. По SPI 512 байт вычитывать стал за полторы секунды вместо положеных 300 мкс
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 30 2016, 03:07
Сообщение #28


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Alechek @ Jun 30 2016, 00:34) *
Сейчас занимаюсь с LPC1754. В настройках JLINK стоит тип сброса "Normal". Для интереса, попробовал поставить "Core and peripheral" - у меня не только ADTRIM в 0 стал, у меня вообще весь проект раком встал. По SPI 512 байт вычитывать стал за полторы секунды вместо положеных 300 мкс

Ранее тоже пользовался "Normal" (это дефолт). Но потом перешёл на "Core and peripheral" как раз из-за каких-то проблем с периферией при рестартах отладчика. Точно уже не помню в чём именно было дело, возможно что не сбрасывалась какая-то периферия при рестарте или не глушились DMA-передачи или еще чего. С "Core and peripheral" это пропало. Использую эту установку на нескольких разных МК: LPC1758, LPC1778, LPC1788, Tiva TM4C129 - нигде до сих пор проблем не возникало. Правда нигде в них кроме этого проекта АЦП не используется.
Везде используется куча разной периферии как через DMA так и прерывания.
Go to the top of the page
 
+Quote Post
KRS
сообщение Jun 30 2016, 08:34
Сообщение #29


Профессионал
*****

Группа: Модераторы
Сообщений: 1 951
Регистрация: 27-08-04
Из: Санкт-Петербург
Пользователь №: 555



Цитата(jcxz @ Jun 29 2016, 13:37) *
Наверное при выборе "Reset PIN"-варианта сигнал сброса JTAG подаёт на него с проходом bootcode и инитом ADTRIM....

IMHO лучше ставить HALT after bootloader, тогда и reset используется и бутлоадер гарантировано запускается!


Цитата(jcxz @ Jun 30 2016, 06:07) *
Использую эту установку на нескольких разных МК: LPC1758, LPC1778, LPC1788, Tiva TM4C129 - нигде до сих пор проблем не возникало. Правда нигде в них кроме этого проекта АЦП не используется.
Везде используется куча разной периферии как через DMA так и прерывания.

Вот я тоже использовал, обычно правда, SWD connect under reset чтобы вообще чип чисты был!
но вот на LPC40xx функции из boot rom стали глючить пришлось ставить halt after bootloader

В общем чем дальше - тем печальнее! документации все меньше - непонятного и закрытого кода от производителя - больше!


Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 30 2016, 08:54
Сообщение #30


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(KRS @ Jun 30 2016, 14:34) *
IMHO лучше ставить HALT after bootloader, тогда и reset используется и бутлоадер гарантировано запускается!

А при этом точно reset подаётся? И какой именно: импульс на какую-то ногу разъёма JTAG или сброс при помощи регистров CPU?
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jul 10 2016, 06:01
Сообщение #31


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(KRS @ Jun 30 2016, 14:34) *
IMHO лучше ставить HALT after bootloader, тогда и reset используется и бутлоадер гарантировано запускается!

Сейчас попробовал поставить "HALT after bootloader" в проекте на LPC4370.
Результат: даже не может запуститься сессия отладки - при каждой попытке запуска, во время загрузки кода выдаёт:
Цитата
Can not read register 15 (R15) while CPU is running
Abort debug session?

В то время как "Core and peripheral" работает нормально.
Правда в качестве эмулятора использую не J-Link, а плату OM13054 с прошивкой J-Link с сайта segger.
Go to the top of the page
 
+Quote Post

3 страниц V   1 2 3 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 23rd July 2025 - 12:45
Рейтинг@Mail.ru


Страница сгенерированна за 0.01678 секунд с 7
ELECTRONIX ©2004-2016