[VladislavS 29]

Еще один вопрос созрел. Мне нужен файл прошивки в simple-code. В документации вот что сказано:

BUILD CONSIDERATIONS

When you build an application that will be downloaded to flash, special consideration

is needed. Two output files must be generated. The first is the usual ELF/DWARF file

out) that provides the debugger with debug and symbol information. The second file

(is a simple-code file (filename extension sim) that will be opened and read by the flash

loader when it downloads the application to flash memory.

The simple-code file must have the same path and name as the ELF/DWARF file except

for the filename extension. This file is automatically generated by the linker.

 

Когда запускаешь отладку с прописанным флэшлоадером и правда появляется файл в simple-code. Но ведь как-то линкеру передаётся указание его сделать. Мистическое "This file is automatically generated by the linker" не может происходить самом собой. Как линкер узнает что НАДО ДЕЛАТЬ SIM?

[zltigo 0]

Непонятно ЗАЧЕМ? Неужели для совместимости c другими компиляторами?

Упаси бог - "совместимость" ни причем, скорее нарочитая несовместимость для того что-бы непонимающие сути сидели вечно на на одном компиляторе :). Вообще никогда не стоит пользоваться хидерами "любезно" предоставленными IAR, да и многими другими производителями тоже. Переписываете без специфичных наворотов и пользуетесь c любым компилятором.

 

 

 

 

Как линкер узнает что НАДО ДЕЛАТЬ SIM?

Не линкер.

Запускается objcopy и делает чего угодно из выходного файла линкера.

[VladislavS 29]

Не линкер.

В приведенной мной цитате говорится что именно линкер.

 

Запускается objcopy и делает чего угодно из выходного файла линкера.

Вот насчет "чего угодно" я что-то не нашел в его хэлпе ключа для simple-code. Не подскажете?

[zltigo 0]

Вот насчет "чего угодно" я что-то не нашел в его хэлпе ключа для simple-code. Не подскажете?

Не пользовался отладкой, не подскажу. Натравите на полученный "simple-code" objdump - что скажет?

[VladislavS 29]

C:\IAR\EWARM510\ARM\BIN\OBJCOPY.EXE: spi_loader.sim: File format not recognized

 

Вот. Всёже линкер, но как ему приказать?

[zltigo 0]

Вот.

Вообще-то речь шла об objdump, хотя, видимо и objcopy должен сказать чего-нибудь более разумное.

Всёже линкер, но как ему приказать?

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

[NikolaKirov 0]

Для 4 версии бъило:

Project Options -> Linker -> Output -> Format -> Debug information for C-SPY -> Allow C-SPY extra output file поставит галочку

Project Options -> Linker -> Extra Output -> Generate Extra Output File поставит галочку

Project Options -> Linker -> Extra Output -> Format -> Output format = simple-code

 

Для 5 кажется что так

Project Options -> Linker -> Output -> Include debug information in output

файл после компиляции в exe директории с разширением .sim

[VladislavS 29]

Вообще-то речь шла об objdump, хотя, видимо и objcopy должен сказать чего-нибудь более разумное.

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

 

objdump вообще как рыба об лёд, а командные строки я первым делом посмотрел - однохренственные до последнего символа.

 

 

PS:

 

С какого он секцию .intvec размером 0x40 размещает с 0x00000000 по 0x00000040 ? Раньше ему для этого хватало 0x00-0x3F и c 0x40 можно было что-то другое размещать. Теперь же только с 0x48.

[VladislavS 29]

С какого он секцию .intvec размером 0x40 размещает с 0x00000000 по 0x00000040 ? Раньше ему для этого хватало 0x00-0x3F и c 0x40 можно было что-то другое размещать. Теперь же только с 0x48.

 

В 5.11 пофиксили. Теперь .intvec как и прежде умещается в 0x00-0x3F.

 

 

Когда выдается совсем свободное время пробую перетаскивать проекты в 5-ю версию. С конфигами и кодом вроде никаких проблем - всё по migration guide получается. Один небольшой проект даже работает на железе. А вот отладка в C-SPY что-то не идет почеловечески никак. Работаю с J-Link. Макросы все те же. Но как-то непредсказуемо отладчик работает. То "застрянет" в любом месте, то наоборот вместо шага понесется дальше, то вообще на какое-нибудь прерывание свалится... И это даже на работающем проекте.

[elcielo 0]

I want EWARM 5.11.

plz help me.

[KRS 0]

А есть у кого __iar_data_init() в исходниках? А то привык в проекте cstartup.s79 , low_level_init.c и segment_init.c иметь. Пока только щупаю 5.10 - рабочие проекты на него еще не перевожу, но уже подумываю.

 

Т.к. пока приходится отлаживать через openOCD (в IAR 5.11 есть поддержка GDB server). Пришлось переходить на 5 IAR. Я тоже люблю цеплять свой стартап. Поэтому разобрался с принципиальным отличием 5 от перыдущих.

Раньше необходимые данные для инициализации сегментов генерил компилер в виде:

PUBWEAK ?init?tab?DATA_Z
        RSEG INITTAB:CODE:ROOT(2)
        DATA
?init?tab?DATA_Z:
        DCD      sfe(DATA_Z) - sfb(DATA_Z), sfb(DATA_Z), sfb(DATA_Z)

        PUBWEAK ?init?tab?DATA_I
        RSEG DATA_ID:CONST:SORT:NOROOT(2)
`?*?DATA_ID`:

        RSEG INITTAB:CODE:ROOT(2)
        DATA
?init?tab?DATA_I:
        DCD      sfe(DATA_I) - sfb(DATA_I), sfb(DATA_I), sfb(DATA_ID)

        END

и т.п. всякими хитрыми метками и директивами. что бы полностью выкинуть этот стартап. можно было в своем стартапе определить

        PUBLIC ?init?tab?DATA_I
?init?tab?DATA_I:
        PUBLIC ?init?tab?DATA_Z
?init?tab?DATA_Z:

и сегмент INITTAB не создавался и можно спокойно было инитить сегменты или не инитить...

 

Теперь принципиально идеология не поменялась просто все это свалили на линкер, поэтому он и не стандартный. Линкер генерит аналог INITTAB ( в который еще похоже добавили адрес функции инициализирующей...).

 

Но есть способ просто от этого всего избавится!

использовать do not initialize ( в том числе и для DATA_Z и заполнять 0 самому)

и initialize manually для сегментов, которые надо копировать (из флеша например)

ну и указать имя точки входа Override default program entry.

 

Для Coretx-M3 вообще можно обойтись без ASM, т.к. стек изначально сам проц инитит

 

uint32_t const __vector_table@".intvec" =
{
    STACK_TOP,
    (uint32_t)main,
            ......
};

а в icf файле 
place at start of ROM { section .intvec};

[IgorKossak 0]

I want EWARM 5.11.

plz help me.

Download 30-day evaluation edition, V5.11

[Vitaliy_ARM 0]

Недавно заметил тут такую штуку.

Создаю структуру:

 

typedef struct _MY_STRUCT

{

BYTE Cmd;

BYTE Rsv;

WORD K1;

DWORD Status;

BYTE K2;

}MY_STRUCT, *pMY_STRUCT;

 

BYTE TxData[100];

pMY_STRUCT pMyStr = TxData;

-----

делаю вызов функции Func(TxData, sizeof(MY_STRUCT));

 

И вижу, что sizeof(MY_STRUCT) возвращает не 9 (как написано в книжках по C/C++), а 12!

Понятно, что это делается для выравнивания данных в OЗУ по 4 байтным словам.

Жутко не удобно постоянно для каждой структуры объявлять длину через дерективы препроцессора.

Может можно это отключить, и сделать так, чтобы sizeof() возвращал количество байт?

Изменено 18 марта, 2008 пользователем Vitaliy_ARM

[KRS 0]

И вижу, что sizeof(MY_STRUCT) возвращает не 9 (как написано в книжках по C/C++), а 12!

Понятно, что это делается для выравнивания данных в OЗУ по 4 байтным словам.

Жутко не удобно постоянно для каждой структуры объявлять длину через дерективы препроцессора.

Это делается по стандарту, что бы структуры можно было объеденить в массив. (данные внутри одной структуры и так выравнены)

Единтсвенный известный мне способ - это #pragma pack. Но при этом если обращаться к такой структуре через указатель будет большой оверхид потому что компилер не будет знать выравнена она или нет.

[Vitaliy_ARM 0]

Это делается по стандарту, что бы структуры можно было объеденить в массив. (данные внутри одной структуры и так выравнены)

Единтсвенный известный мне способ - это #pragma pack. Но при этом если обращаться к такой структуре через указатель будет большой оверхид потому что компилер не будет знать выравнена она или нет.

 

Думаю придется обойтись директивами. Не хочется лишний раз использовать #pragma.