[Из песочницы] STM32 USB Mass Storage Bootloader05.09.2016 14:33

Загрузчик — это удобно и полезно, не правда ли? А если загрузчик собственной реализации, то это еще более удобно, полезно и гибко и не стабильно. Ну и конечно же, очень круто!

Так же, это прекрасная возможность углубиться и изучить особенности используемой вычислительной машины — в нашем случае микроконтроллера STM32 с ядром ARM Cortex-M3.

На самом деле, загрузчик — это проще, чем кажется на первый взгляд. В доказательство, под cut’ом соберём свой собственный USB Mass Storage Bootloader!

Работать мы будем с самодельной платой на микроконтроллере (дальше — МК) STM32F103RET. Что бы не переполнять публикацию лишними картинками, приведу усеченную схему этой железки:

При написании bootloader’а я руководствовался следующими принципами:

1. Свой bootloader очень нужен и хватит откладывать это в TODO-лист, пора уже сесть и сделать;
2. Bootloader должен иметь удобный для пользователя интерфейс загрузки программы. Никаких драйверов, сторонних программ, плат-переходников и жгутов МГТФ провода до целевого устройства. Что может быть проще автоматически определяемого USB флеш накопителя?
3. Для работы в режиме bootloader’а микроконтроллеру необходима минимальная аппаратная обвязка (фактически, только USB, кварц и кнопка);
4. Размер boot’а — не главное. Важен, конечно же, но не будем преследовать цель ужать его в пару килобайт. Без мук совести мы поднимем USB стек, поработаем с файловой системой, навтыкаем printf () через строку и вообще не будем особо ни в чем себе отказывать (hello, Standard Peripheral Libraries!);

Немного о FLASH

В используемом МК содержится 512 Kbyte FLASH памяти. Она разбита на страницы по 2048 байт:

Виртуально разобьем FLASH на несколько областей, у каждой из которых будет свое, особое назначение:

• BOOT_MEM — область памяти, выделенная под bootloader;
• USER_MEM — тут мы будем хранить (и исполнять отсюда же) пользовательскую прошивку. Очевидно, что теперь она имеет ограничение в 200 Kbyte;
• MSD_MEM —, а тут будет MASS STORAGE диск, куда можно закинуть прошивку средствами компьютера и вашей любимой ОС;
• OTHER_MEM — ну и оставим еще немного места на всякий случай;

А теперь все то же самое, только для машины (и удобства программиста):

#define FLASH_PAGE_SIZE		2048 						//2 Kbyte per page
#define FLASH_START_ADDR	0x08000000					//Origin
#define FLASH_MAX_SIZE		0x00080000					//Max FLASH size - 512 Kbyte
#define FLASH_END_ADDR		(FLASH_START_ADDR + FLASH_MAX_SIZE)		//FLASH end address
#define FLASH_BOOT_START_ADDR	(FLASH_START_ADDR)				//Bootloader start address
#define FLASH_BOOT_SIZE		0x00010000					//64 Kbyte for bootloader
#define FLASH_USER_START_ADDR	(FLASH_BOOT_START_ADDR + FLASH_BOOT_SIZE)	//User application start address
#define FLASH_USER_SIZE		0x00032000					//200 Kbyte for user application
#define FLASH_MSD_START_ADDR	(FLASH_USER_START_ADDR + FLASH_USER_SIZE)	//USB MSD start address
#define FLASH_MSD_SIZE		0x00032000					//200 Kbyte for USB MASS Storage
#define FLASH_OTHER_START_ADDR	(FLASH_MSD_START_ADDR + FLASH_MSD_SIZE)		//Other free memory start address
#define FLASH_OTHER_SIZE	(FLASH_END_ADDR - FLASH_OTHER_START_ADDR)	//Free memory size

1. Первый режим отвечает за получение и хранение пользовательского ПО в области MSD_MEM, которая доступна, как внешний накопитель.
2. Второй режим проверяет MSD_MEM на наличие файла с именем «APP.BIN», проверяет его целостность, подлинность, а так же перемещает в USER_MEM, если там пусто или если прошивка «APP.BIN» более свежая.

USB Mass Storage Device

int main(void)
{
	Button_Config();
	if(GPIO_ReadInputDataBit(BUTTON_PORT, BUTTON_PIN) == SET) //Bootloader or Mass Storage?
	{
		LED_RGB_Config();
		USB_Config();
		Interrupts_Config();
		USB_Init();
		while(TRUE);
	}
//Bootloader mode
}

u16 MAL_Init(u8 lun) 
{
	switch (lun)
	{
		case 0:
			FLASH_Unlock();
			break;

		default:
			return MAL_FAIL;
	}

	return MAL_OK;
}

u16 MAL_Read(u8 lun, u32 memOffset, u32 *readBuff)
{
	u32 i;

	switch (lun)
	{
		case 0:
			LED_RGB_EnableOne(LED_GREEN);

			for(i = 0; i < MassBlockSize[0]; i += SIZE_OF_U32)
			{
				readBuff[i / SIZE_OF_U32] = *((volatile u32*)(FLASH_MSD_START_ADDR + memOffset + i));
			}

			LED_RGB_DisableOne(LED_GREEN);
			break;

		default:
			return MAL_FAIL;
	}

	return MAL_OK;
}

u16 MAL_Write(u8 lun, u32 memOffset, u32 *writeBuff)
{
	u32 i;

	switch (lun)
	{
		case 0:
			LED_RGB_EnableOne(LED_RED);

			while(FLASH_GetStatus() != FLASH_COMPLETE);
			FLASH_ErasePage(FLASH_MSD_START_ADDR + memOffset);

			for(i = 0; i < MassBlockSize[0]; i += SIZE_OF_U32)
			{
				while(FLASH_GetStatus() != FLASH_COMPLETE);
				FLASH_ProgramWord(FLASH_MSD_START_ADDR + memOffset + i, writeBuff[i / SIZE_OF_U32]);
			}

			LED_RGB_DisableOne(LED_RED);
			break;

		default:
			return MAL_FAIL;
	}

	return MAL_OK;
}

Отформатируем диск и посмотрим, как это отразилось на области MSD_MEM:

Объем совпадает, размер сектора Windows определила верный, нулевой сектор — загрузочный, расположение в памяти соответствует задуманному. Файлы пишутся, читаются, не исчезают после отключения питания — полноценная флешка на 200 Kbyte!

Bootloader

Пусть мы уже создали средствами Windows файловую систему на USB накопителе и загрузили необходимое ПО. Теперь неплохо бы увидеть содержимое носителя «глазами» МК, а значит идем в гости к товарищу ChaN’у за FatFS (модуль простой файловой системы FAT, предназначенный для маленьких встраиваемых систем на микроконтроллерах). Скачиваем, закидываем в проект, прописываем функцию чтения с диска нужных данных:

DRESULT disk_read (
	BYTE pdrv,	/* Physical drive nmuber to identify the drive */
	BYTE *buff,	/* Data buffer to store read data */
	DWORD sector,	/* Sector address in LBA */
	UINT count	/* Number of sectors to read */
)
{
	u32 i;

	for(i = 0; i < count * SECTOR_SIZE; i++)
	{
		buff[i] = *((volatile u8*)(FLASH_MSD_START_ADDR + sector * SECTOR_SIZE + i));
	}

	return RES_OK;
}

Дальше все более-менее очевидно: монтируем файловую систему, открываем файл прошивки, начинаем читать. Изначально было реализовано так, что основное место хранения прошивки — MSD_MEM, а микроконтроллер каждый раз при включении перезаписывает свою FLASH память. Нет прошивки — отладочное сообщение об отсутствии и while (TRUE). Есть прошивка — закидываем её в USER_MEM. Однако очевидный минус такого решения — ресурс стирания/записи FLASH памяти имеет лимит и было бы глупо постепенно и осознанно убивать изделие.

Поэтому сравним «APP.BIN» и USER_MEM, тупо, байт за байтом. Возможно, сравнение хеш-сумм двух массивов выглядело бы более изящным решением, но уж точно не самым быстрым. Заглянем снова в main ():

int main(void)
{
	Button_Config();
	if(GPIO_ReadInputDataBit(BUTTON_PORT, BUTTON_PIN) == SET) //Bootloader or Mass Storage?
	{
		//USB MSD mode
	}
	
	FATFS_Status = f_mount(&FATFS_Obj, "0", 1);
	if(FATFS_Status == FR_OK)
	{
		FILE_Status = f_open(&appFile, "/APP.BIN", FA_READ);
		if(FILE_Status == FR_OK)
		{
			appSize = f_size(&appFile);

			for(i = 0; i < appSize; i++) //Byte-to-byte compare files in MSD_MEM and USER_MEM
			{
				f_read(&appFile, &appBuffer, 1, &readBytes);

				if(*((volatile u8*)(FLASH_USER_START_ADDR + i)) != appBuffer[0]) 
				{
					//if byte of USER_MEM != byte of MSD_MEM
					break;
				}
			}

			if(i != appSize)//=> was done "break" instruction in for(;;) cycle => new firmware in MSD_FLASH
			{
				CopyAppToUserMemory();
			}

			FILE_Status = f_close(&appFile);
			FATFS_Status = f_mount(NULL, "0", 1);

			PeriphDeInit();
			GoToUserApp();
		}
		else //if FILE_Status != FR_OK
		{
			if(FILE_Status == FR_NO_FILE)
			{
				//No file error
			}
			else //if FILE_Status != FR_NO_FILE
			{
				//Other error
			}
			FATFS_Status = f_mount(NULL, "0", 1);
			while(TRUE);
		}
	}
	else //FATFS_Status != FR_OK
	{
		//FatFS mount error
		while(TRUE);
	}
}

void CopyAppToUserMemory(void)
{
	f_lseek(&appFile, 0); //Go to the fist position of file

	appTailSize = appSize % APP_BLOCK_TRANSFER_SIZE;
	appBodySize = appSize - appTailSize;
	appAddrPointer = 0;

	for(i = 0; i < ((appSize / FLASH_PAGE_SIZE) + 1); i++) //Erase n + 1 pages for new application
	{
		while(FLASH_GetStatus() != FLASH_COMPLETE);
		FLASH_ErasePage(FLASH_USER_START_ADDR + i * FLASH_PAGE_SIZE);
	}

	for(i = 0; i < appBodySize; i += APP_BLOCK_TRANSFER_SIZE)
	{
		/*
		 * For example, size of File1 = 1030 bytes
		 * File1 = 2 * 512 bytes + 6 bytes
		 * "body" = 2 * 512, "tail" = 6
		 * Let's write "body" and "tail" to MCU FLASH byte after byte with 512-byte blocks
		 */
		f_read(&appFile, appBuffer, APP_BLOCK_TRANSFER_SIZE, &readBytes); //Read 512 byte from file
		for(j = 0; j < APP_BLOCK_TRANSFER_SIZE; j += SIZE_OF_U32) //write 512 byte to FLASH
		{
			while(FLASH_GetStatus() != FLASH_COMPLETE);
			FLASH_ProgramWord(FLASH_USER_START_ADDR + i + j, *((volatile u32*)(appBuffer + j)));
		}
		appAddrPointer += APP_BLOCK_TRANSFER_SIZE; //pointer to current position in FLASH for write
	}

	f_read(&appFile, appBuffer, appTailSize, &readBytes); //Read "tail" that < 512 bytes from file

	while((appTailSize % SIZE_OF_U32) != 0)		//if appTailSize MOD 4 != 0 (seems not possible, but still...)
	{
		appTailSize++;				//increase the tail to a multiple of 4
		appBuffer[appTailSize - 1] = 0xFF;	//and put 0xFF in this tail place
	}

	for(i = 0; i < appTailSize; i += SIZE_OF_U32) //write "tail" to FLASH
	{
		while(FLASH_GetStatus() != FLASH_COMPLETE);
		FLASH_ProgramWord(FLASH_USER_START_ADDR + appAddrPointer + i, *((volatile u32*)(appBuffer + i))); 
	}
}

Предварительно стираем во FLASH памяти местечко под файл. Размер стираемой области равен количеству страниц в памяти, которые полностью займет «APP.BIN» + еще одна (которую не полностью). А еще, виртуально бьем файл прошивки на «body» и «tail», где «body» — максимально возможный кусок файла, в который входит целое количество блоков по 512 байт, а «tail» — все остальное.

Кажется, что все бинарные файлы прошивок кратны 4-м байтам. Я не был в этом уверен точно (и до сих пор), так что на всякий случай — если прошивка не кратна sizeof (u32) — дополняем её байтами 0xFF. Повторюсь: кажется, что этого не нужно делать —, но операция безобидна для кратных sizeof (u32) бинарников, так что оставим.

Hello, User Application!

Заключительный жизненный этап загрузчика — начало исполнения пользовательской прошивки:

void GoToUserApp(void)
{
	u32 appJumpAddress;
	void (*GoToApp)(void);

	appJumpAddress = *((volatile u32*)(FLASH_USER_START_ADDR + 4));
	GoToApp = (void (*)(void))appJumpAddress;
	SCB->VTOR = FLASH_USER_START_ADDR;
	__set_MSP(*((volatile u32*) FLASH_USER_START_ADDR)); //stack pointer (to RAM) for USER app in this address
	GoToApp();
}

В ядре ARM Cortex M3, когда возникает какое-либо исключение, для него вызывается соответствующий обработчик. Что бы определить начальный адрес обработчика исключений, используется механизм векторной таблицы. Таблица векторов представляет собой массив слов данных внутри системной памяти, каждое из которых является начальным адресом одного типа исключений. Таблица перемещаема и перемещение управляется специальным регистром VTOR в SCB (System Control Block). (В мануале звучит круче, но я сломался: The vector table is relocatable, and the relocation is controlled by a relocation register in the NVIC). После RESET’а значение этого регистра равно 0, то есть таблица векторов лежит по адресу 0×0 (для STM32F103 в стартап файле мы уже самостоятельно двигаем её на 0×08000000). И что очень важно для нас, порядок следования там следующий:

• Значение, лежащее по адресу 0×04 — это то место в программе, куда мы попадаем после Reset-исключения
• Значение, лежащее по адресу 0×00 — это начальное значение Main Stack Pointer для пользовательского приложения

Теперь проверим, работает ли оно вообще. Напишем простую программу мигания светодиодов, с циклами в main () и парочкой прерываний (SysTick и TIM4):

#include "stm32f10x.h"
#include "stm32f10x_gpio.h"
#include "stm32f10x_rcc.h"
#include "stm32f10x_tim.h"
#include "misc.h"

#define SYSCLK_FREQ	72000000
#define TICK_1_KHz	((SYSCLK_FREQ / 1000) - 1)
#define TICK_1_MHz	((SYSCLK_FREQ / 1000000) - 1)

volatile u32 i, j;

int main(void)
{
	GPIO_InitTypeDef GPIO_Options;
	NVIC_InitTypeDef NVIC_Options;

	RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_GPIOB, ENABLE);
	RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM4, ENABLE);

	GPIO_Options.GPIO_Pin = GPIO_Pin_7;
	GPIO_Options.GPIO_Speed = GPIO_Speed_2MHz;
	GPIO_Options.GPIO_Mode = GPIO_Mode_Out_PP;
	GPIO_Init(GPIOA, &GPIO_Options);

	GPIO_Options.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1;
	GPIO_Options.GPIO_Speed = GPIO_Speed_2MHz;
	GPIO_Options.GPIO_Mode = GPIO_Mode_Out_PP;
	GPIO_Init(GPIOB, &GPIO_Options);

	GPIOB->BSRR = GPIO_Pin_0 | GPIO_Pin_1; //LEDs off
	GPIOA->BSRR = GPIO_Pin_7

	TIM4->PSC = 720 - 1;		//clock prescaller
	TIM4->ARR = 60000 - 1;		//auto-reload value
	TIM4->CR1 |= TIM_CounterMode_Up;//upcounter
	TIM4->DIER |= TIM_IT_Update;	//update interrupt enable
	TIM4->CR1 |= TIM_CR1_CEN;	//timer start

	NVIC_Options.NVIC_IRQChannel = TIM4_IRQn;
	NVIC_Options.NVIC_IRQChannelPreemptionPriority = 0;
	NVIC_Options.NVIC_IRQChannelSubPriority = 0;
	NVIC_Options.NVIC_IRQChannelCmd = ENABLE;
	NVIC_Init(&NVIC_Options);

	SysTick_Config(TICK_1_KHz);

	while(1)
	{
		__disable_irq();

		GPIOB->BSRR = GPIO_Pin_0 | GPIO_Pin_1; //Off
		for(i = 0; i < 10; i++)
		{
			for(j = 0; j < 500000; j++); //Pause
			GPIOA->ODR ^= GPIO_Pin_7; //Reverse
		}
		GPIOA->BSRR = GPIO_Pin_7; //Off

		__enable_irq();

		for(i = 0; i < 5000000; i++); //Pause
	}
}

void SysTick_Handler(void)
{
	volatile static u32 LED_Counter = 0;

	if(LED_Counter >= 40)
	{
		GPIOB->ODR ^= GPIO_Pin_1; //Reverse
		LED_Counter = 0;
	}

	LED_Counter++;
}

void TIM4_IRQHandler()
{
	TIM4->SR = ~TIM_SR_UIF;
	GPIOB->ODR ^= GPIO_Pin_0; //Reverse
}

1. Убрать из SystemInit () операцию перемещения таблицы векторов на какое либо значение (//SCB→VTOR = FLASH_BASE). Bootloader перемещает ее самостоятельно перед переходом в пользовательскую программу!
2. В Linker script поменять начало нашей программы с адреса 0×08000000 на адрес начала USER_MEM (FLASH (rx): ORIGIN = 0×08010000, LENGTH = 200K);

А вот так выглядит лог загрузки этой прошивки в МК через бутлоадер:

Спасибо за внимание!

Комментарии (4)

• telhin

  5 сентября 2016 в 14:09

  0

  ↑

  ↓

  Блок схема у вас очень красивая, можно поинтересоваться в чем приготовлена?

  • Katbert

    5 сентября 2016 в 14:10

    0

    ↑

    ↓

    Спасибо.
    https://www.lucidchart.com/

• igor_suhorukov

  5 сентября 2016 в 14:19

  0

  ↑

  ↓

  Спасибо за статью. Как вариант — DFU bootloader из проекта Maple для stm32.
  Но usb mass storage конечно удобнее!

• x893

  5 сентября 2016 в 14:31

  0

  ↑

  ↓

  Мне удобнее было не отводить память для MSD, а сделать её виртуальной. Со стороны хоста диск отформатирован и содержит файл APP.BIN. Если его считать — это содержимое флэша. Я просто копирую файл APP.bin (до 496K) и образ сразу записывается во флэш.
  То есть размер APP.bin = MCU Flash Size — BOOTLOADER Size (16K у меня)