Всем привет.

Сигнальниками раньше не занимался, больше ПЛИС. Но СИ и еклипс мне знакомы.
Сделал плату, на ней имеется ПЛИС и OMAP L138.
Нужно написать простую программку для проверки работоспособности платы:
- EMIF, подключенный к ПЛИС
- UPP, подключенный к ПЛСИ
- чтение/запись DDR2, подключенной к сигнальнику
- помаргать светодиодиками.

Что-то не могу найти простых толковых примеров, Quick Start или еще чего. Ткните куда-нибудь...

"хело ворлд" в Code Composer Studio v5 получил, т.е. jtag работает, проц запускается.

Хм... А что - в L138 первым стартует ARM?
Работал с L137 только - там стартует DSP (по вкл. питания ARM - в ресете) , код bootloader-а выполняет DSP, и в пользовательском ПО чтобы использовать ARM, надо сперва прописать таблицу векторов для ARM (в его памяти), а потом - включить его и вывести из ресета.
Под JTAG - на L137 доступны сразу оба ядра, так как JTAG их сам выводит из ресета когда подключается к ним. И на отладку под JTAG можно запускать сразу два проекта параллельно.

rts.lib файл boot.asm:Можно конечно через SWI. Но я делаю как показал выше - так проще.
Кроме того - в этом rts.lib можно ещё что-нить пооптимизить и пообкусывать.

Скачали с сайта техаса файл boot.asm, тупо добавили его в проект - все заработало.

Как это работает, каким образом этот асм файл встроился в код - непонятно совершенно.

А сигнальник все равно в ресете

На строках



виснет. Какой порядок включения dsp? Разве не такой же как и GPIO?

Там мудреная система загрузки: первым стартует DSP, затем он при помощи PRU окучивает ARM, потом ARM отрубает DSP.


Порядок включения описан в разделе "DSP Wake Up" sprugm7. Но виснуть при обращении к PSC всяко не должен.

По мануалу:

Perform the following steps to wake up the DSP:
1. Write a 83E7 0B13h to the KICK0R register in the SYSCFG module.
2. Write a 95A4 F1E0h to the KICK1R register in the SYSCFG module.
3. Write the truncated DSP boot address vector to the DSP_ISTP_RST_VAL field in the host 1
configuration register (HOST1CFG) of the SYSCFG module. The least-significant bits of the boot
address are fixed at 0.
4. Write a 3h to the NEXT bit in the DSP local power sleep controller (LPSC) module control register
(PSC0.MDCTL15) to prepare the DSP module for an enable transition (to enable the clocks and all
transitioning from the SwRstDisable state to Enable state).
5. Write a 1 to the GO[1] bit (DSP subsystem is part of the PD_DSP domain) in the power domain
transition command register (PSC0.PTCMD) to start the state transition sequence for the DSP module.
6. Check (poll for 0) the GOSTAT[1] bit in the power domain transition status register (PSC0.PTSTAT) for
power transition sequence completion. The domain is only safely in the new state after the GOSTAT[1]
bit is cleared to 0.
7. Wait for the STATE bit field in the DSP LPSC module status register (PSC0.MDSTAT15) to change to
3h. The module is only safely in the new state after the STATE bit field changes to reflect the new
state.
8. Write a 1 to the LRST bit in PSC0.MDCTL15 to release the DSP local reset controlled by the PSC
module.

Выполняю следующее:



И на строке

Выполнение программы подвисает. Что делаю не так?

А что говорит PSC0.MDSTAT15?

0x00000A00

То есть по статусу он и не начинал включаться. Нужно смотреть внутренности PSCModuleControl, так у меня идей нет.

Значит - всё точно так же как в L137.
А зачем Вы отрубаете DSP после старта ARM?
Если интересно могу привести свой код, которым запускаю ARM (см. прикреплённый файл).  boot.zip ( 1.05 килобайт ) Кол-во скачиваний: 140
Файл boot.asm (который в составе rts.lib) модифицирован как указано в моём посте выше.
Начало main() из DSP-проекта:

Нет, совершенно по-другому. DSP после старта отрубает программа из ARM Boot ROM.

Это и есть основное, если даже не единственное отличие 137 и 138 - в 137 стартует DSP с заглушенным ARM, а в 138 наоборот, стартует ARM с заглушенным DSP.

Да уж, нагородили ... техасцы на ровном месте.....
Думаю, что у L138 тогда более логичный порядок старта. Всегда удивляло - зачем в L137 сделали главным в запуске DSP?
Кстати - не единственное - для нас существенным доводом в пользу L137 против L138 стало наличие в первом McASP (в L138 - только McBSP).

Все просто. Есть задачи, где ДСП молотит всегда, а АРМ у него на подручных работах - TCP/IP например. Там не надо, чтобы АРМ стартовал первым, ДСП в него грузит нужные протокольные уровни и работает через него как через сопроцессор связи. Там L137 удобен - так как ДСП грузится первым и дальше мастерит всеми процессами. А есть другие задачи - где АРМ работает например под линуксом, а ДСП у него на подручных работах - кодек загрузить, когда юзер захочет. Вот тут L138 самое оно.

На самом деле в L138 первым тоже стартует DSP, просто от конечного пользователя вся эта кухня скрыта.

И в нем есть McASP, куда же без него.

Конечно, точно не могу утверждать, но косвенные признаки показывают, что это не так. Если выполнить hardware reset через JTAG при помощи ICEPICK, и не дать ядрам выполнить ничего из внутреннего ПЗУ, то живым в L138 оказывается таки ARM, а в L137 - DSP. И это же следует из анализа стартапных GEL-файлов обоих процессоров, и последовательностей коннекта эмуляторов к ядрам.

Вот цитата из errata, касающаяся ревизий 2.0 и ниже:

Возможно, в 2.1 последовательность поменяли, хотя проще было бы пропатчить DSP boot ROM.