[EdgeAligned 53]

Есть две штуки - настраиваемый (и отключаемый совсем) порог сброса при пониженном напряжении (BOR) и детектор снижения напряжения, вызывающий преырвание (PVD).
Первый (BOR) используется для задания порога сброса, если требования к величине питания более жесткие, чем стандартный минимум 1,8. Конкретные значения порогов указаны в даташите микроконтроллера, в разделе электрических характеристик.
Второй (PVD) используется для детектирования момента прекращения питания устройства и выполнении каких-либо действий при выключении, например, сохранение состояний в бэкап-памяти. Основыввается на том факте, что благодаря конденсаторам, питание не пропадает мгновенно, а идет спад в течение некоторого времени. И вот начиная от некоторого уровня напряжения детектор формирует прерывание (привязано к EXTI16), и МК на остатках питания до момента сброса по порогу BOR или PDR (Power-down reset) производит заданные операции.

16 минут назад, aske1 сказал:

Но чтобы сброс же был по цепи тактирования должен же сторожевой таймер включен

Правильно. Можно даже ткнуть пальцем в кварц, остановив генерацию на нем - микроконтроллер просто остановится (если не включен CSS).

[andrewkrot 0]

Запаяйте поближе к ноге сброса для эксперимента какой-нибудь супервизор подходящий по параметрам напряжения, например ADM809. Будет с чем сравнивать.

[aske1 0]

17 минут назад, EdgeAligned сказал:

Есть две штуки - настраиваемый (и отключаемый совсем) порог сброса при пониженном напряжении (BOR) 

Спасибо. А по умолчанию он наверно включен? 

[EdgeAligned 53]

Он настраивается в регистрах опций (отдельный раздел памяти флеша), поэтому его значение неизвестно программе и не зависит от нее. Однако, если эти биты никогда ранее не изменялись, то BOR отключен.

[aske1 0]

В 06.10.2023 в 13:57, EdgeAligned сказал:

Вообще, вначале желательно выяснить причину сброса, добавив в программу (в её начало, выполняемого при старте) проверку битов причины сброса в регистре RCC->CSR. В частности, бит PINRSTF отвечает за сброс от ноги NRST, бит PORRSTF - за сброс поле подачи питания, а бит BORRSTF - за сброс от детектора снижения напряжения. 

Таким образом, если при не штатном сброс будут ВЫСТАВЛЕНЫ еще какие либо биты, кроме PINRSTF, то дело не в ножке сброса. 

Добрый день!

Если я правильно понял, для диагностики причины сброса по этому пути мне надо
в начале main вероятно сразу после SystemCoreClockUpdate(); и SysTick_Config();
написать что то вроде вот этого:

uint8_t byte_errreset=0;

if((RCC->CSR & RCC_CSR_PORRSTF) == 1){byte_errreset=byte_errreset|1;}
if((RCC->CSR & RCC_CSR_BORRSTF) == 1){byte_errreset=byte_errreset|2;}
if((RCC->CSR & RCC_CSR_PINRSTF) == 1){byte_errreset=byte_errreset|4;}

потом  этот byte_errreset проще всего по uart скинуть

На строчку с RCC_CSR_PINRSTF компилятор ругается - посмотрел в stm32hxx.h нет бита RCC_CSR_PINRSTF или он как то иначе называется..

Изменено 7 октября, 2023 пользователем aske1

[EdgeAligned 53]

Такс, я писал названия по памяти, да еще и со смартфона, мож где чего ошибся. Ща проверим...

[aske1 0]

1 час назад, aske1 сказал:

 

На строчку с RCC_CSR_PINRSTF компилятор ругается - посмотрел в stm32hxx.h нет бита RCC_CSR_PINRSTF или он как то иначе называется..

 

Похоже его почему то так обозвали RCC_CSR_PADRSTF, хотя в документации реально как у вас название

Изменено 7 октября, 2023 пользователем aske1

[EdgeAligned 53]

Да, действительно, обозван этот флаг как PADRSTF. Ну да ладно. 

	/* Проверка флагов причины сброса */
	switch(RCC->CSR & (RCC_CSR_PORRSTF | RCC_CSR_PADRSTF | RCC_CSR_BORRSTF | RCC_CSR_SFTRSTF)) {
	case RCC_CSR_PORRSTF | RCC_CSR_BORRSTF | RCC_CSR_PADRSTF:
		// сброс по питанию (POR/PRD, BOR) (флаг NRST тоже будет выставлен)
		GPIOG->BSRRL = 1 << 13; // зеленый светик
		break;
	case RCC_CSR_PADRSTF:
		// сброс только от NRST
		GPIOG->BSRRL = 1 << 14;	// красный светик
		break;
	default:
		break;
	}
	RCC->CSR |= RCC_CSR_RMVF;	// очистка флагов причины сброса

Флаг PADRSTF выставляется при всех причинах сброса, поскольку внутренняя схема дублирует этот сигнал на ножку NRST. Флаг SFTRSTF - это флаг программного сброса, инициируемого программной командой. При подключении отладчика софтовый сброс генерируется отладчиком.

[aske1 0]

5 часов назад, EdgeAligned сказал:

Да, действительно, обозван этот флаг как PADRSTF. Ну да ладно. 

	/* Проверка флагов причины сброса */
	switch(RCC->CSR & (RCC_CSR_PORRSTF | RCC_CSR_PADRSTF | RCC_CSR_BORRSTF | RCC_CSR_SFTRSTF)) {
	case RCC_CSR_PORRSTF | RCC_CSR_BORRSTF | RCC_CSR_PADRSTF:
		// сброс по питанию (POR/PRD, BOR) (флаг NRST тоже будет выставлен)
		GPIOG->BSRRL = 1 << 13; // зеленый светик
		break;
	case RCC_CSR_PADRSTF:
		// сброс только от NRST
		GPIOG->BSRRL = 1 << 14;	// красный светик
		break;
	default:
		break;
	}
	RCC->CSR |= RCC_CSR_RMVF;	// очистка флагов причины сброса

Флаг PADRSTF выставляется при всех причинах сброса, поскольку внутренняя схема дублирует этот сигнал на ножку NRST. Флаг SFTRSTF - это флаг программного сброса, инициируемого программной командой. При подключении отладчика софтовый сброс генерируется отладчиком.

спасибо, буду пробовать

[_Sergey_ 13]

On 10/8/2023 at 1:38 PM, aske1 said:

спасибо, буду пробовать

Ну и как?

[aske1 0]

1 час назад, _Sergey_ сказал:

Ну и как?

Пока не было возможности у заказчика, я напишу когда удастся поработать

[aske1 0]

Пару недель назад таки появилась возможность поработать над проблемой, к сожалению времени было отведено мало. Поэтому сделал всё и сразу:

1) отрезал идущую далеко на разъём дорожку от ножки сброса;

2) с ножки сброса убрал всё лишнее, оставил лишь 0,1 мкФ как по даташиту

3) дополнительно навесил емкостей вокруг мк по питанию

4) зашил прошивку, в которую добавил фрагмент для установления причины сброса

 

  Правда к сожалению к нашему приезду нагрузка уже была достаточно хорошо отработана и в общем то перестала пробиваться, поэтому проверить помогли ли решения да и вообще увидеть проблему повторно пока не удалось.

Изменено 22 ноября, 2023 пользователем aske1

[aske1 0]

На будущее собираюсь переразвести плату,дополнительно хотелось бы по возможности уменьшить стоимость. В связи с этим вопрос: насколько я понял из прочитанного выше при не правильной разводке (с точки зрения помехозащищенности) оптроны не помогают. А если разводка выполнена правильно (контроллер ничем не окружен т.е. расположен в углу платы и правильно выбрана точка заземления), то их лучше выкинуть или всё таки оставить?

И ещё: у нас из покон веков мк отделен от внешних цепей с помощью оптронов и имеет свой собственный dc/dc - преобразователь по питанию, соответственно внешние цепи после оптронов тоже имеют свой dc/dc, общие точки этих двух dc/dc не связаны друг с другом. Я так понимаю, что  если оптроны останутся правильно заземлять общую точку dc/dc -преобразователя питающего внешние цепи, а общую точку dc/dc -преобразователя питающего мк правильно оставлять висящей в воздухе или это не так?     

Изменено 22 ноября, 2023 пользователем aske1

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

7 минут назад, aske1 сказал:

у нас из покон веков

Из чего веков???

8 минут назад, aske1 сказал:

а общую точку dc/dc -преобразователя питающего мк правильно оставлять висящей в воздухе

Чтобы на нее навелся потенциал больше пробивного напряжения оптронов?

[aske1 0]

15 минут назад, Сергей Борщ сказал:

Из чего веков???

 

с незапамятных времен

16 минут назад, Сергей Борщ сказал:

Чтобы на нее навелся потенциал больше пробивного напряжения оптронов?

Таким образом, хотите сказать, что её надо тоже заземлять. Но тогда получается, что у меня входа/выхода платы и мк будут гальванически связаны и тогда в чем смысл оптронов?