Преамбула
Изначально вторая глава задумывалась только, как шпаргалка по работе из оперативной памяти, но делать и разбираться в этом не очень трудно. Основная "запара" может настигнуть несведущего именно при работе с прерываниями. Собсна, решено объединить.
Стек:
Отладочная плата LDM-HELPER-K1986BE1QI-FULL;
МК K1986BE1QI(но все паки и тд. юзаю 1986ВЕ1Т ибо
те же яйца, только с бокудаже даташит 1 на целую линейку);Программатор ARM-USB-OCD-H;
IDE Keil uVison 5;
Open OCD.
Оффтоп
"RAM & Interruptions" не потому что "Я умею писать по буржуйски", а потому что "Размер заголовка не может превышать 120 символов" и "Отладка прерываний в опреативной памяти" не лезет. Ну, как говорил препод по информатике: "Это по молодости кажется, что не влазит"
Подготовка к работе
В принципе, подготовка ничем не отличается от предыдущего поста, поэтому повторяться лишний раз не будем.
Настройка Keil для линковки проекта в оперативную память
Для того, чтобы собрать проект под 1986BE1T (и не только) для отладки с помощью OLIMEX ARM-USB-OCD-H (и не только) из оперативной памяти средствами среды Keil uVision 5 необходимо для начала создать новый проект keil (смотри все тот же предыдущий пост).
После того, как проект будет создан, необходимо как-то объяснить линкеру, что именно мы хотим. Посмотрим, где и как это делать. Если жамкнуть правой кнопкой по "target" в дереве проекта можно увидеть опции – заходим туда.
С «Output» все просто – минимально необходимое условие выполнения наших целей – это установленный флаг «Create Executable».
«Target» и «Linker» же немного более интересны. На выходе конфигурации этих вкладок получим готовые скрипты для линкера с помощью так называемых «Scatter files». Что это за скатерть такая объяснять не будем, есть документация.
На вкладке «Linker» нужно включить флаг «Use Memory Layout from Target Dialog» - это позволит автогенерить скрипты в зависимости от того, как мы настроим вкладку «Target».
Собственно, к "Target".
Что видим тут полезного для поставленной цели, так это 2 блока с описанием памяти (причем предзаполненных! Спасибо пакам keil-а.).
Посмотрим, какая скатерть получается на выходе. В папке проекта есть ./RTE/Device/MDR1986BE1T, а там файл MDR1986VE1T.sct. Это дефолтный скрипт. Так как никаких изменений не проводилось будет юзаться именно он.
MDR1986VE1T.sct
; ******************************************************************************
; ************* Scatter-Loading Description File for MDR1986VE1T ***************
; ******************************************************************************
LR_IROM1 0x00000000 0x00020000 { ; load region size_region
ER_IROM1 0x00000000 0x00020000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
.ANY (+XO)
}
RW_IRAM1 0x20000000 0x00008000 { ; RW data
.ANY (+RW +ZI)
}
RW_IRAM2 0x20100000 0x00004000 {
.ANY (+RW +ZI)
}
}Небольшой анализ показывает, что код будет записываться в ER_IROM1. Правда сейчас там все сконфигурировано так, чтобы грузить программу во флешу. Будем менять.
Можно, кончено, править scatter руками, но проще воспользоваться рафическими инструментами. Инструкции линкуются в первый раздел IROM памяти. Т.е. изменив поля «Start» и «Size» IROM1 на вкладке «Target» можно получить нужную линковку. Видим, что разделов IRAM у нас 2. Но. Читая даташит натыкаемся на фразу: «AHB-Lite – шина выборки инструкций и данных из внешнего адресного пространства» и, немного покурив остальное описание понимаем, что эта шина – единственный способ дотянуться до инструкций в оперативной памяти. Смотрим адреса и понимаем, что программу для выполнения в оперативной памяти дозволено грузить с 0x20100000.
Итого: копируем поля из IRAM2 в IROM1 и ребилдим.
Результирующий scatter файл. Будет находиться ./Objects/projectName.sct
; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************
LR_IROM1 0x20100000 0x00004000 { ; load region size_region
ER_IROM1 0x20100000 0x00004000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
.ANY (+XO)
}
RW_IRAM1 0x20000000 0x00008000 { ; RW data
.ANY (+RW +ZI)
}
}Теперь видно, что инструкции будут располагаться в оперативной памяти, причем именно в той, которая для них и предназначена. Отлично! Пора проверить.
Запуск в оперативной памяти
Загрузим проект по образу и подобию 1 части статьи. И посмотрим адреса функций, например:
(gdb) x main
0x20100aa8 <main>: 0x25d95598Т.е. адрес входа в main - 0x20100aa8, что вполне себе похоже на то, ради чего все это было затеяно.
Попробуем простенькую программу. Пусть по прерыванию таймера зажжем диод на плате.
Вначале было слово тактирование. С этого и начнем. Еще с первых дней знакомства с Миландровскими вычислителями был написан небольшой блочок, для того, чтобы в будущих простых проектах не париться по поводу настройки частоты проца. Суть: работает от внутреннего HSI, разрешает задавать частоты от 8 до 128 МГц. Пока что этого хватало.
Рассмотрим программу, которую будем грузить в RAM. Код туп, прост и, надеюсь, понятен.
main.c
static void ledInit( void );
inline static void ledOn( void ) { MDR_PORTB->RXTX = 0; }
inline static void ledOff( void ) { MDR_PORTB->RXTX = 1; }
static void timerInit( void );
inline static void timerStart( void ) { MDR_TIMER1->CNTRL = 0x01; }
void TIMER1_IRQHandler( void );
int main( void )
{
// Основное тактирование
freqHsiCpuSet( 8 );
// Инициализация диода
ledInit();
// Инициализация таймера
timerInit();
// Стартуем! Я сказала стар-ту-ем.
timerStart();
while(1) __NOP();
}
static void ledInit( void )
{
MDR_RST_CLK->PER_CLOCK |= 1 << 22;
PORT_InitTypeDef portLEDInitStruct;
PORT_StructInit( &portLEDInitStruct );
portLEDInitStruct.PORT_OE = PORT_OE_OUT;
portLEDInitStruct.PORT_MODE = PORT_MODE_DIGITAL;
portLEDInitStruct.PORT_SPEED = PORT_SPEED_SLOW;
portLEDInitStruct.PORT_Pin = PORT_Pin_0;
PORT_Init( MDR_PORTB, &portLEDInitStruct );
ledOff();
}
static void timerInit( void )
{
NVIC_EnableIRQ( TIMER1_IRQn );
// Разрешение тактирования TIMER1
MDR_RST_CLK->PER_CLOCK |= 1 << 14;
// Разрешение тактовой частоты на TIM1
MDR_RST_CLK->TIM_CLOCK |= 1 < 24;
MDR_TIMER1->CNTRL = 0;
// Настраиваем работу основного счетчика
// Начальное значение
MDR_TIMER1->CNT = 0;
//Предделитель частоты
MDR_TIMER1->PSG = 0;
// Основание счета
MDR_TIMER1->ARR = 0x0F;
// Разрешение генерировать прерывание при CNT = ARR
MDR_TIMER1->IE = 1 << 1;
}
void TIMER1_IRQHandler( void )
{
ledOn();
MDR_TIMER1->IE = 0;
NVIC_DisableIRQ( TIMER1_IRQn );
}Что ожидается? А того, что после запуска практически сразу будет сработано прерывание от таймера. Окей. Грузим в оперативку. Запускаем.
Аккуратный вывод «Continuing.» говорит о том, что программа запущена, но диод не горит(
В чем же, собственно, дело?
Приостановим программу и увидим,
(gdb) <Cntrl + c>
Program received signal SIGINT, Interrupt.
main () at main.c:29
29 while(1) __NOP();... что мы в бесконечном цикле ожидания.
Первая мысль (конечно же, после того, как выругал компилятор/отладчик/среду и тд. и тп. ибо виноват ТОЧНО не ты) - возможно не так проинициализировл LED. Ну, энивей, прерывание сработать должно, попробуем в него попасть, поставив точку останова в обработчике прерывания таймера:
(gdb) b TIMER1_IRQHandler
Breakpoint 2 at 0x20100192: TIMER1_IRQHandler. (2 locations)Перезапустим:
(gdb) monitor reset halt
(gdb) load
(gdb) cНичего не изменилось(
Глянем состояние регистров таймера. Счетчик (Регистр CNT) лежит по адресу 0x40070000, а Основание (Регистр ARR) по 0x40070000.
(gdb) x 0x40070000
0x40070000: 0x0000
(gdb) x 0x40070000
0x40070000: 0x0000Таким же образом можно проверить флаги разрешения прерываний и прочее. И, судя по, что счетчик досчитал до основания и прерывания разрешены (trust me i am an engineer) все должно было сработать. Но не сработало.
А теперь попробуем провернуть все тоже самое, но во флеше. Проводим нехитрые манипуляции с вкладкой "Target", ребилдим, запускаем.
Загрузились, запустились – все работает. И диод горит в прерывании остановились.
(gdb) c
Continuing.
Breakpoint 1, main () at main.c:18
18 freqHsiCpuSet( 8 );
(gdb) c
Continuing.
Breakpoint 2, TIMER1_IRQHandler () at main.c:77
77 ledOn();
(gdb) c
Continuing.Суть в том, что таблица векторов прерываний в данных МК непереносима в принципе и располагается по нулевому адресу. Убедимся, рассмотрев файл startup_MDR1986VE1T.S. Там происходит начальная инициализация: стек поинтер, размеры кучи, стека… Но сейчас будет интересовать таблица векторов прерываний.
startup_MDR1986VE1T (кусочек)
; Vector Table Mapped to Address 0 at Reset
AREA RESET, DATA, READONLY
EXPORT __Vectors
__Vectors DCD __initial_sp ; Top of Stack
DCD Reset_Handler ; Reset Handler
DCD NMI_Handler ; NMI Handler
DCD HardFault_Handler ; Hard Fault Handler
DCD 0 ; Reserved
DCD 0 ; Reserved
DCD 0 ; Reserved
DCD 0 ; Reserved
DCD 0 ; Reserved
DCD 0 ; Reserved
DCD 0 ; Reserved
DCD SVC_Handler ; SVCall Handler
DCD 0 ; Reserved
DCD 0 ; Reserved
DCD PendSV_Handler ; PendSV Handler
DCD SysTick_Handler ; SysTick Handler
; External Interrupts
DCD MIL_STD_1553B2_IRQHandler ;IRQ0
DCD MIL_STD_1553B1_IRQHandler ;IRQ1
DCD USB_IRQHandler ;IRQ2
DCD CAN1_IRQHandler ;IRQ3
DCD CAN2_IRQHandler ;IRQ4
DCD DMA_IRQHandler ;IRQ5
DCD UART1_IRQHandler ;IRQ6
DCD UART2_IRQHandler ;IRQ7
DCD SSP1_IRQHandler ;IRQ8
DCD BUSY_IRQHandler ;IRQ9
DCD ARINC429R_IRQHandler ;IRQ10
DCD POWER_IRQHandler ;IRQ11
DCD WWDG_IRQHandler ;IRQ12
DCD TIMER4_IRQHandler ;IRQ13
DCD TIMER1_IRQHandler ;IRQ14
DCD TIMER2_IRQHandler ;IRQ15
DCD TIMER3_IRQHandler ;IRQ16
DCD ADC_IRQHandler ;IRQ17
DCD ETHERNET_IRQHandler ;IRQ18
DCD SSP3_IRQHandler ;IRQ19
DCD SSP2_IRQHandler ;IRQ20
DCD ARINC429T1_IRQHandler ;IRQ21
DCD ARINC429T2_IRQHandler ;IRQ22
DCD ARINC429T3_IRQHandler ;IRQ23
DCD ARINC429T4_IRQHandler ;IRQ24
DCD 0 ;IRQ25
DCD 0 ;IRQ26
DCD BKP_IRQHandler ;IRQ27
DCD EXT_INT1_IRQHandler ;IRQ28
DCD EXT_INT2_IRQHandler ;IRQ29
DCD EXT_INT3_IRQHandler ;IRQ30
DCD EXT_INT4_IRQHandler ;IRQ31Эта же таблица (только External Interrupts) описана в разделе 31.10 «Lock-up» даташита.
А вот в пункте 31.1 «Типы исключений» написано: "В таблице представлены типы исключений, их номера и приоритет. Номер показывает словное смещение исключений относительно стартового адреса таблицы векторов, которая всегда расположена в 0x0."
После небольшого когнитивного напряжения замечаем, что таблица «железно» вбивается в нулевой адрес. Заметить это нужно очень и очень, ибо с этим пришлось повозиться. Сразу было неочевидно. (Ну, мб я дурень, а остальные до этого сразу догадываются).
Ок, посмотрим на таблицу изнутри.
(gdb) x/48 0x0
0x0 <RST_CLK_GetClocksFreq>: 0x20002068 0x00000165 0x0000016d 0x0000016f
0x10 <RST_CLK_GetClocksFreq+16>: 0x00000000 0x00000000 0x00000000 0x00000000
0x20 <RST_CLK_GetClocksFreq+32>: 0x00000000 0x00000000 0x00000000 0x00000171
0x30 <RST_CLK_GetClocksFreq+48>: 0x00000000 0x00000000 0x00000173 0x00000175
0x40 <RST_CLK_GetClocksFreq+64>: 0x00000177 0x00000179 0x0000017b 0x0000017d
0x50 <RST_CLK_GetClocksFreq+80>: 0x0000017f 0x00000181 0x00000183 0x00000185
0x60 <RST_CLK_GetClocksFreq+96>: 0x00000187 0x00000189 0x0000018b 0x0000018d
0x70 <RST_CLK_GetClocksFreq+112>: 0x0000018f 0x00000191 0x0000083d 0x00000195
0x80 <RST_CLK_GetClocksFreq+128>: 0x00000197 0x00000199 0x0000019b 0x0000019d
0x90 <RST_CLK_GetClocksFreq+144>: 0x0000019f 0x000001a1 0x000001a3 0x000001a5
0xa0 <RST_CLK_GetClocksFreq+160>: 0x000001a7 0x00000000 0x00000000 0x000001a9
0xb0 <RST_CLK_GetClocksFreq+176>: 0x000001ab 0x000001ad 0x000001af 0x000001b1Так как таблица - это вполне себе символ можно указать
(gdb) x/48 __VectorsВыведет тоже самое.
Почему 48? 32 внешних прерывания + адрес вершины стека + 6 системных прерываний + 9 зарезервированных полей.
Заметим, что наше прерывание от таймера (TIMER1_IRQHandler) – это IRQ14. Т.е. (16 + 14) * 4 = 120(в дес) ил 0x78. Что лежит по этому адресу?
(gdb) x/ 0x78
0x78 <RST_CLK_GetClocksFreq+120>: 0x0000083dА куда указывает?
(gdb) x 0x0000083d
0x83d <TIMER1_IRQHandler>: 0x8ff000b5Есть! То самое прерывание, которое искали.
Подобное можно выщучить из таблицы. Получается строка 0x70 <RST_CLK_GetClocksFreq+112> столбец 3, т.к. 1 слово = 4 байта. Кстати, выглядит это все примерно так:
Вернемся немного назад и провернем все тоже самое, но в оперативке. Глянем таблицу.
(gdb) x/48 0Осталась неизменной, что, наверное и следовало ожидать, ведь флеш не прошивалась.
А что лежит по
(gdb) x 0x0000083d
0x83d: 0x8ff000b5Собственно, то, что и было, но без символа.
Заметил только при написании статьи
Возможно теперь это отработает правильно (ибо флеш прошита такой же программой, что и в оперативке, но мы "зайдем" не в тот обработчик, что написали, а в тот, что прошит). Для чистоты эксперимента лучше очистить флешку.
А глянем теперь таблицу через символ
(gdb) x/48 __Vectors
0x20100000 <__Vectors>: 0x20002068 0x20100165 0x2010016d 0x2010016f
0x20100010: 0x00000000 0x00000000 0x00000000 0x00000000
0x20100020: 0x00000000 0x00000000 0x00000000 0x20100171
0x20100030: 0x00000000 0x00000000 0x20100173 0x20100175
0x20100040: 0x20100177 0x20100179 0x2010017b 0x2010017d
0x20100050: 0x2010017f 0x20100181 0x20100183 0x20100185
0x20100060: 0x20100187 0x20100189 0x2010018b 0x2010018d
0x20100070: 0x2010018f 0x20100191 0x2010083d 0x20100195
0x20100080: 0x20100197 0x20100199 0x2010019b 0x2010019d
0x20100090: 0x2010019f 0x201001a1 0x201001a3 0x201001a5
0x201000a0: 0x201001a7 0x00000000 0x00000000 0x201001a9
0x201000b0: 0x201001ab 0x201001ad 0x201001af 0x201001b1Есть родная, причем наше прерывание туц описано правильно. Осталось переместить ее во флешу. К сожалению чистых способов я не знаю, затрагивать флешку придется энивей.
Последний рывочек
Есть несколько способов добиться желаемого результата, но вот этот мне нравится больше всех: прошить во флешку обработчик прерывания, который будет переходить по нужному адресу в оперативной памяти.
Создаем новый проект, который будет располагаться во флеш
#define READWD(x) (*((volatile uint32_t *)(x)))
typedef void ( *fUserIrptHandler )( void );
int main()
{
while(1){}
}
void TIMER1_IRQHandler()
{
volatile uint32_t addr = READWD( 0x20100078 );
fUserIrptHandler funcInRAM = ( fUserIrptHandler )( addr );
funcInRAM();
}
Все предельно просто. При срабатывании прерывания, по таблице попадем в тот обработчик, который лежит во флеш. В нем же мы переходим к пользовательскому обработчику, расположенному уже в оперативной памяти. Такая получается матрешка.
Смещение постоянное, так что для расчета не тяжко: Стартовый адрес памяти (0x20100000) + сдвиг для конкретного прерывания (0x78).
Прошиваем данную флеш вспомогательной программой. Запускаем ту программу, что с таймером из оперативной. Baldezh.
Итого
Да, совсем обойтись без флехи не удалось, но всегда нужно искать плюсы:
Если такой способ есть гуру обязательно подскажет о нем в комментарии - буду рад;
Погрузились во внутрянку работы проца, это полезно;
Все-таки прошить можно 1 раз флешку нужными обработчиками и уйму раз отлаживаться в оперативке, не коцая постоянку. Есть конечно, трабл: если во флешке будет прошит обработчик, а в оперативке мы его не сделаем - будет доступ не туда, куда надо - а это беда.
Спасибо, надеюсь кому-то статья поможет :)