[doom13 0]

Разница, наверное, что один проект видит файл "boot.asm" - он лежит или в проекте, или где-то в путях доступен, а второй нет.

Проект отин и тот же только Debug Configurations разные запускаю, но по опциям они одинаковые, ну может не вижу чего.

Что касается останова в нем - надо где-то в опциях проекта (или отладки, не помню) убрать галку, говорящую, что надо автоматически дойти до main и остановиться на ней. Тогда она сразу остановится на _c_int00

Да, заработало. Я пытался поменять Run to symbol main на Run to symbol _c_int00, а надо было убрать галку. Стало заходить в boot.asm, но пошагово отследить, что и за чем следует, как Вы и говорите, нельзя, прыгает по чём попало и по коментам тоже.

Должно быть достаточно. Я не раз так делал, когда требуется модификация boot.asm, компилятор компилирует тот, что в проекте, а тот, что в либе, игнорирует.

Вот если boot.asm, который и открывается для одной из конфигураций, закинуть в проект или импортировать как File system -> link in workspace, то появляется такая вот ошибка:

[Sauris 0]

Это похоже какие-то опции сборки надо поставить (например -D <define>) для boot.asm, чтобы она не вызывала эту инициализацию xdc.

 

 

UPD:

Хотя... В исходнике "boot.asm" такого идентификатора не видно. Так что похоже Вы сами что-то туда лишнее еще притащили.

 

UPD2: Более того, во всей run time поиск по всем исходникам не дал ничего на тему этого символа.

 

UPD3:

 

А Вы откуда этот boot.asm вообще взяли? Надо из ccsvX\tools\compiler\arm_X.X.X\lib\src\boot.asm

Изменено 27 июня, 2014 пользователем SAURIS GmbH

[doom13 0]

Это похоже какие-то опции сборки надо поставить (например -D <define>) для boot.asm, чтобы она не вызывала эту инициализацию xdc.

UPD:

Хотя... В исходнике "boot.asm" такого идентификатора не видно. Так что похоже Вы сами что-то туда лишнее еще притащили.

UPD2: Более того, во всей run time поиск по всем исходникам не дал ничего на тему этого символа.

UPD3:

А Вы откуда этот boot.asm вообще взяли? Надо из ccsvX\tools\compiler\arm_X.X.X\lib\src\boot.asm

В том, который автоматом открывается что-то такое есть. Он открывается из c:\ti\xdctools_3_25_03_72\packages\ti\targets\arm\rtsarm\boot.asm

 

[Sauris 0]

В том, который автоматом открывается

 

Это XDC runtime - совсем и близко не то. Тот... Ну я уже сказал, где лежит

[doom13 0]

Это XDC runtime - совсем и близко не то. Тот... Ну я уже сказал, где лежит

Счас попробую прикрутить Ваш, но какого оно тогда его подтягивает и, когда галку с main убрал, в него и заходит?

[Sauris 0]

Ну видимо в пути поиска он первым стоит. Название файла одинаковое, его и отображает (но вовсе не в него заходит!). Просто подгружает файл и подсвечивает некую совершенно бредовую строку кода, согласно таблице номеров строк из совершенно отвлеченного объектного модуля.

[doom13 0]

У меня есть только c:\ti\ccsv5\tools\compiler\arm_5.1.1\lib\, в ней папки src с boot.asm нету!?

[Sauris 0]

У меня есть только c:\ti\ccsv5\tools\compiler\arm_5.1.1\lib\, в ней папки src с boot.asm нету!?

Значит сделайте ее, раскрыв тамошний архив rtssrc.zip туда. Или просто достаньте boot.asm из него

[doom13 0]

Значит сделайте ее, раскрыв тамошний архив rtssrc.zip туда. Или просто достаньте boot.asm из него

Помогло, прилинковал его к проекту, теперь обе конфигурации работают одинаково, заходят в один и тот же boot.asm и ходить по нему нормально стало.

 

Ещё добавил в include options данную папку и вообще шикарно стало, можно от _c_int00 по шагам добраться до main. При создании проекта почему-то подключает к пректу папку c:\ti\ccsv5\tools\compiler\arm_5.1.1\include, которой вообще нет, зачем? Это, по-идее, и болжна быть данная src с распакованным архивом?

[Sauris 0]

Помогло,

Кстати там четко откоментирован кусок, отвечающий за вход в user mode. Так что три движения мизинцем, и оно выключено.

[doom13 0]

Кстати там четко откоментирован кусок, отвечающий за вход в user mode. Так что три движения мизинцем, и оно выключено.

Да, так и сделал, спасибо за полезные советы.

 

[Sauris 0]

При создании проекта почему-то подключает к пректу папку c:\ti\ccsv5\tools\compiler\arm_5.1.1\include, которой вообще нет, зачем? Это, по-идее, и болжна быть данная src с распакованным архивом?

 

Она там есть. Ее не может там не быть. Там лежат все стандартные инклуды, "stdio.h", "stdlib.h", "limits.h" и пр. Без этого у Вас бы ничего бы вообще не скомпилировалось с применением стандартных #include

Изменено 27 июня, 2014 пользователем SAURIS GmbH

[doom13 0]

Она там есть. Ее не может там не быть. Там лежат все стандартные инклуды, "stdio.h", "stdlib.h", "limits.h" и пр. Без этого у Вас бы ничего бы вообще не скомпилировалось с применением стандартных #include

Да, есть, что-то я, наверное, не то смотрел.

 

[doom13 0]

Приветствую.

Возник вопрос с прерыванием, вся инициализация проделана по аналогии с примером (правильно), но не заходит в обработчик прерывания.

Нашёл, что перед main (в примере у которого всё работает) выполняется кусок кода, который копирует вектор прерываний:

static void CopyVectorTable(void)
{
    unsigned int *dest = (unsigned int *)0xFFFF0000;
    unsigned int *src =  (unsigned int *)vecTbl;
    unsigned int count;

    for(count = 0; count < sizeof(vecTbl)/sizeof(vecTbl[0]); count++)
    {
        dest[count] = src[count];
    }
}

, где 0xFFFF0000 - адрес ARM local RAM, у меня вектор прерываний лежал в On-Chip RAM, но при этом в Vector Base Register все адреса были прописаны правильно. Зачем нужно это копирование если адреса вектора прерываний и так были известны?

И второй вопрос по самому вектору:

static unsigned int const vecTbl[14]=
{
    0xE59FF018,
    0xE59FF018,
    0xE59FF018,
    0xE59FF018,
    0xE59FF014,
    0xE24FF008,
    0xE59FF010,
    0xE59FF010,
    (unsigned int)Entry,
    (unsigned int)UndefInstHandler,
    (unsigned int)SWIHandler,
    (unsigned int)AbortHandler,
    (unsigned int)IRQHandler,
    (unsigned int)FIQHandler
};

, что означают константы 0xE59FF018, ... , 0xE59FF010 в таблице?

[jcxz 181]

, где 0xFFFF0000 - адрес ARM local RAM, у меня вектор прерываний лежал в On-Chip RAM, но при этом в Vector Base Register все адреса были прописаны правильно. Зачем нужно это копирование если адреса вектора прерываний и так были известны?

Наверное контроллер прерывания AM1808 требует чтобы таблица векторов находилась с этого адреса.

Или вы спрашиваете почему на этапе компиляции вы сразу не разместили эту таблицу по адресу 0xFFFF0000?

Про AM1808 не знаю, но например в OMAP-L137 делается так же, там тоже вектора прерываний ARM-ядра прописываются в ARM local RAM уже после старта ПО.

Делается это по той причине, что первым в нём стартует DSP-ядро, ARM-ядро в это время в сбросе. Грузит и стартует прошивку DSP-ядро.

А оно не имеет доступа к ARM local RAM.