jcxz

Может и проще, не знаю - не пробовал.

Хм... Надо было наверно ещё раз до дырок зачитать :) Я написал свой USB-device-стек на L137 пользуясь исключительно SPRUFM9H и примером USB-device-стека от NXP для LPC2378. Правда USB1.1, но больше и не нужно. Реализовать обмен через control-endpoint там сравнительно просто - нужно всего десяток регистров. Дальше берете любой пример стека для другого проца, переписываете уровень взаимодействия с аппаратурой и всё. Заняло буквально пару недель. По крайней мере без DMA, работа с USB там не сложнее работы с SPI. Ну конечно нужно более-менее знать как работает USB в целом. Пример инициализации USB есть в SPRUFM9H. Сначала тоже пытался выдирать что-то из Linux, но понял что гиблое это дело :)

По-крайней мере для L137/L138 - есть Jungo USB stack.

Отправка в control endpoint: u32 WriteEP0() { u8 *s; u32 n = MIN(ep0setup.f.len, EP0_FIFO_SIZE); ep0setup.f.len -= n; if (!((int)ep0ptr & 3)) for (; n >= 4; n -= 4) USB0.FIFO[0] = *ep0ptr++; for (s = (u8 *)ep0ptr; n; n--) *(u8 *)&USB0.FIFO[0] = *s++; ep0ptr = (u32 *)s; return (ep0setup.f.len) ? 1 << CSR0_TXPKTRDY: 1 << CSR0_TXPKTRDY | 1 << CSR0_DATAEND; }

Ну - это ничего страшного. Если конечно требуемое время реакции на прерывание позволяет, а по-моему DSP-система должна быть спроектирована так, чтобы не требовать времен реакции менее нескольких сотен мкс. Будет прерываться на границах цикла конвейера. 2 SAURIS GmbH: Что там у нас с аппаратными бряками на L137 + SAU ISO PLUS ? Есть прогресс?

Что значит - непрерывные? Вы имеете в виду - контекст DSP ядра при прерывании не сохраняется? Что-то сомнительно... PS: Сейчас работаю на L137

Судя по всему Вы затёрли часть бутлоадера. В даташите же ясно говорится, что бутлоадер занимает: 0x00000000 – 0x0001FFFF On-Chip Bootloader, т.е. - можно использовать от 0x00020000 и далее (если Вам не нужно то что там лежит). а Вы пишете от 0000F200h. А вообще - интересно каким образом JTAG шьёт во флеш? Я не очень представляю как этот процесс происходит здесь на OMAP-ах от TI, но на ARM от LPC JTAG напрямую не умеет ничего шить во флеш, для этого он грузит в ОЗУ программу, которая через API процессора (IAP) шьёт флеш из ОЗУ. Если здесь подобным образом, то возможно можно взять флеш от живого проца и прошить его в Ваш. Лишь бы JTAG мог стартовать с таким попорченным bootloader-oм. Например так: Считайте область 0x00000000 – 0x0001FFFF с живого проца в bin-файл, сконвертите его в массив unsigned char, создайте любой проект с пустой main() в ОЗУ, создайте там сегмент с тем массивом образа 0x00000000 – 0x0001FFFF, слинкуйте его на 0x00000000 – 0x0001FFFF и запустите проект. Либо может проще - в CCS через меню файл\data\load и потом файл\data\save.

У McASP (по крайней мере OMAP-L137) SCLK берётся от OSCIN с минимальным делителем == 1, т.е. - без PLL :(((((( А у McBSP дела обстоят по другому? (лень даташит на него искать)

Посмотрите в сторону McASP. У него в отличие от McBSP имеется как правило несколько сериализаторов - можно передавать несколько битовых потоков с одним клоком/фреймом параллельно. Т.е. - можно повысить скорость при той же частоте клока или уменьшить частоту клока при той же скорости.

Пытаюсь запустить EDMA3 McASP1->L2RAM. Получаю BusError в EDMA3TC[0].ERRDET. Думаю, что возможная проблема - с арбитражем доступа к L2RAM (DSP крутится в цикле в L2 и буфер DMA там же). Значит надо сконфигурить приоритеты доступа CPU и EDMA к L2RAM. В результате поисков в SPRS563 нашёл упоминание о регистре EDMAWEIGHT (L2 EDMA access control register), но нигде в даташитах на L137/C674x он не описан (только в старых даташитах типа spru610 на ядра C64x). Но самое главное, что занимаемый EDMAWEIGHT адрес (0x01841000) согласно SPRS563 (OMAP-L137 Low-Power Applications Processor (Rev. D)) занимает регистр CPUARBU согласно SPRUFK5 (TMS320C674x DSP Megamodule Reference Guide). У обоих доступ == R/W. Да и вообще все регистры "C674x Cache Registers" (SPRS563) конфликтуют с "Arbitration Registers" (SPRUFK5). Что за бардак? Кому верить??? Кто-нить сталкивался с этой проблемой?

Народ, кто-нить скачивал последний CCS4 (v4.2.4.00033) с сайта TI? Уже дважды скачал - сравнил побайтно - совпадают, но при попытке распаковать архив вылазит ошибка CRC. Пробовал распаковывать и winrar-ом и последним winzip-ом - один фиг. Если кто скачал, можете написать CRC или MD5 своего архива? А то на сайте TI их нету. у моего MD5 == 6517263279066d048fff250c285005cc

Ну что-ж - побуду бета-тестером. :) Хорошо - буду ждать результатов.

На Вашу dvr-ку ругается: Unable to load F:\CCS\drivers\tixds6400_plus.dvr CCS4 у меня нет. :(

А это где? Нашёл только в меню CCS Debug\real-time mode, но с ним не коннектится к процу

На DSP. Я ARM вообще ещё не трогал - пока в ресете. SR12_CCS_v3.3_SR_3.3.82.13 Это не может быть связано с тем, что я запретил адаптивное тактирование? Прикрепил картинку со свойствами аппаратного бряка, не знаю есть-ли там полезная информация.

Рано радовался - не работают аппаратные breakpoints :( Всё остальное, что успел попробовать - работает (и "step into" и "step over" и останов по shift+f5 и выполнение до курсора), видно CCS для этого использует программные точки. И на встроенном JTAG-е платы аппаратные точки работают, а вот с саурисом - нет :( Проходит точку как будто её и нет. Хотя конечно здесь не флеш - и программными можно пользоваться, но пропадает ряд возможностей.

Ураааа!! Заработало!!! :)))))))))))))) Только что. Заработало после того как _ОТКЛЮЧИЛ_ адаптивное тактирование (TCK freq == 15МГц). Все остальные настройки - как раньше. К ARM ядру мне удавалось подключиться только один раз после долгих перетыканий/передёргиваний всего и вся и больше этого повторить не удавалось. В меню "Debug" CCS есть "Advanced Resets/System Reset" и при его выборе, судя по всему, происходит реальный ресет DSP ядра судя по симптомам (в отличие от пункта меню "CPU Reset"). Софт записанный в SPI-flash не при чём - при включении без эмулятора он нормально работает (из DSP, ARM-ядро стоит). При переключении bootpins в состояние "emulation debug" софт не стартует, так что тут всё как ожидалось - ARM-ядро в ресете. Наверно в этом и было дело. Кстати - все тесты проходили на ура. Спасибо большое за помощь!!!! Вы сразу были правы, только надо было Ваш совет насчёт адаптивного тактирования проинвертировать ;) Не. Не мой случай. Во-первых - я изначально пробовал всё в режиме "emulation debug" и только потом поставил загрузку с FLASH SPI, во-вторых - ПО зашитое во flash SPI рабочее и нормально работает без JTAG и нормально стопается при подключении встроенного JTAG.

Нет. Просто в setup-e CCS создавал новую конфигурацию. Попробовал сейчас сделать импорт из sau510iso_omapl137.ccs - ничего не изменилось. В pod_drvr стоит драйвер сауриса. ccbrd0.dat: # config version=3.5 $ sepk pod_drvr=sm510usb.dll pod_scanloop=NO $ / $ c6000 scanloop=NO $ / $ sepk pod_aw_en=YES pod_slowclk=NO pod_emuversion=2 pod_dummy1=NO pod_tckexp=0 pod_tckdiv=10 $ / $ uscif clkmode=normal $ / $ sepk pod_tckpredivena=NO pod_no_tckr=NO pod_aclk_enable=YES $ / $ router adaptive_tclk=yes $ / $ sepk pod_tck_bpas_dly=0 pod_tckload=YES pod_tdoontckfall=NO pod_tms_ofs=0 pod_tdo_ofs=0 $ / $ uscif linkdly=3 $ / $ router skip_polling=Yes $ / @ icepick_c_0 family=icepick_c subpaths=3 & subpath_2 address=19 force=yes pseudo=no default=no custom=no @ etb11_0 family=etb11 & subpath_1 address=18 force=yes pseudo=no default=no custom=no @ arm9_0 family=arm9xx & subpath_0 address=17 force=yes pseudo=no default=no custom=no @ tms320c674x_0 family=tms320c64plus & / # /

CCS говорит что 510й. И работает с ним нормально в отличие от саурис. Адаптивное тактирование включено, файлы и для DSP и для ARM прописаны от платы (те же что и для XDS510). В L137 первым стартует DSP. Прицепил сюда (если получилось канеш) файл с экспортированной конфигурацией. Смущает наличие в нём строк типа "%DVRPATH%\tixds6400_plus.dvr" и подобных. Это вроде как для XDS? Или это нормально? mySetup.zip

Имеется отладочная плата TMDSOSKL137 (OMAP-L137) и SAU510-USB ISO PLUS JTAG (куплен недавно в Сканти). Данный эмулятор наотрез отказывается работать с этой платой, CCS говорит об ошибке: 0x80000244/-1060 Встроенный в эту плату отладчик (XDS-510) работает нормально, но хотелось-бы запустить на ней Sauris. С другими имеющимися в наличии платами на 5502 и 5509 sauris работает нормально. А с этой, максимум, что удаётся - инициализировать ARM-ядро, на DSP ядре спотыкается и пишет эту ошибку. CCS3.3, дрова с сайта sauris.de последние. Прошу помощи у представителей sauris или может кто сталкивался с такой проблемой?

Начинаем проект на новом процессоре F28M35H52C (TI Concerto Microcontrollers). В качестве JTAG-эмулятора собираемся приобрести SAU510-USB ISO PLUS JTAG. Вопрос к представителям Sauris - данный эмулятор поддерживает F28M35H52C ?

Да. Один проход цикла. Здесь же всё видно.

Примерно так (может где-то в мелочах только неточности за давностью лет ;) DATAcodec .sect ".dual:.DATAcodec" txPhasa .long 0 stepPhasa .long ... coefC3C4 .long -21812 << 16 | 2231 coefC1C2 .long 12864 << 16 | 83 coefC5 .word 7374 txAmpl .word -32768 .text .dp DATAcodec AMOV #DATAcodec, XDP MOV #stepPhasa, AR2 MOV #outbuf, AR0 BSET SXMD BSET ARMS BCLR SATD BCLR M40 BSET FRCT .arms_on MOV dbl(txPhasa), AC2 SFTL AC2, #1, AC0 SFTS AC0, #-17 ABS AC0, T3 ||MOV dbl(coefC3C4), pair(hi(AC0)) RPTBLOCAL cdc_1 ADD dbl(*AR2), AC2 ||MOV hi(AC2), AR1 MACMR coefC5, T3, AC1, AC3 ||BSET SATD MACR AC3, T3, AC0, AC3 ||MOV dbl(coefC1C2), pair(hi(AC0)) MACR AC3, T3, AC1, AC3 ||MOV hi(AC2), T2 MACR AC3, T3, AC0, AC0 ||SFTL T2, #1 MPYR T3, AC0, AC3 ||MOV dbl(coefC3C4), pair(hi(AC0)) SFTS AC3, #3 ||SFTS T2, #-1 XCC AR1 < #0 ||NEG AC3 MPYMR txAmpl, AC3 ||BCLR SATD cdc_1: MOV hi(AC3), *AR0+ ||ABS T2, T3

Конечно, я так и делал. И инициализированных (не нулями) переменных старался делать минимум. Еще, для уменьшения размера, перекомпилил rts55.lib, выбросив оттуда все ненужные функции.

Генератор синусоиды на полиноме 4-й степени (примерно 13 бит точности) на C5502 тратит 10 тактов на 1 отсчёт синуса при 32-битной фазе. Без stalls насколько помню.