talus

У меня L137 + xds100v2 У меня с моим конфигом все нормально, частота 375МГц реальная. Подозреваю, что L138 виноват. Попробуйте АРМ ядро выключить после инициализации, оставьте чисто DSP.

Чё это так безапелляционно? Через L2 определенную как RAM тоже прекрасно обмениваются, почитайте внимательно описание оба ядра имеют доступ ко всей памяти...

Ну вот видите, с этого и надо было начинать. Спрашивается с чего вы решили, что ошибка в SPI? Управляя SPI при помощи процессора ошибок нет, попробуйте сами. Значит глядеть то надо в связь между dma и spi.

Не встречал такого... Точнее при записи еепром такого не видел.

Не проще, можно добавить такую рюшечку как изолированный JTAG. Что очень помогает от кривых рук ;) И еще много чего, ограничиваясь лишь фантазией. Ну и до кучи можно их сделать много и раздать всем желающим на предприятии, лишними эмуляторами оказать помошь (то бишь подарить) университету какому либо. Ну и т.д.

Для маломальски грамотного инженера не составит труда повторить это, а может сделать и лучше.

Использовал SPI под 6727b только как бутлоадер, никаких проблем не испытывал ибо скорость SPI ограничивалась EEPROM. Учтите boot spi не поддерживает flash, только eeprom. Нормально по сравнению с BottSPI отличается только количеством линий, оба используют EEPROM.

Ооо пропустил как то... Будет чуточку быстрее, добавили поддержку 1149.7 Придеться заняться на досуге новой ревизией своего XDS100 :) P.S. размеры платки увеличаться теперь, нет в природе маленьких FPGA со флэхой :(

Кэш инструкции и кэш данных включены. Оппа! А вы занете метод "от противного" сработал, т.е. отключил кэш и код выполняется. Спасибо за подсказку :)

Имеем сей чудный девайс, всё прекрасно работает. Используются DSP+ARM без операционки. C6747 крутиться в L2RAM. ARM9 крутиться в shared RAM. Есть необходимость "убыстрить" ARM. Перечитывая документ sprs563 наткнутлся на фразу Т.е. можно запустить ARM под "быстрой" L2RAM или даже в L1DRAM (имеюшую latency = 0). Переделав .cmd (убираем shared RAM, ставим L2RAM), получим: для ARM L2RAMA: o = 0x11800000 l = 0x00020000 для DSP L2RAMD: o = 0x00810000 l = 0x00020000 L2RAM проиницирован как no caсhe, RAM only. В итоге получаем, что код под DSP также работает, а код под ARM не исполняется. В диссасемблере загруженный код виден, соответствует написанному. В памяти загруженный код виден м также соответствует написанному. Но пошагово не исполняется, видимо инструкции не исполняются, в регистры ARM не записываются данные, но при этом PC прибавляется как будто идет выполнение кода. Как заставить работать ARM из под L2RAM? Может какой защитный битик памяти не установлен? P.S. тему забыл нормально обозвать :( "Исполнение кода ARM в L2RAM"

Ого лихо загнули, протоколы знаете и как подойти к проблеме нет. Все таки может сначала с низкоуровневым драйвером разберетесь, для одного из протокола. Чтобы данные, без завязки на протокол, туда-сюда гонялись А затем уже самим протоколом будете заниматься?

Когда разбирался с C2000, в датащите все в картинках и черным по белому английскими буковками, да в сравнении эти методы разжеваны и показаны. Почитайте, а?

Хы я уж подумал, что TI что то новое сделал, ан нет все также. Сам производитель индексы штампует просто, ну ладно всё оффтоп, свой эмулятор ближе к телу ;)

А ничё, что компилятор для арм TI вроде как свой не предоставляет, а использует компилятор АРМ холдинга лишь портировав его под CCS? А описание на регистры и внутреннюю часть арм, TI даже не выкладывает, а лишь дает ссылку на АРМ холдинг.

Все правильно в BSL, область памяти блока UPP находится по адресу 0x01E16000 заканчиваетя 0x01E16FFF = 4K Читаем SPRS586B п.6.26.1 Адрес UPPID = 0x01E16000, а вот его значение UPPID = 0x44231100. Что не понятно то?