АЦП LPC1758 (недопустимое значение регистра ADTRIM) Опции

[jcxz]

Столкнулся с проблемой с АЦП в давно выпускаемом устройстве на 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 (там калибровочные значения). И непонятно что будет дальше в других экземплярах МК?

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

[ViKo]

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

[jcxz]

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

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

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

Код

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

[Alechek]

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

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