[Poluektovich 0]

Хочу чтобы код определенной функции выполнялся из RAM. Для этого следовал рекомендациям:

Quote

Placing code in RAM using GCC

Gcc supports the use of the __attribute__ keyword which allows you to apply special attributes to your code. There are many attributes you can apply; the one we are interested in is section .

The section attribute places code in a specific memory section as defined in the cm3gcc.ld file. RAM is defined as the .data section. So, for example, if you wanted to place a function in RAM the code for the function prototype would look like this:

void foo (void) __attribute__ ((section(".data")));

 

Однако. код по-прежнему размещется во FLASH.

Изменено 1 августа, 2023 пользователем haker_fox
Перенесено в соответствующий раздел.

[_Pasha 0]

из чего это следует?

он во флеше для загрузки в RAM должен быть.

+ make clean надо сделать

Изменено 18 сентября, 2015 пользователем _Pasha

[DmitryM 0]

Хочу чтобы код определенной функции выполнялся из RAM. Для этого следовал рекомендациям:

 

 

Однако. код по-прежнему размещется во FLASH.

 

Вообще-то надо

void foo (void) __attribute__ ((section(".ramfunc")));

 

__attribute__ ((section(".data"))); - это для констант размещенных в RAM

[GenaSPB 11]

... И озаботиться тем, чтобы в ld script эта секция попадала в копируемые в ОЗУ данные.

Нолько на STM32F4xx это уже не требуется... Код в ОЗУ работает медленнеее чем из FLASH. На ATMEL SAM7 помогало.

STM32F446ZE_rom.zip

Изменено 19 сентября, 2015 пользователем Genadi Zawidowski

[Сергей Борщ 119]

__attribute__ ((section(".data"))); - это для констант размещенных в RAM

Да хоть горшком обзовите, только в печь не суйте. Какая линкеру разница, что конкретно за байты лежат в этой секции? Он не отличает коды команд от констант начальных значений. И решение с помещением кода в секцию .data - довольно элегантное: без дополнительных теловижений образ загружаемого в ОЗУ кода вместе с констанатами начальных значений размещается в ПЗУ, в ОЗУ под этот код резервируется место заодно с данными, стартап-код копирует образ кода из ПЗУ в ОЗУ вместе с начальными значениями данных. Я всегда добавлял в скрипт свою секцию рядом со входной секцией .data но так и не додумался сразу класть функции в секцию .data.

 

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

[_Pasha 0]

кста, вопрос.

как правильно сделать shared buffer?

например чтобы работать с областью ОЗУ как данными.

а затем скопировать код функции и запустить ее?

 

 

[GenaSPB 11]

помещением кода в секцию .data - довольно элегантное

Что-то из тулзов на атрибуты секции ругалось при таком решении... Потому я у себя оставил ramfunc.

 

работать с областью ОЗУ как данными. а затем скопировать код функции и запустить ее?

Делаете массив, заплолняете его кодами, затем вызываете начальный адрес как функцию (не забыть про thumb!).

 

uint32_t codes [77];
...
codes [0] = 0xXXXX;
...

((void (*)(void)) & codes [0]) ();

[_Pasha 0]

Делаете массив, заплолняете его кодами, затем вызываете начальный адрес как функцию (не забыть про thumb!).

Эта часть как раз понятна. Непонятно, что делать в скрипте линкера.

А если чтобы несколько функций на одни и те же адреса компилить?

Изменено 20 сентября, 2015 пользователем _Pasha

[GenaSPB 11]

в сообщении №4 лежит архив со скриптом линкера - там как раз используется "AT" - аналог того, что делал оператор ".phase" в древнем микрософтовском асемблере M80. Несколько таких заведите... с соответствующими дублированиями.

Изменено 20 сентября, 2015 пользователем Genadi Zawidowski

[scifi 1]

Делаете массив, заплолняете его кодами, затем вызываете начальный адрес как функцию (не забыть про thumb!).

+1. Я так обычно и делаю. Самый надёжный способ, и не требует настройки линкера.

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

Вот пример:

static const uint16_t jump2fw[] =
{
        0xF850, 0xDB04, /* LDR.W SP, [R0], #4   */
        0x6800,         /* LDR.W R0, [R0]       */
        0x4700,         /* BX R0                */
};

void func(void)
{
        ...
        ((void (*)(int*))(1 + (int)jump2fw))(&fw_start[2]);
}

[Poluektovich 0]

Спасибо за помощь. Размещение в .ramfunc сработало.

 

Раньше при попытке размещения в .data выдавался warning:

Warning: ignoring changed section attributes for .data

[sergvks 0]

Подскажите, как в GCC  описать внешнюю асмовскую функцию размещенную в ram, чтобы он правильно оформил её вызов?

 

[dimka76 42]

On 8/1/2023 at 4:12 PM, sergvks said:

Подскажите, как в GCC  описать внешнюю асмовскую функцию размещенную в ram, чтобы он правильно оформил её вызов?

У вас стартап на ассемблере ?

Если да, то в нем можно подглядеть

  .section  .text.Reset_Handler
  .weak  Reset_Handler
  .type  Reset_Handler, %function
Reset_Handler:  
  ldr   sp, =_estack     /* set stack pointer */

/* Copy the data segment initializers from flash to SRAM */  
  movs  r1, #0
  b  LoopCopyDataInit

 

[sergvks 0]

Спасибо! Добавил .type и всё заработало.