Суть вам описали в первом же ответе.

Ну да, M3 умеет невыровненный доступ.

Откройте для себя memcpy.

Не знаю как там в кейл, но в IAR есть чудесный префикс __packed. И если объявить long-переменную с этим префиксом, то даже на МК не поддерживающих невыровненный доступ, обращения к таким невыровненным переменным будет происходить как по-маслу - без HF. И "дополнительный расход памяти" чудесным образом уйдёт в небытие.
Думаю что и в кейл должно быть что-то подобное.

http://www.keil.com/support/man/docs/ar ... 968737.htm

и
http://www.keil.com/support/man/docs/ar ... 966304.htm

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

ТС злобный буратино, он невыровненный доступ с помощью приведения типа указателя получает. Против лома никакой __packed не спасёт. Если он захотел 32-битный доступ, то он его получит.

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

Лучше объявить массив с 32х битными элементами, он то точно будет пословно выравнен, а побайтный доступ к нему работать будет.

Добавлено after 3 minutes 6 seconds:

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Вот нахрена эти извращения? ТС написал, что это копирование происходит ОДИН РАЗ ПРИ СТАРТЕ ПРОГРАММЫ для считывания конфигурации. На чём экономить собрались? Микросекунда при старте погоду сделает?

Зачем изобретать велосипед и не пользоваться memcpy()? https://devel.rtems.org/browser/umon/ma ... a9b6214cd6
Причем это верно для любой платформы. Функция memcpy() почти всегда имеет оптимизацию под конкретную архитектуру. Уж больно часто необходимо копировать массивы данных.

объявляю массив таким образом:
__align(4) uint8_t adr_sensor[QTY_TERM_SENSOR][8];
и все норм.

ТС, откройте для себя структуры и, как уже выше сказали, memcpy. И любые параметры пихайте в эту структуру.
Потом просто сохраняйте/читайте её, и никаких проблем не будет.

В memcpy реализована процедура записи во flash?

Нет, но ссылку на исходник memcpy, обеспечивающий оптимальную скорость копирования я привел выше. Берите его за основу. Если, конечно, не жалко flash.
Я в таких случаях предпочитаю пользоваться EEPROM или AT24C*

Почему её должно быть жалко? Запись происходит максимум несколько десятков раз за всю жизнь девайса. Объем флеша МК вполне позволяет.

На простое копирование из 8 битного массива 4 байтов в 32 битную переменную id_data, с реверсом данных в необходимый вид. Таким образом
id_data = moimassiv[1]<<8;
id_data = ( id_data + moimassiv[2])<<8;
id_data = ( id_data + moimassiv[3])<<8;
id_data = id_data + moimassiv[4];
Уходит 14 asm команд, если то же самое делаю применяя memcpy то уже 47 команд! Потом еще нужно сделать реверс __REV плюс еще пару команд.

Копирование маленьких объёмов данных с помощью memcpy, естественно, будет нерациональным по скорости. И это нужно понимать.
Вы бы ещё с одним байтом сравнили
Ну а реверс нужен не всем. ТС'у, для сохранения/чтения данных он явно ни к чему.

Не думаю что конфигурационные данные могут занимать большие объемы. Если увеличится объем то так же линейно увеличится и время, или memcpy больший объем будет копировать быстрее? сомневаюсь!

Увеличил тактовую частоту с помощью PLL с 8МГц до 24МГЦ.

RCC->CR |= ((uint32_t)RCC_CR_HSEON);
while((RCC->CR & RCC_CR_HSERDY) == 0) { }

RCC->CFGR = (RCC->CFGR & (~RCC_CFGR_PLLMUL)) | RCC_CFGR_PLLMUL3 | RCC_CFGR_PLLSRC_HSE_PREDIV; // (6)

RCC->CR |= RCC_CR_PLLON; // (7)
while((RCC->CR & RCC_CR_PLLRDY) == 0) // (8)
{

}

RCC->CFGR |= (uint32_t) (RCC_CFGR_SW_PLL); // (9)
while ((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_PLL) //(10)
{

}
RCC->CR &= ~((uint32_t)RCC_CR_HSION);
while((RCC->CR & RCC_CR_HSIRDY) == 0) { }

Стал виснуть MK при записи во flash на
*(__IO uint16_t*)(Address) = (uint16_t)data;

Не помогает.
Да и FLASH_ACR_LATENCY ставится если SYSCLK > 24MHz

Добавлено after 10 minutes 16 seconds:
Полжение дел одинаковое на stm32f030 и stm32f071

Запись во флеш тактируется от HSI, который ты отключил.

Благодарю. Заработало.