-
Постов
2 650 -
Зарегистрирован
-
Победитель дней
2
Весь контент repstosw
-
Ещё задействовал L2 в качестве кеша (максимально получилось оттяпать 128кБ, при 256 кБ программа не запускается, потому что она перетирается кешем L2): L2CFG=0x3; //128 kB L2 Итого время тестов сократилось ещё на 24%. Вот бы ещё L1P для кода задействовать. И что важно перед тем как туда (на внешнюю память) прыгнуть, надо сбросить L1D (flush) чтобы конец образа программы гарантированно лег в SDRAM. Я на Блекфинах на этом моменте собаку съел )) использовал flush_data_buffer()
-
Да ладно, не язвите. Поугорали и хватит))) Я запустил DSP - и уменя сегодня праздник!!!
-
Спасибо за помощь. Вышеприведенного кода оказалось недостаточно для того чтобы закешировать SDRAM. На гитхабе в ccslearning-master было упоминание о MAR-регистрах. Поиск вывел меня на даташит: TMS320C674x DSP Megamodule Оказалось, что эти самые MAR-регистры задают регионы кеширования. И по дефолту регистры MAR192 и MAR193 (они отвечают за адреса 0xC0000000...0xC1FFFFFF, которые используются SDRAM ) с выключенным кешированием. Младший бит этих регистров был равен 0 (проверял), удалось их установить в 1 (операция привелегированная : требуется SuperVisor Mode, который как оказывается у меня был). После этого время теста на 32-битных записях уменьшилось в 3 раза! Попробовал убрать инит MAR-регистров, всё вернулось как без кеширования. Полная функция включения кеша L1D для SDRAM 32 МБ на EMIFB - выглядит так: void Enable_DCache(void) //Enable D-Cache { L1DWB=0x01; //Flush L1D L1DCFG=0x07; //Reconfigure L1D to default state (full cache) MAR192=0x00000001; //0xC0000000..0xC0FFFFFF cacheble MAR193=0x00000001; //0xC1000000..0xC1FFFFFF cacheble } Про кеширование доки слишком сложные, для моего понимания, а вот хочется максимально выжать с внешней памяти производительность на чтение-запись данных и выполнение кода. Так как внутренней памяти мне не хватит - она пойдет под стек, кучу и DMA.
-
Рефреш-тест тоже проходит нормально. Делаю 4 чтения каждой ячейки после записи. Не совсем понятно про кеширование данных. Надо включить Data Cache. Нашёл только вот это: void Enable_DCache(void) //Enable D-Cache { L1DWB=0x01; //Flush L1D L1DCFG=0x07; //Reconfigure L1D to default state (full cache) } Подозреваю, этого мало. А как политику кеша настраивать : Write Back, Write Throw ? И как закешировать к примеру, только регион SDRAM - все 32 мегабайта начиная с адреса 0xC0000000 ? Референс мануал ничего по этому поводу не пишет. Где можно подсмотреть?
-
Завидуйте молча! :)
-
Разве в AISgen можно указать стартовый адрес для кода? Картинка ниже. Может имели в виду, что CMD-файл надо править, где расписаны регионы и их адреса? Пользуясь случаем задам вопрос, как можно базовые адреса секций программы менять? RO, RW, ZI, Stack, Heap ? А на счет идеи потестить с рефрешем я понял. Просто добавить многократное чтение каждой ячейки с проверкой на обнаружения факта разрушения данных в каждой ячейки после первого чтения.
-
Мне важно было убедиться в том, что нет интерференционных наводок и сбития битов на адресных линиях и линиях данных. Включенный кеш делает тест нечестным, так как он минимизирует обращение к памяти. Ясен пень, что аппликухи должны пускаться с настроенным кешированием Тест рефреша - это как? Каков его алгоритм? Хочу добавить! Код находится там куда загрузчик ROM загрузил. В SDRAM пока находтся абстрактные данные. В будущем буду грузить туда мега-тонные программы
-
Всё взлетело и работает как надо!!! Подробности тут: https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=150590&page=3 Есть 11 штук свободных плат. Пишите в личку, цена договорная.
-
Разобрался с PLL (файлы проекта PLL.c/PLL.h), выставил такой режим: частота ядра: 456 МГц частота шины EMIFB: 152 МГц (SDRAM) частота шины EMIFA: 91.2 МГц (пока свободна) Проинитил SDRAM (файлы проекта EMIFB.c/EMIFB.h) MT48LC16M16 на частоту 152 МГц (6.5 нс). Это максимальная частота шины по даташиту на C6745. Сама память ещё более быстрая 166 МГц (6 нс). --- Накатал тест памяти (файлы проекта MemTest.c/MemTest.h). Несколько тестов: запись словами по 8,16,32,64 байт. 16 типов шаблонов: const u64 Patterns[]= { 0x0000000000000000ULL, 0xFFFFFFFFFFFFFFFFULL, 0x5555555555555555ULL, 0xAAAAAAAAAAAAAAAAULL, 0x1111111111111111ULL, 0x2222222222222222ULL, 0x4444444444444444ULL, 0x8888888888888888ULL, 0x3333333333333333ULL, 0x6666666666666666ULL, 0x9999999999999999ULL, 0xCCCCCCCCCCCCCCCCULL, 0x7777777777777777ULL, 0xBBBBBBBBBBBBBBBBULL, 0xDDDDDDDDDDDDDDDDULL, 0xEEEEEEEEEEEEEEEEULL, }; Вначале идёт заполнение всеми шаблонами по-очереди, затем заполнение отдельным шаблоном. А также дополнительный тест - запись псевдо-случайными числами. Код функции Random() такой: u32 Seed; u32 Random32(void) { register u32 c=0x21; register u32 a=Seed; register u32 b; m0: b=a; a+=a; if(a>b) goto m1; a^=0xC5; m1: c--; if(c) goto m0; Seed=a; return Seed; } Seed перед использованием Random32() надо проинитить простым числом (используется 0x7FFFFFFF). Тест всей памяти идёт около 4 минуты 20 секунд (последние тесты с Random вносят задержку). Если что-то не так, то тестирование памяти прекратится и светодиод на порте GP0[0] будет быстро моргать (интервал 100 мс). Если всё ОК и тест пройден, то светодиод будет медленно мигать (интервал 1 с). Кеширование кода и данных естественно - не задействовано(выключено), чтобы работа с SDRAM была не в пакетном режиме. Адресное пространство SDRAM (32 МБ) объявлено как volatile, что исключает оптимизацию компилятора - для гарантированного обращения к каждой ячейке памяти. --- При написании программ усердно курю Reference Manual на C6745 и поглядываю на следующие сорцы: c6000-evi-lib-master.zip и C6745-master.zip (оба качаются с GitHub). В первом проекте регистры периферии почему-то объявлены без VOLATILE, что приводит к неправильной работе программы, когда она Release, а не Debug и со включенной оптимизацией. В частности при настройке PLL без volatile повисало на втором цикле: while(PLL0_PLLSTAT&0x1==1){} В моих исходниках все хедеры с регистрами исправлены, всё работает на максимальном уровне оптимизации. Во втором проекте автор не выложил хедеры. --- Обнаружил, что размер данных unsigned long int не 4, а 8 байт. В ARM 4 байта, а тут 8! Протестил остальные типы: sizeof(unsigned char)=1 sizeof(unsigned short int)=2 sizeof(unsigned int)=4 sizeof(unsigned long int)=8 - НЕ СОВМЕСТИМО С ARM !!! sizeof(unsigned long long)=8 При портировании это надо учитывать! --- Токи потребления на частоте ядра 456 МГц, SDRAM 152 МГц при выполнении MemTest: Ядро 1.3V: 210 мА - пиковое значение Периферия 3.3V: 90 мА - пиковое значение C6745 и SDRAM слегка тёплые. LDO на 1.3V сильно тёплый - пиковая рассеиваемая мощность на нём 0.777 Вт = (5 V - 1.3 V)*0.21 A Как я говорил уже, на отладочной плате предусмотрены перемычки для исключения штатных LDO и запитки от других источников питания - к примеру, от более экономичных DC/DC. Короче, SDRAM работает нормально, что и радует! :) Исходники, весь проект MemTest на CCS: 1_Blink.rar Если кому-то понадобятся платы под этот DSP пишите в личку - в наличии 11 штук пустых плат. Отдам недорого.
-
Всё, разобрался. Дофига чего инитить нужно было. Ниже рабочий код мигания светодиода на GP0[0]. #define u32 unsigned int #define SYSCFG_0_REGS 0x01C14000 #define GPIO_0_REGS 0x01E26000 #define PSC1_BASE 0x01E27000 #define PSC1_MDCTL (PSC1_BASE+0xA00) #define PSC1_MDSTAT (PSC1_BASE+0x800) #define KICK0R (*(volatile u32*)(SYSCFG_0_REGS+0x038)) #define KICK1R (*(volatile u32*)(SYSCFG_0_REGS+0x03c)) #define PINMUX13 (*(volatile u32*)(SYSCFG_0_REGS+0x154)) #define GPIO_DIR01 (*(volatile u32*)(GPIO_0_REGS+0x10)) #define GPIO_OUT_DATA01 (*(volatile u32*)(GPIO_0_REGS+0x14)) #define GPIO_SET_DATA01 (*(volatile u32*)(GPIO_0_REGS+0x18)) #define GPIO_CLR_DATA01 (*(volatile u32*)(GPIO_0_REGS+0x1C)) #define PSC1_PTCMD (*(volatile u32*)(PSC1_BASE+0x120)) #define PSC1_PTSTAT (*(volatile u32*)(PSC1_BASE+0x128)) void Unlock_Hardware(void) { KICK0R=0x83E70B13; KICK1R=0x95A4F1E0; } void PSC1_lPSC_enable(u32 PD,u32 LPSC_num) { *(volatile u32*)(PSC1_MDCTL+4*LPSC_num)=(*(volatile u32*)(PSC1_MDCTL+4*LPSC_num)&0xFFFFFFE0)|0x0003; PSC1_PTCMD=0x1<<PD; while((PSC1_PTSTAT&(0x1<<PD))!=0); //Wait for power state transition to finish while(((*(volatile u32*)(PSC1_MDSTAT+4*LPSC_num))&0x1F)!=0x3); } void Delay(volatile u32 ms) //for 24 MHz & disabled cache { volatile u32 i; while(ms>0) { for(i=0;i<1725;i++); ms--; } } void main(void) { Unlock_Hardware(); //unlock registers PINMUX13|=0x08000000; //select function GP0[0] PSC1_lPSC_enable(0,3); //enable GPIO GPIO_DIR01&=0xFFFFFFFE; //GP0[0] output while(1) { GPIO_SET_DATA01=0x00000001; //set GP0[0] Delay(1000); GPIO_CLR_DATA01=0x00000001; //clear GP0[0] Delay(1000); } } Прошивка, сгенерированная в AISgen для загрузки по UART с помощью UART Boot Host ниже. Blink.bin
-
Ну BF532 осилил же :) C6745 аналогично хочу. Вот с такими настройками делал, посмотрите пожалуйста, что не так?
-
Ok, спасибо за помощь! Создал в CCS 5.5.0.00077 проект - просто моргать диодом на порте GP 0.0 - не работает , но загружается. Код: Окно загрузки: Пример взят у индусов и наверное из-за отсутствия слова volatile в регистрах - не работает. Надо посмотреть ассемблерный листинг. Или проблема в другом? В проекте надо менять настройки (типа базовый адрес приложения итп)? Вначале из Blink.out делаю Blink.bin (AISGen-ом), затем bin гружу Uart boot host-ом
-
так, всё-же нашел здесь в самом конце: https://e2e.ti.com/support/processors/f/791/t/740404 могиканы получаются какие-то, попрятали всё. Или я всё проспал? ;-) На всякий случай прикреплю сюда, чтоб не потерять. sprabb1c.zip
-
Не могу найти AISgen и UARTHost для D800K005 (я так понимаю, что он для C6745). Нашёл только для D800K008. Техасцы порезали все ссылки на скачивание материала для C6745. Поделитесь пожалуйста для D800K005, а то застопорился весь процесс......
-
Пришли платы, распаял минимум, подключил к RS-232 ПК - по крайней мере BOOTME есть. На каком этапе были у вас проблмы с загрузкой? Кстати, сделали аж 12 штук печатных плат. Пишите в личку если кому надо, отдам недорого.
-
С6745 и SDRAM от индийских коллег
repstosw ответил repstosw тема в Работаем с трассировкой
Вы ещё побайтово сравните варианты разводки, чтоб отличия увидеть. Ну и индусов обижать не стОит - они тоже люди. А то так можно в бан попасть -за расовую дискриминацию на форуме. :-E -
Угодили в ловушку шаблонного мышления! "Должен, но не обязан!..." Ещё раз посмотрите на фрагмент схемы подключения кварца и нагрузочных банок в даташите: Причем, смотрите до просветления. И теперь в схеме: Понимаете, теперь, куда идёт GND кварца и банок? На OSCVss - специальный пин, который =GND и является фильтровым. P.S. Что-то нынешнее поколение электронщиков совсем слабое пошло, не тто что 10-15 лет назад... Никакого креатива, одно шаблонное мышление. Шаг в сторону - и уже неправильно. Огорчает!
-
Может быть я что-то пропустил пока спал, но с каких пор входы LDO защищают от статики? Оно же дубовое и низкоомное + 2 сплошных слоя (GND Vcc).
-
Я не совсем понимаю что там защищать от статики? Vcc и GND ? Зарядка USB - одно название там - и используются выводы + и -. Порта USB там нет вообще. Или подключение к ПК? Так там своя защита стоит. Пускай защищается. можно и так. Всегда стараюсь предусмотреть множество вариантов
-
Отбросив категоричность и неукоснительность следования даташитам, руководствовался следующим: 1) Теплообмен наверняка приведён для наижесточайших условий: выскокая температура окружающей среды, непрерывная работа платы 24 часа в сутки, максимальная нагруженность всех линий порта. При моих условиях эксплуатации - комнатная температура, часть портов останется незадействованными, подключенная периферия к портам слаботочная - не требуется экстремальное отведение тепла. До этого работал с ADSP BF532/533 - разгонял их до 600-700 МГц и испытывал в течение суток. Корпус микросхемы был тёплым, но не горячим. И средств для отвода тепла у Блекфинов нет. 2) Неуж-то толщина фольги 40 микрон способна настолько хорошо отводить тепло, чтобы стоило заморачиваться и делать весь полигон на GND? Весь пар уйдёт в объемный радиатор из припоя, который при желании можно нарастить любой толщины. 3) Теплопроводность через толстые металлизированные VIA и текстолит на внутренние слои будет всёравно, думаю, такого охлаждения будет достаточно. 4) Ядро в пике ест 660 мА при 1.3V - это 0.9 Вт максимум - не та мощность чтобы ставить рёбра и вентиляторы. Особенно при наличии пункта 1) выше. 5) И даже если будет греться, то буду наращивать припоем сзади, как это сделано в приводе CD от автомагнитолы. А также мне не понятен сарказм Чебурашки пользователя EvilWrecker по поводу разводки кварца - я делал всё по даташиту. Картинка ниже. Из моей схемы: И что тут не так??? Вся схема тут: http://www.picshare.ru/uploads/190218/G2KVQKmE92.png По USB вообще смешно - его тут нет вообще! Лудим Termal Pad на пузе процессора перед пайкой, покрываем анктивным флюсом. Припаиваем все ножки микросхемы. Затем с обратной стороны припоем ПОС-61 феном или мощным паяльником. Уже не впервые. Отверстия достаточно большие, чтобы туда скошенным жалом паяльника лезть
-
Это не догма. Тепло всёравно будет рассеиваться на тот маленький полигон 5x7 + на остальную часть меди которая вокруг. Не вижу смысла делать всё сплошным как в даташите. Потому что пузо микросхемы не металлическое, а из пластика. Тем более львиная часть тепла уйдет в объёмный припой и во внутренний слой GND. Взрыва не будет, это точно! А нафиг он там сдался, этот via-шаринг? Земля кварца идёт к ноге 144 OSCVSS напрямую. Как и рекомендовано в даташите. Время покажет, кто был прав!
-
Что касается заземление камня: "а почему бы и нет???" Это единственный вывод который GND, его размер 5x7 мм по-грубому и всё уходит на внутренний сплошной слой GND, via без маски - туда будем припой заливать, чтоб обеспечить хорошо теплоотводимый контакт и надежную GND с минимальным омическим R :) На счёт избытка блокировочных "булок" и размещения под процессором - ну так захотелось! Тем более так делают на материнках ПК - и ничего всё работает. На счёт земляного пина - он один - и это Termal Pad, нету других выводов GND. На счёт USB - где вы его увидели? :) Будет питаться от USB-зарядки, которая в розетку с током отдачи 1,5-2A. Так как от ПК такую штуку питать крайне опасно (малый ток 0.5A). На счёт земли кварца и конденсаторов - всё согласно даташиту на C6745. Там есть отдельный фильтровой вывод земли. Так что пусть вас не удивляет отсутствие соединения земли кварца с GND напрямую ))) Про LDO - вопрос вкуса, о котором не спорят. Но в целом - спасибо за ваш комментарий! Кто следующий? :)))
-
У меня есть SDK с примером как правильно инитить SDRAM на этом DSP. Так что если не заработает или будет глючить - буду биться об стену ))) Но почему-то я уверен, что заработает. Изначально хотел резисторы на 33 Ом на линии данных и адреса поставить, но увидев плату от индусов(фото выше) и раздолбанную авто-магнитолу с CD-приводом, решил не ставить их. Потом длина проводников. Не превышает 5,5 см. Это 0.18 нс - против 6 нс памяти: или 1/32 часть. Не думаю что здесь выравнивание дорожек сыграет роль. CLK, CLKE включены наикратчайшим образом. Соседние трассы на бОльшем расстоянии, чем 0.2 мм. Земляной полигон на расстоянии 0,12 мм препрег 1080 с диэл. проиницаемостью 3.9 при толщине фольги 18 мкм + 25 мкм осаждение; и ширина проводника 0.2 мм - даёт где-то 50-60 Ом. С маской будет чуть-меньше. Ну и чем ближе земля тем более ослабление crosstalk (зависимость обратно-квадратичная от расстояния). Резюме: почему может глючить? :)
-
С6745 и SDRAM от индийских коллег
repstosw ответил repstosw тема в Работаем с трассировкой
Сделал как у индусов, только память подвинул ещё ближе: https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=150876