Непонятное прерывание stm32

[Hives]

sosedi и на какой инструкции он улетает?

[_Артём_]

_Артём_ запиши: ничто не происходит мгновенно.
сброс флага не сразу сбраcывает запрос на irq, и поэтому можно еще раз вернуться в него после завершения обработчика.

Кстати да - такое возможно.

а у stm32 есть плюшка -

Только не у STM эта плюшка, а Cortex-M.
Вот такой вот пример для EFM:

OS_INTERRUPT void OS::SystemTimer_ISR() // прерывание от RTC
{
	*(volatile uint32_t *)0xE0001004=0;
	/* Clear interrupt source */
	RTC_IntClear(RTC_IFC_COMP0);
	/* Flushing instructions to make sure that the interrupt is not re-triggered*/
	/* This may be required when the peripheral clock is slower than the core */
	__DSB();
	{ // это обработчик 

		scmRTOS_ISRW_TYPE ISR;

#if scmRTOS_SYSTIMER_HOOK_ENABLE == 1
		system_timer_user_hook();
#endif
		Kernel.system_timer();
	}
}

Местами барьеры надо использовать.

[sosedi]

sosedi и на какой инструкции он улетает?

К сожалению на какой инструкции он туда переходит я не могу узнать((а в каких случаях он может туда "Default_Reset_Handler()" переходить???

[ewseltek]

Лично я столкнулся с такой неприятностью- периферию сначала надо сбрасывать -
а то она себя ведет непредсказуемо - в частности таймеры- правда сейчас я копаюсь с
F103- там у них есть ф-я типа RccReset-а без этого волосы дыбом вставали.

[sosedi]

Тема все еще актуальна ((( но кстати выяснились некоторые моменты! к примеру если ткнуться осциллографом на ножку NRST то там проскакивает каждые 500мс сброс!!!!! Поискав немного в даташите(rm0090) нашел на странице 82 возможные причины сброса, в итоге это IWDG !!!!!!!!!!!Да, сброс его можно обойти - записью значений в переполняемый регистр, но почему он вообще включен? как его отключить ???

[Hives]

глянь доку PM0075, пункт 2.5

[Mike121234]

_Артём_ запиши: ничто не происходит мгновенно.
а у stm32 есть плюшка - сброс флага не сразу сбраcывает запрос на irq, и поэтому можно еще раз вернуться в него после завершения обработчика.

Да... А у меня вот что было:
пользую несколько прерываний. UART - ВЫСОКИЙ приоритет, таймер - низкий.
Скидывал прерывание по таймеру перед выходом из обработчика. Ну дак вот: непредсказуемо, через некоторое время переставал попадать на прерывание от таймера. А uart - все отлично - попадал по приходу данных.

ЛЕЧЕНИЕ: стал скидывать прерывание сразу, первой командой. И все работает.

А вот еще глюк. Есть таймер, который работает с автоперезагрузкой в 1мС. Есть вход, на который поступают импульсы. Ловим по перепаду, и определяем длительность по таймеру.
У таймера - более низкий приоритет. Программа - ни о чем, простая. Больше прерываний нет. в mane только while(1).
Время обработки прерывания около 10 мкС. Импульсы поступают 6 - 20мСек.
Все работает. Но иногда прога залетает в обработчик таймера и сидит там 30!!!!!!! мСек
И потом все опять ок....

Лечится - ставим более высокий приоритет на таймер, чем на прерывание по фронту....


Вот здесь человек пишет про грабли с прерываниями (скидывать надо сразу при входе в ф-ию!!!!) и про файлики

А вообще, подключите все фалики к проекту :system_stm32f10x.c, startup_stm32f10x_md_vl.s, core_cm3.c - надежнее будет. /цитата/

http://www.be-em.ru/stm32-%D0%B2%D0%...D%D0%B8%D1%8F/

[Boba_spb]

в mane

Мишаня, весна на носу? Маня вместо main - это по Фрейду !!