На днях мне попала в руки плата с убитой DSP-шкой TMS320F28335 от Texas Instruments. Машинка для своей цены довольно резвая и заряжена всем чем только можно пожелать для цифровой обработки сигнала (ну, разве что Ethernet’а не хватает, но у Texas Ethernet на DSP появляется только на 6678, а это уже совсем заряженная машинка).
Принесли мне эту плату с целью установить — можно ли ее оживить, т.к. программист, который ей занимался, прошил туда что-то непонятное и DSP превратился в тыкву. В результате JTAG эмулятор не мог подключиться к ядру и остановить его для отладки/прошивки. Code Composer при запуске debug-сессии выдавал следующую ошибку:
C28xx: Error connecting to the target: (Error -1155 @ 0x0) Device may be operating in low-power mode. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.0.872.0)
При этом JTAG Integrity scan-test показывал, что сама JTAG-цепочка в полном порядке.
——[Perform the Integrity scan-test on the JTAG IR]————————
This test will use blocks of 512 32-bit words.
This test will be applied just once.
Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.
The JTAG IR Integrity scan-test has succeeded.
——[Perform the Integrity scan-test on the JTAG DR]————————
This test will use blocks of 512 32-bit words.
This test will be applied just once.
Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.
The JTAG DR Integrity scan-test has succeeded.
[End]
Естественно, никакого «low-power mode» там быть не могло, разные настройки частоты TCLK интерфейса JTAG также не помогли.
Путем интенсивного допроса программиста, выяснилось, что он пытался сделать специфический бутлоадер и прошить его во флэш DSP-шки. Кроме того там еще была запись каких-то констант во флэш. А вот это уже было интересно!
Дело в том, что в даташите на контроллер нормальным английским языком сказано, что при попытке прошить что-то во внутреннюю флэш, кусок кода, выволняющий запись, должен в этот момент находиться в ОЗУ. Программист, видимо, считал изучение даташита излишним… А получилось в результате, вот что: выполняясь из флэш-памяти, функция записи данных отключает флэш-память от внутренней шины DSP, далее процессор пытается выбрать следующую инструкцию (из флэш-памяти, ага!) и не может это сделать, т.к. флэш только что отвалился. И процессор переходит в какое-то неопределенное состояние, в котором его невозможно остановить. Проблема была в том, что программа выполнялась из флэш-памяти и после сброса быстро возвращалась в неработоспособное состояние. Специфические настройки дебаггера, типа «Wait in Reset» также не помогли подключиться к устройству. Чтобы победить подобный клин было принято решение выдрать с платы кварц и подать на процессор внешнее тактирование 1кГц (вместо штатных 30МГц). Расчет был на то, что встроенный PLL не защелкнется и программа застрянет в бесконечном цикле ожидания PLL.
В целом, расчет оправдался — к DSP-шке удалось подключиться дебаггером, но в процессе стирания флэш произошла какая-то ошибка (вероятно, как раз из-за низкой частоты тактирования) и операция записи была прервана (а это самая хреновая ситуация из возможных операций с флэш-памятью). Что конкретно произошло внутри контроллера — не понятно, но после возвращения на место штатного кварца доступ по JTAG к контроллеру сохранился, но полностью отвалилось ОЗУ (ни чтение, ни запись не работают).
Чуть позже пришло понимание, что можно было это сделать по-другому: настроить bootstrap pin’ы на принудительную загрузку из другого источника (по SPI, XINTF или др.). Подробнее тут: PDF страница 21. В результате контроллер спасти не удалось — придется менять, а если плата через неделю не пройдет ПСИ (приемо-сдаточные испытания), то, возможно, не удастся спасти и программиста 🙂
PS: Это был ведущий(!) инженер-программист!
А еще боремся за почетное звание дома высокой культуры быта! (С) А.С. Шпак, к/ф «Иван Васильевич меняет профессию»
UPDATE: т.к. после написания этого поста программист «успешно» запорол еще один контроллер, удалось на практике проверить второй способ оживления — с bootstrap пинами. На этот раз все прошло гладко — ROM bootloader был сконфигурирован на принудительную загрузку из ОЗУ и эмулятор успешно соединился с контроллером. После чего флэш память была успешно затерта и контроллер вернулся в исходное состояние.
— Готово, мастер! Зопорол, все шесть!
— Как шесть? Я же тебе пять дал!
— И шоблон зопорол! (С) Автор неизвестен