Из чего это очевидно?
memcpy в IAR проверяет - выровнены ли на 4 оба адреса и если да, то копирует (size & -16) байт (где size - размер из аргумента функции) инструкциями LDM/STM; если адреса не выровнены или (4 <= size < 16) - копирует пословно (по 4 байта LDR/STR); и только остальное - побайтно. Ну вначале ещё немного копирует побайтно, пытаясь выровнять адреса. То же самое возможно и в M0, имхо.
"Приведение к упакованной структуре" ничего не порождает, так как анализ указателей и размера происходит внутри memcpy() в runtime и memcpy ничего не знает о типе копируемых данных. И вообще не знает - структура это, или её часть или просто произвольная область памяти. Конечно некоторые компиляторы, имея данные о выравнивании или о размере копирования, могут вместо memcpy() общего вида подставлять специализированные memcpy, оптимизированные под данный случай вызова (не нужны проверки и выравнивания внутри в runtime).
Для пользователя (пишущего в коде memcpy()) всё это прозрачно и копирование он может считать побайтным. Если конечно он не сделал глупостей с приведением типа аргументов memcpy() (если такие глупости могут иметь место быть, то компилятор, будучи введён в заблуждение кривым приведением типов, может подставить оптимизированные функции memcpy() вместо memcpy() общего вида - тогда и будут проблемы с выравниванием).
Нет. Много лет назад сделал обработку fault-ов. С тех пор просто перетаскиваю её из проекта в проект. Сделал по даташиту на ядро. Там всего ничего регистров. С M0 не работал, только M3/M4.
Под "точкой фаулта (PC)" я имел в виду адрес PC, на котором произошёл fault.
haker_fox писал, что у него уже анализируются регистры. По-моему под анализом надо понимать выдачу пользователю содержимого всех регистров CPU + кадра активного стека + расшифровки регистров HF. Типа как в синем окне смерти винды. По-крайней мере у меня во всех проектах сделано именно так.
Когда я писал про то, как сделать FatFS устойчивой к сбоям, я имел в виду подобный метод. Вроде в нём нет никакого ноу хау - всё само собой очевидно. Не раз реализовывал системы хранения подобным образом. Главное правило тут: любая небезопасная операция модификации носителя, должна быть журналируемой (перед её началом должна быть сделана в журнале запись о её начале, содержимое и последовательность планируемых операций, в процессе операции в журнале должно бэкапиться всё содержимое перезаписываемых поверх областей, а после завершения - запись удалена). Небезопасные операции модификации - все операции, которые, будучи прерваны, приведут к нарушению логической структуры хранения на носителе. Примерно так.
Нет конечно. Причём тут невыровненный доступ, если аргументы-указатели функции (memcpy()) могут быть произвольными (байтовыми)?
Скорее похоже на то, что Ваш memcpy() лезет в несуществующую память (нарушение границ). Смотрите код в точке fault-а и значение регистров в этой точке.
Как вариант: один из ваших new не может выделить память и возвращает NULL, который Вы затем передаёте в memcpy(). Отсюда и доступ в несуществующую память. Почему после new не проверяете возвращаемое ею значение? Это грубая ошибка.
Вообще эта ошибка находится за 5 минут, после взгляда в окна дизасма и состояния регистров отладчика.
Ну можно изменить мой метод, добавив перед записью блока, запись в тот маркерный байт отдельного значения "старт записи" например == 0xFE, а после завершения записи блока - записывать в этот байт "завершение записи" == 0xFC. Тогда достаточно только этот байт прочитать. Но выигрыш от этого не велик, так как блоки всё равно лучше проверять на валидность при старте ПО (CRC, ...), а значит их нужно читать полностью по любому. А вот при записи 3 шага вместо 2-х - это уменьшение скорости записи. И чтение блока - операция очень быстрая, я в своих устройствах читал их с внешней флешь по dual-SPI на SCLK == 30МГц - время очень малое.
А что сложного? Выделить один байт в заголовке записываемого блока. При записи блока выставить ему значение == значению стёртой ячейки флешь (предположим это 0xFF). После завершения записи блока выполнить запись поверх этого байта со значением != 0xFF (предположим это 0xFE). Теперь при старте ПО проверяем блок:
1) Если все байты блока имеют значение == 0xFF - блок чистый (не писался);
2) Если в блоке есть байты со значением != 0xFF и наш байт == 0xFE - блок записан полностью;
3) Если в блоке есть байты со значением != 0xFF и наш байт == 0xFF - был рестарт в процессе записи блока.
