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

Кто-нибудь сталкивался с этой проблемой?

Может быть, вы не выдерживаете какие-то времена, прежде чем обращаться к АЦП? Тстартап, или что там есть у 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). Повторил опыт много раз, перезапуская, пересбрасывая питание, перешил несколько раз ПО туда и обратно....

Значит, запукать дебагер с брякой на запись даных по адресу ADTRIM.
Возможно, кто-то пишет туда нечаянно.

Предлагаете bootcode отлаживать? А смысл? Он и должен писать.

У STM есть datasheet, в нем все времена описаны. Где искать у NXP, не знаю. Где-то есть. Предлагаю удостовериться, что все в пределах нормы. Перенесите инициализацию на позже...

Я же уже несколько раз написал:
В старом ПО - работает. В новом - нет. Код включающий АЦП и считывающий - один и тот же, что в старом что в новом ПО. Место его вызова - одно и то же. От точки старта ПО до места этого вызова и в том и в другом ПО выполняются всего две ассемблерные команды (запреты прерывания), на эти команды переход происходит с вектора сброса из таблицы прерывания. Повторяемость - 100%-ная.
Времён для этого регистра в принципе нет, и единственное что про него написано - что его содержимое инициализируется в bootcode.
Более того - это код (чтения с АЦП) проходил и по шагам тоже под JTAG-ом, т.е. - задержки между шагами огромные, и симптомы остались те же.
И ещё раз повторю: регистр ADTRIM нигде у меня в ПО не считывается не пишется, да и в принципе не может писаться так как от вектора сброса до точки включения тактирования периферии АЦП прошагал под JTAG-ом (много раз причём) - сразу как только включается АЦП и его регистры оказываются читаемыми JTAG-ом, из ADTRIM считывается или 0 или 0xF00. И очень похоже, что именно значение 0 приводит к неработоспособности АЦП.

Я прочитал столько же несколько раз. Но лучше один раз увидеть. Это не "Top secret", несколько ассемблерных команд, до и после "перестройки"?
Да не для регистра времен...! Для всего АЦП!
Понятно, что 0 приводит к неработоспособности. Это же, типа, масштаб опорного напряжения. 0 откуда взялся?
В-общем, новая прошивка портит ADTRIM. Неважно, когда, главное, как.

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

mac-файл для подключения JTAG-а я тоже никакой не задавал.

А если InitADC выполнить позже, поменять с чем-нибудь?

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

В даташите указывается что bootcode должен записать в ADTRIM значение некоего коэффициента, а потом установить lock-биты (8-11). Получается в каких-то случаях он этого не делает......

Слабо верится в то, что содержимое рабочей области флэша влияет на загрузчик. Более верю в то, что выполняется рабочий код с ошибкой, поганит что-то, потом происходит сброс (переход на AppStart) и далее с вытекающими.
Совет поставить бряку на ADTRIM остается в силе. Даже если оно завязано на заводской загрузчик, по коду можно понять, в чем дело.

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


Можно попробовать, хотя не знаю что это даст если внутри bootcode туда будет что-то писаться.

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

Согласен, всё как будто указывает на аппаратную причину. Но это происходит на одном и том же устройстве просто при смене прошивки на ту или другую
Просто на столе в одинаковых условиях, и повторяемость 100%-ая.
У меня единственная версия, какой бы не была она несуразной: после сброса, управление получает bootcode, который проверяет наличие валидной программы во флешь (подсчётом контрольной суммы первых нескольких векторов прерывания вроде), после чего инитит ADC. И по какой-то причине, в новом ПО, при проверке валидности прошивки происходит сбой (из-за содержимого таблицы векторов прерываний???), такой что инициализация АЦП не производится. Больше в голову ничего не приходит. Похоже нужно ждать обновления errata-ы, тем более что недавно она на этот МК как раз обновилась и в ней как раз добавилось описание ещё одного бага АЦП, на который мы наткнулись ещё несколько лет назад, а в errata его добавили только недавно.
Возможно в bootcode где-то есть баг.....