[jcxz 232]

16 минут назад, __inline__ сказал:

Пример взят у индусов и наверное из-за отсутствия слова volatile в регистрах - не работает. Надо посмотреть ассемблерный листинг.

Или проблема в другом?

...или AISgen-ом собрали неправильно. 

16 минут назад, __inline__ сказал:

 

Вначале из Blink.out делаю Blink.bin (AISGen-ом), затем bin гружу Uart boot host-ом

Вы что-ж - собрались что-то отлаживать без эмулятора???   На таком МК это - мазохизм. имхо.

[repstosw 18]

 

Quote

Вы что-ж - собрались что-то отлаживать без эмулятора???   На таком МК это - мазохизм. имхо.

Ну BF532 осилил же :) C6745 аналогично хочу.

Quote

...или AISgen-ом собрали неправильно. 

Вот с такими настройками делал, посмотрите пожалуйста, что не так?

 

[repstosw 18]

Всё, разобрался.

Дофига чего инитить нужно было. Ниже рабочий код мигания светодиода на 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

 

[repstosw 18]

Разобрался с 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 штук пустых плат. Отдам недорого.

Изменено 4 марта, 2019 пользователем repstosw

[aaarrr 69]

2 hours ago, __inline__ said:

Кеширование кода и данных естественно - не задействовано(выключено), чтобы работа с SDRAM была не в пакетном режиме.
Адресное пространство SDRAM (32 МБ) объявлено как volatile, что исключает оптимизацию компилятора - для гарантированного обращения к каждой ячейке памяти.

Что же тут "естественного"? Для полноценного теста нужно работать с памятью максимально быстро.

[jcxz 232]

3 часа назад, __inline__ сказал:

Короче, SDRAM работает нормально, что и радует! :)

Тесты чтения/записи только. А теста рефреша нет.  

3 часа назад, __inline__ сказал:

Кеширование кода и данных естественно - не задействовано(выключено), чтобы работа с SDRAM была не в пакетном режиме.

Не понял - у Вас что код теста в SDRAM находится? Если да - то зачем??? Ведь в C6745 вроде внутренняя ОЗУ есть.

[repstosw 18]

2 hours ago, aaarrr said:

Что же тут "естественного"? Для полноценного теста нужно работать с памятью максимально быстро.

Мне важно было убедиться в том, что нет интерференционных наводок и сбития битов на адресных линиях и линиях данных.  Включенный кеш делает тест нечестным, так как он минимизирует обращение к памяти.  Ясен пень, что аппликухи должны пускаться с настроенным кешированием

57 minutes ago, jcxz said:

Тесты чтения/записи только. А теста рефреша нет.  

Не понял - у Вас что код теста в SDRAM находится? Если да - то зачем??? Ведь в C6745 вроде внутренняя ОЗУ есть.

Тест рефреша - это как? Каков его алгоритм? Хочу добавить!

Код находится там куда загрузчик ROM загрузил.  В SDRAM пока находтся абстрактные данные.  В будущем буду грузить туда мега-тонные программы

[jcxz 232]

1 час назад, __inline__ сказал:

Тест рефреша - это как? Каков его алгоритм? Хочу добавить!

У меня в практике был случай когда в плате оказался дефектный чип DRAM. Все штатные тесты памяти ошибок в нём не обнаруживали. Но если в нём расположить код или данные - ПО глючило. После разбирательств я установил, что запись данных в него и последующее после записи первое чтение проходили нормально, но вот или второе или последующие чтения - возвращало мусор. Не всегда разрушение происходило при втором чтении, иногда оно давало ещё валидные данные. А штатные тесты делали просто запись и потом одно чтение/сравнение - поэтому не обнаруживали такого дефекта чипа.

Как я понимаю работу DRAM: при каждом чтении ячейки, содержимое её разрушается и DRAM должна его переписать обратно. Вот этот узел в том чипе и не работал.

С тех пор я во всех тестах DRAM делаю многократное чтение после записи.

Цитата

Код находится там куда загрузчик ROM загрузил.  В SDRAM пока находтся абстрактные данные.  В будущем буду грузить туда мега-тонные программы

Нет - код находится там, куда Вы указали при сборке .ais-образа.   Если Вы указали внутреннюю ОЗУ, то смысла включать кеширование кода особого нет. Ну будет незначительный эффект если закешировать 2-х или 3-х тактную внутреннюю ОЗУ, но практически незаметный (по моему опыту OMAP L137). Так что и обращать внимание "включен" или "выключен" кеш кода - тоже смысла нет.

А если Вы слинковали код в .ais - в SDRAM, то это как-то странно для кода теста SDRAM.

[repstosw 18]

11 minutes ago, jcxz said:

Нет - код находится там, куда Вы указали при сборке .ais-образа.   Если Вы указали внутреннюю ОЗУ, то смысла включать кеширование кода особого нет. Ну будет незначительный эффект если закешировать 2-х или 3-х тактную внутреннюю ОЗУ, но практически незаметный (по моему опыту OMAP L137). Так что и обращать внимание "включен" или "выключен" кеш кода - тоже смысла нет.

А если Вы слинковали код в .ais - в SDRAM, то это как-то странно для кода теста SDRAM.

Разве в AISgen можно указать стартовый адрес для кода?  Картинка ниже.

Может имели в виду, что CMD-файл надо править, где расписаны регионы и их адреса?

Пользуясь случаем задам вопрос, как можно базовые адреса секций программы менять?  RO, RW, ZI, Stack, Heap ?

 

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

[aaarrr 69]

2 hours ago, __inline__ said:

Включенный кеш делает тест нечестным, так как он минимизирует обращение к памяти.

Ровно наоборот: он весьма "уплотняет" общение с памятью. Если что, видел изделия, где без кэша такие тесты проходили, а с ним - нет.

[jcxz 232]

3 часа назад, __inline__ сказал:

Может имели в виду, что CMD-файл надо править, где расписаны регионы и их адреса?

Да. Только его надо не править, его надо делать.  Под задачу.  

Цитата

Пользуясь случаем задам вопрос, как можно базовые адреса секций программы менять?  RO, RW, ZI, Stack, Heap ?

Не понял вопроса.... 

У секций программы нет адресов, они линкуются компоновщиком в какие-то регионы и в результате получают адреса. А RO, RW - это вообще атрибуты регионов памяти.

Директива MEMORY (.cmd-файла) определяет регионы и их атрибуты, а директива SECTIONS - задаёт какую секцию .obj-файлов в какой регион линковать.

[repstosw 18]

Рефреш-тест тоже проходит нормально. Делаю 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 ?

Референс мануал ничего по этому поводу не пишет.

Где можно подсмотреть?

[jcxz 232]

53 минуты назад, __inline__ сказал:

Надо включить Data Cache.

В своих старых исходниках нашёл только это (в самом начале main()):

  CACHE.L1DCFG = 7;
  { u32 i = CACHE.L1DCFG; }
  CACHE.L1DCC = 0;

Видимо конфигурю только кеш данных. Помню что у меня были какие-то проблемы с конфигурением кеша в DSP-ядре. Но потом я все быстрые данные и код DSP-ядра разместил во внутренней памяти и DSP-ядро мало обращалось к SDRAM (с ней работало в основном ARM-ядро). Только при (пере-)инициализации, когда скорость не важна. Поэтому у меня кеш не сильно влиял на работу DSP. И поэтому я глубоко не разбирался с кешем DSP. Только разбирался с кешем ARM.

Цитата

Референс мануал ничего по этому поводу не пишет.

Где можно подсмотреть?

Ну так наверное тут: SPRUG82— TMS320C674x DSP Cache User's Guide.

http://www.ti.com/lit/pdf/sprug82

[repstosw 18]

Спасибо за помощь.

Вышеприведенного кода оказалось недостаточно для того чтобы закешировать 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 марта, 2019 пользователем repstosw

[repstosw 18]

Ещё задействовал L2 в качестве кеша (максимально получилось оттяпать 128кБ, при  256 кБ программа не запускается, потому что она перетирается кешем L2):

 L2CFG=0x3;   //128 kB L2

Итого время тестов сократилось ещё на 24%.

 

Вот бы ещё L1P для кода задействовать.   И что важно перед тем как туда (на внешнюю память) прыгнуть, надо сбросить L1D (flush) чтобы конец образа программы гарантированно лег в SDRAM. Я на Блекфинах на этом моменте собаку съел )) использовал flush_data_buffer()