IAR Embedded Workbench

[Serega_B]

не совсем понял пока с volatile.

Дело не в структуре, а в volatile. Компилятор сообщает что не обеспечивает атомарность операции сравнения.

volatile int a,b;
int c;
...
//Здесь ДОЛЖЕН ругнуться
if (a›b){
}
...
//а при таком порядке - не должен
c=a;
if (c›b){
}

[viruswin32porexb]

Пишу бутлоадер в Иаре, который мне уже весь мозг вынес. Язык С++. Бутлоадер объединен с другим проектом, поэтому в памяти программ выделено 2 сегмента: один с адреса 0x00000 до 0x1e000 (пространство для основного приложения), второй соответственно с 0x1e000 до конца памяти (это пространство для самого бутлоадера). Проблема в следующем. Дело в том, что когда я использую операторы сдвига впроцедурах, которые находятся в секции бутлоадера, типа:

void tempBootloader() @ "BOOTLOADER"
{
  for (uchar i=0;i‹sizeof(length);i++)
  {
      unsigned long length=0;
      unsigned char tempLength=12;

      length|=tempLength‹‹(8*i);        //вот в этом месте начинаются баги
  }
}

то в дизассемблере видно, что IAR вставляет в эту строку кусок кода, который находится за пределами секции бутлоадера. Выглядит это примерно так:

      length|=tempLength‹‹(8*i);
    01E084   8108             LD      R16,Y
    01E086   E010             LDI     R17,0x00
    01E088   E028             LDI     R18,0x08
    01E08A   9E42             MUL     R4,R18
    01E08C   2D40             MOV     R20,R0
    01E08E   940E 9CEE        CALL    ?S_SHL_L02
    01E092   2F21             MOV     R18,R17
    01E094   0F22             LSL     R18
    01E096   0B22             SBC     R18,R18
    01E098   2F32             MOV     R19,R18
    01E09A   2B80             OR      R24,R16
    01E09C   2B91             OR      R25,R17
    01E09E   2BA2             OR      R26,R18
    01E0A0   2BB3             OR      R27,R19

В 6 строке сверху происходит вызов некой подпрограммы ?S_SHL_L02, начало которой берется по адресу 0139DC:

?S_SHL_L02:
    0139DC   954A             DEC     R20
    0139DE   F01A             BRMI    0x139E6
    0139E0   0F00             LSL     R16
    0139E2   1F11             ROL     R17
    0139E4   CFFB             RJMP    ?S_SHL_L02
    0139E6   9508             RET

А теперь, когда я выполняю стирание страницы, то соответственно стирается и подпрограмма ?S_SHL_L02. Когда я повторно вызываю функцию tempBootloader(), то при выполнении мы снова попадем в ?S_SHL_L02, но на этот раз там уже ничего не будет, только 0xff-фы, т.к. страница то стерлась уже. Вот и все, приехали. Бутлоадеру сорвало крышу.

Теперь собственно вопрос: Как сделать так, чтобы IAR не вставлял вот такие вставки кода, который выходит за пределы сегмента BOOTLOADER?

можно конечно, сделать какой-нибудь макрос или инлайн функцию, но это не удобно, т.к. ситуации могут быть разные и для каждой писать что-то новое - не лучший выход. К тому же неизвестно как оно будет компилиться на других машинах.
Я еще заметил, что иногда компилятор вставляет что-то подобной в начале процедур. Но эта проблема решается, если при ее определении перед именем и типом написать строку __C_task. Что-же касается вставок в середине процедур - я в тупике.

[Hives]

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

[viruswin32porexb]

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

Задача стоит в том, чтобы совместить два проекта в один.

[Hives]

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

[skrynia]

viruswin32porexb,
попробуйте разбить операцию

length|=tempLength‹‹(8*i);

на несколько элементарных, вдруг что-то поменяется в листинге.

[Hives]

и я, кстати, не понял, в чем великий смысл этого цикла - он же заменяется на одну операцию: len |= 0x0c0c0c0c;

[skrynia]

void tempBootloader() @ "BOOTLOADER"
{
  for (uchar i=0;i‹sizeof(length);i++)
  {
      unsigned long length=0;
      unsigned char tempLength=12;

      length|=tempLength‹‹(8*i);        //вот в этом месте начинаются баги
  }
}

В цикле объявлена переменная length, которая инициализируется в 0 каждым проходом цикла?

[viruswin32porexb]

Код:

void tempBootloader() @ "BOOTLOADER" { for (uchar i=0;i‹sizeof(length);i++) { unsigned long length=0; unsigned char tempLength=12; length|=tempLength‹‹(8*i); //вот в этом месте начинаются баги } }

В цикле объявлена переменная length, которая инициализируется в 0 каждым проходом цикла?

Да это я просто тестовый пример сделал, смысла в нем нет, просто объяснил ситуацию.

На данный момент сделал обычные процедуры сдвига, типа:

unsigned long ShiftLeft(unsigned long y, uchar z) @ "BOOTLOADER"
{
  while(z)
  {
    y=y‹‹1;
    z--;
  }
  return y;
}

поэтому строка length|=tempLength‹‹(8*i); теперь выглядит вот так:

length|=ShiftLeft(tempLength, 8*i);

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

[skrynia]

Почему же тогда оно не стирается, когда процедура не входит в сегмент бутлоадера, остается загадкой месяца

Если хотите писать Flash, то команда SPM должна физически находиться в секции бута:

While the application section is used for storing the application code, the The Boot Loader software
must be located in the BLS since the SPM instruction can initiate a programming when
executing from the BLS only.