STM32 загрузчик и защита от чтения Опции

[uriy]

Столкнулся с неожиданной для себя вещью.
Имеется железка на STM32L1.
В ней есть самописный загрузчик и основная программа.
Загрузчик позволяет обновлять прошивку через uart.
Перед переходом из загрузчика в основную программу проверяется ее CRC.
На чип установил защиту от чтения.
Теперь оказывается даже загрузчик не может считать флешку.
Я не могу проверить CRC, при чтении возвращаются нули.
Как решается вопрос о защите прошивки от считывания при наличии самописного загрузчика?

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

На чип установил защиту от чтения.
Теперь оказывается даже загрузчик не может считать флешку.
Я не могу проверить CRC, при чтении возвращаются нули.

Не может такого быть. В процессе работы программа читает константы (даже адреса регистров) из памяти программ теми же самыми командами, которыми должна считывать содержимое памяти для расчета CRC. Если бы она не могла считывать флешь-память, она просто не смогла бы работать. Никаких специальных механизмов, запрещающих считывать одну облать флешь из другой в этом семействе нет, запрещено только чтение флеш при исполнении кода из ОЗУ, из системной памяти и отладчиком.

[KRS]

Так видимо вторичный загрузчик из ОЗУ работает...
Надо разбить и в ОЗУ копировать только ту часть, которая флеш пишет.

[adnega]

Я не могу проверить CRC, при чтении возвращаются нули.

CRC аппаратно считаете? Может, тактирование не разрешили?

[uriy]

Что-то непонятное происходит.
Сделал несколько экспериментов.
Первый через JLink
1. Через JFlash стираю всю флешку.
2. Через JFlash заливаю свой загрузчик.
3. В JFlash ставлю защиту от чтения (Target->Secure chip). Проверяю JFlash считать данные не может.
4. Через UART средствами своего загрузчика заливаю прошивку. Все работает.

Второй через STLink
1. В ST-Link utility стираю всю флешку.
2. Заливаю свой загрузчик.
3. Ставлю защиту от чтения Level 1. Загрузчик больше не подает признаков жизни.

Третий через ST-Link
1. В ST-Link utility стираю всю флешку.
2. Заливаю свой загрузчик.
3. Через UART заливаю прошивку. Все работает как надо
4. Ставлю защиту от чтения Level 1. Опять никаких признаков жизни.

JLink и ST-Link дали разные результаты и оба отличаются от того что я получил вчера. Как так?

Так видимо вторичный загрузчик из ОЗУ работает...
Надо разбить и в ОЗУ копировать только ту часть, которая флеш пишет.

Я пользуюсь SPL библиотеками от ST. Я знаю все начнут тыкать пальцем. У меня с ней не бывало проблем. Мне казалось там были директивы для размещения функций записи в ОЗУ. Проверил их нет. Посмотрел в дебаггере адреса функций, они лежат во флеш. Кажется при этом были какие-то нюансы. Надо запрещать все прерывания когда функции записи лежат во флеш?
При старте загрузчик читает параметры из EEPROM. Может это вызывает HardFault при включенной защите от чтения? У меня нет вывода отладочной инфы в HardFault handler.

CRC аппаратно считаете? Может, тактирование не разрешили?

Нет считаю программно. С CRC возникала проблема только когда включена защита от чтения. Да и ту сегодня уже не могу повторить.

[Axel]

Option bytes в обоих случаях (J-Link и ST-Link) не сравнивали?

[uriy]

Сравнивал только в ST-Link utility для 4 плат она отображала одинаковые значения.
Сегодня считал в JFlash. Оказалось в двух платах стоят биты защиты записи на некторые сектора.
Похоже ST-Link мало что читает в option bytes и просто показывает значения по умолчанию.
Разве полное стирание не должно было сбросить эти биты?
Сейчас привел option bytes к единому значению на всех платах. И теперь все работает.
Могу обновить программу через загрузчик и стоит защита от чтения.

[Axel]

Разве полное стирание не должно было сбросить эти биты?

В общем - нет. Вот наоборот - да (но это Вы и сами знаете).