Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Реальный пример установки защиты
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > ARM, 32bit
RomanRom
Что означает распространенная в Интернете фраза о том, что после установки бита защиты LCKR снять защиту можно только после сброса. Сброса какого? Аппаратного кнопкой RESET или программного? Кто-нибудь может привести короткую программу, на которой четко было бы видно - вот есть защита (светодиод светится), вот что-тосбрасываем, а вот защита снимается (светодиод не светится)?
RomanRom
Ладно, упростим вопрос.
Из перевода референс манула STM32F10x:

...Когда последовательность процедуры блокировки была применена к биту порта (LCKR), то его конфигурацию больше нельзя изменить до следующего сброса.

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


Aner
Его сброса, этого бита LCKR. При его сбросе память программы, конфигурация стирается.
cioma
Для исключения трудностей перевода, приведите цитату на языке оригинала.
Aner
Да и так понятно, зачем еще цитату. Еще попросите на английском языке писать вопросы, тогда ваабще не к чему придраться.
Из программы читаем регистр по адресу F800, Если FF то CP. Если A5 -Default. Вот и напишите программу для светодиода на нужном потру.
RomanRom
Вот цитата и перевод из интернетовского документа STM32_DOC_RU.chm

This register is used to lock the configuration of the port bits when a correct write sequence is applied to bit 16 (LCKK). The value of bits [15:0] is used to lock the configuration of the GPIO. During the write sequence, the value of LCKR[15:0] must not change. When the LOCK sequence has been applied on a port bit it is no longer possible to modify the value of the port bit until the next reset.

Этот регистр используется для блокировки конфигурации битов порта, когда применена правильная последовательность записи к биту 16 (LCKK). Для блокировки конфигурации GPIO используется значение битов [15:0]. Во время последовательности записи значение LCKR [15:0] не должно изменяться. Когда последовательность процедуры блокировки была применена к биту порта, то его конфигурацию больше нельзя изменить до следующего сброса.

То есть, правильно ли я понимаю, что слово "reset" относится не к сбросу микроконтроллера, а всего лишь к сбросу бита в LCKR?
_Артём_
Цитата(RomanRom @ May 15 2012, 15:39) *
То есть, правильно ли я понимаю, что слово "reset" относится не к сбросу микроконтроллера, а всего лишь к сбросу бита в LCKR?

Нет. По смыслу цитаты речь идёт о сбросе контроллера.
VslavX
Цитата(_Артём_ @ May 15 2012, 16:30) *
По смыслу цитаты речь идёт о сбросе контроллера.

Именно. Причем по моему опыту сброс через внешний вход ~RESET не помогает. После стирания битов еще приходится делать Power Cycling - тогда только защита гарантировано отключается.
RomanRom
Цитата(VslavX @ May 16 2012, 08:08) *
Именно. Причем по моему опыту сброс через внешний вход ~RESET не помогает. После стирания битов еще приходится делать Power Cycling - тогда только защита гарантировано отключается.

Вопрос 1 - Power Cycling относится к установке защиты GPIO или к защите флэш-памяти. Как в программе сделать Poer Cycling?

Вопрос 2. В нижеприведенной программе сначала зажигается лампочка на PC8, затем ставится защита LCKR, а затем PC8 переводится в режим входа. Если защита установлена правильно, то лампочка должна гореть, а у меня она гаснет (хотя если убрать блок из 4 нижних строк, то светится). Почему не устанавливается защита?

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

int main(void)
{ int tmp;
//Конфигурирование GPIOC.8
RCC->APB2ENR |= RCC_APB2ENR_IOPCEN; // Разрешить тактирование GPIOC
GPIOC->CRH &= ~GPIO_CRH_MODE8; //очистить разряды MODE
GPIOC->CRH &= ~GPIO_CRH_CNF8; //очистить разряды CNF
GPIOC->CRH |= GPIO_CRH_MODE8_0; //выход, 10MHz
GPIOC->CRH &= ~GPIO_CRH_CNF8; //общего назначения, симетричный
GPIOC->BSRR = GPIO_BSRR_BS8; //GPIOC.8=1

GPIOC->LCKR |= GPIO_LCKR_LCK8; //включение защиты настроек
GPIOC->LCKR |= GPIO_LCKR_LCKK; //Записать в LCKK "1”-"0”-"1”
GPIOC->LCKR &= ~GPIO_LCKR_LCKK; //
GPIOC->LCKR |= GPIO_LCKR_LCKK; //
tmp = GPIOC->LCKR; //Две операции чтения регистра LCKR
tmp = GPIOC->LCKR;

//Конфигурирование GPIOC.8
GPIOC->CRH &= ~GPIO_CRH_MODE8; //очистить разряды MODE
GPIOC->CRH &= ~GPIO_CRH_CNF8; //очистить разряды CNF
GPIOC->CRH |= GPIO_CRH_CNF8_1; //дискретный вход, подтяжка к "земле"
GPIOC->BSRR = GPIO_BSRR_BR8; //включить подтягивающий резистор

while(1);
}
RomanRom
Может ли кто-то проверить по указанному выше листингу установку защиты на линии PC8?

Возможно требуется включить еще какое-то дополнительное тактирование в регистрах RCC или вводить задержки во времени?
AHTOXA
Попробуйте вот так:
Код
    GPIOC->LCKR = GPIO_LCKR_LCK8 | GPIO_LCKR_LCKK;
    GPIOC->LCKR = GPIO_LCKR_LCK8;
    GPIOC->LCKR = GPIO_LCKR_LCK8 | GPIO_LCKR_LCKK;
    GPIOC->LCKR = GPIO_LCKR_LCK8;
    tmp = GPIOC->LCKR;
VslavX
Цитата(VslavX @ May 16 2012, 08:08) *
Именно. Причем по моему опыту сброс через внешний вход ~RESET не помогает. После стирания битов еще приходится делать Power Cycling - тогда только защита гарантировано отключается.

Я прошу прощения - я думал что речь идет о Code Read Protection - вот он только по Power Cycling снимается.
А GPIO LCKR должен бы по любому сбросу процессора деактивироваться.
RomanRom
Цитата(AHTOXA @ May 18 2012, 11:41) *
Попробуйте вот так:
Код
    GPIOC->LCKR = GPIO_LCKR_LCK8 | GPIO_LCKR_LCKK;
    GPIOC->LCKR = GPIO_LCKR_LCK8;
    GPIOC->LCKR = GPIO_LCKR_LCK8 | GPIO_LCKR_LCKK;
    GPIOC->LCKR = GPIO_LCKR_LCK8;
    tmp = GPIOC->LCKR;

Изменений нет (и защиты тоже). Кстати, я в Инете как-то не нашел реальных (а не теоретических) листингов с установкой защиты GPIO и с ее последующей проверкой

И еще одно. В дебаггере тоже регистр GPIO_LCKR не изменяется даже при прямом вводе
GPIOC->LCKR = 0x0000FFFF;
Тут или в названии регистра что-то не то, или нет какой-то предварительной установки.
Проверяю на STM32VLDISCOVERY. Может быть на другом камне по-другому?
Corvus
bb-offtopic.gif
А для чего может потребоваться такая защита на практике?
RomanRom
Цитата(Corvus @ May 18 2012, 13:22) *
bb-offtopic.gif
А для чего может потребоваться такая защита на практике?

Это может потребоваться при отладке программы. Например, разработчик где-то допустил ошибку по невнимательности, а могут быть баги компилятора, когда вдруг "разваливается" стек с непредсказуемыми результатами установки регистров. Если схема критична к изменению входа на выход (или наоборот), то будут проблемы.

А если честно, то дело принципа. Везде на умных сайтах приводят последовательность команд, которые блокируют линии GPIO. А вот проверяли ли авторы этот момент на практике?

P.S. Посмотрел дизассемблером команды записи в регистр GPIO_LCKR, кажется, что правильный базовый адрес 0x40011000 и смещение #24 (0x18) и в регистре r2 происходит смена 1-0-1.
AHTOXA
Цитата(RomanRom @ May 18 2012, 14:58) *
Проверяю на STM32VLDISCOVERY. Может быть на другом камне по-другому?

Проверил, работает. Именно на STM32VLDISCOVERY. Вот такой код:
Код
    uint32_t tmp = GPIO_LCKR_LCK8 | GPIO_LCKR_LCKK;
    GPIOC->LCKR = tmp;
    GPIOC->LCKR = GPIO_LCKR_LCK8;
    GPIOC->LCKR = tmp;
    tmp = GPIOC->LCKR;
    tmp = GPIOC->LCKR;

После выполнения этого кода настройки ножки уже не меняются.

Цитата(Corvus @ May 18 2012, 16:22) *
А для чего может потребоваться такая защита на практике?

Ну, например, операционка, настраивает свою периферию, и запускает пользовательский код. Блокировка не даст пользовательскому коду изменить критичные настройки.
Или - управление мотором в условиях сильных помех. Чтобы никакой сбой в программе не смог сбить настроек ШИМ-а (а то всё сразу сгорит).
RomanRom
AНTOXA
А на каком компиляторе и с какой оптимизацией проверялся код? У меня на кокосе все равно не работает.
Еще раз уточню листинг - синий светодиод горит или нет?

int main(void)
{ RCC->APB2ENR |= RCC_APB2ENR_IOPCEN; // Разрешить тактирование GPIOC
GPIOC->CRH &= ~GPIO_CRH_MODE8; //очистить разряды MODE
GPIOC->CRH &= ~GPIO_CRH_CNF8; //очистить разряды CNF
GPIOC->CRH |= GPIO_CRH_MODE8_0; //выход, 10MHz
GPIOC->CRH &= ~GPIO_CRH_CNF8; //общего назначения, симетричный
GPIOC->BSRR = GPIO_BSRR_BS8; //GPIOC.8=1

uint32_t tmp = GPIO_LCKR_LCK8 | GPIO_LCKR_LCKK;
GPIOC->LCKR = tmp;
GPIOC->LCKR = GPIO_LCKR_LCK8;
GPIOC->LCKR = tmp;
tmp = GPIOC->LCKR;
tmp = GPIOC->LCKR;

GPIOC->CRH &= ~GPIO_CRH_MODE8; //очистить разряды MODE
GPIOC->CRH &= ~GPIO_CRH_CNF8; //очистить разряды CNF
GPIOC->CRH |= GPIO_CRH_CNF8_1; //дискретный вход, подтяжка к "земле"
GPIOC->BSRR = GPIO_BSRR_BR8; //включить подтягивающий резистор

while(1)
{
}
}
AHTOXA
Всё нормально у вас. Вы залочили конфигурацию ножки на выход, а состояние-то по-прежнему можно менять, GPIOC->BSRR = GPIO_BSRR_BR8 - гасит светодиод.
RomanRom
AHTOXA, спасибо. Осталось еще чуть-чуть.

Защита установлена, но нажатие кнопки сброса (одиночное или многократное) защиту не снимает (перепроверьте у себя на STM32VLDiscovery по-возможности).

Если смотреть документы, то существует три типа сброса: систеный сброс, сброс по питанию и сброс резервного домена. Поскольку сброс от кнопки RESET защиту не снимает, то все остальные способы системного сброса (типа программный через static __INLINE void NVIC_SystemReset(void) и т.д.), наверное, не помогут.

Остается сброс по питанию (выход из спящего режима) от и сброс резервного домена.

Еще есть зацепка в сообщении VslavX про ...Code Read Protection - вот он только по Power Cycling снимается...

Как же все-таки сымитировать удаление защиты и увидеть, что она действительно снимается?

AHTOXA
По кнопке сброса снова запускается ваша программа, снова блокирует конфигурацию и гасит светодиодsm.gif
Вы сделайте задержку на пару секунд после запуска и включения светодиода, а уже потом - переключение на вход и блокировку. Тогда после сброса сможете увидеть горящий светодиод, который гаснет через две секунды.
(Я сделал пару терминальных команд - на блокировку состояния ноги, и на попытку изменения состояния ноги. Так что у меня после сброса кнопкой конфигурация не блокируется, и светодиод горит, то есть, всё как положено)
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.