STM32F1->MCO качество сигнала Опции

[Tahoe]

STM32F100, пин PA8, с альтернативными функциями USART1_CK / MCO / TIM1_CH1. Таймер1 отключен. USART1 включен, работает в асинхронном режиме. Включил MCO ( вывод клока для внешнего использования ), в качестве источника клока HSI. Наблюдаю такую картину, в моменты передачи по USART1:



Круто. Сам сигнал с MCO выводится для тактирования ПЛИС.

Кто-нить уже сталкивался с подобным?

С инициализацией проблем нет, там всего две строчки:

Код

void    BspPldInit( void )
{
    McuPinConfig(        MCU_PIN_PA08,        MCU_PIN_MODE_OUT_PP_AF_10MHz    );
    McuClkOutConfig(    MCU_CLK_OUT_SRC_HSI                                 );
}

[diwil]

подтверждаю.
когда работает уарт на передачу, то он создает массу помех.
В некоторых случаях становится даже невозможным использования АЦП.
У меня еще и таймер генерит 400кГц - на этом выходе тоже жуткая наводка.
Правда это наблюдается на f405.

[DASM]

А можно посмотреть код инициализации на уровне ассемблера, а не дурацких макросах от стм?

[DASM]

Очередной "бэгрипорт" не состоялся ?

[ViKo]

Круто. Сам сигнал с MCO выводится для тактирования ПЛИС.

Не могу в это поверить. С печатными проводниками всё нормально, ничто ни за что не зацепилось?

[Tahoe]

Не могу в это поверить. С печатными проводниками всё нормально, ничто ни за что не зацепилось?

На PCB напортачить практически не реально, всего один короткий проводник.

Очередной "бэгрипорт" не состоялся ?

Пока просто интересует опыт тех, кто _реально_ работал с сабж.

а не дурацких макросах от стм?

- они не дурацкие, а единообразные на всех используемых мной архитектурах МК, что для ARM, что для AVR, что для MSP
- не макросы
- не от ST

Сообщение отредактировал IgorKossak - May 30 2013, 14:53

[Genadi Zawidowsk...]

Ну пять-то вольт откуда в процессоре вообще? Это не из ПЛИС идёт? Я использовал выход для контроля в целиком работающей системе (STM32F105) - ничего необъяснимого не наблюдал.

[Tahoe]

Ну пять-то вольт откуда в процессоре вообще? Это не из ПЛИС идёт?

Нет. На плате всего одно питание 3,3В. Масштаб каритнки 0,5В в клетке.

Я использовал выход для контроля в целиком работающей системе (STM32F105) - ничего необъяснимого не наблюдал.

С работающим UART1?

[ViKo]

А вы посмотрите, что делается на разных концах 100 Ом резистора. Частота MCO у вас меньше частоты паразитных тактов (больше похоже на такты, чем на данные, очень уж регулярные). Может, из ПЛИС что-то лезет? Амплитуда MCO меньше 2В - тоже странно.

MCO использую для тактирования контроллера ЖКИ. Работает. Правда, бывают некие редкие пропадания картинки. Думал, программые косяки. Гляну внимательнее на такты.

[Genadi Zawidowsk...]

Нет. На плате всего одно питание 3,3В. Масштаб каритнки 0,5В в клетке.


С работающим UART1?

Во всяком случае, с проинициализированным. 57600 при тактовой процессора 72 МГц, внешний 8 МГц кварц.

Сообщение отредактировал Genadi Zawidowski - May 31 2013, 22:37

[khach]

Кто-нить уже сталкивался с подобным?

С инициализацией проблем нет, там всего две строчки:

С чем сталкивались? С кривой инициализацией многфункционального пина? Постоянно. Обычно по причине криворукости программистов при использвании стандарных библиотек. Инициализацию USART1 еще покажите (вернее его ножек)- очень вероятно что USART1_CK активен и подключен к ноге.
Зы. Иногда это глюки самого кристалла инжинерных ревизий- попробуте поменять порядок инициализации периферии в стартапе программы.

[DASM]

Абсолютно поддерживаю. Если Вы видели эти стмовские полумакросы-полуфункции (иногда и не понять что есть что, где он начинается, от чего перекрестно зависит и главное - зачем он нужен для выставления одного бита при старте проца) то все поймете.

[koyodza]

Использовал МСО для тактирования внешнего АЦП частотой 12МГц (выход HSE), был задействован USART1, всё отлично работало. Правда, на F103, но это скорее всего не важно.
Проверьте, не установлен ли бит CLKEN в USART1->CR2
Если на пин выведены альтернативные функции от нескольких модулей, нужно быть внимательным и не допускать одновременной работы таких модулей либо блокировать работу альтернативной функции в одном из модулей. В Вашем случае выход CLK у USART1 должен быть запрещен.

Если Вы видели эти стмовские полумакросы-полуфункции (иногда и не понять что есть что

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

[DASM]

Да никто не против, а еще лучше - привести кусок дизасма, но автор убежал.

[scifi]

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

Это уже пошёл оффтопик, но я, тем не менее, вставлю свои 5 копеек. Всегда манипулировал регистрами, опираясь только на Reference Manual. Всё получалось. Библиотеку не использовал из-за неприязни (кривой она показалась). Сейчас, однако, мог бы и потерпеть неприязнь, если библиотека реально ускоряет разработку: жизнь слишком коротка. Старею, наверное :-)

[ViKo]

Всегда манипулировал регистрами, опираясь только на Reference Manual. Всё получалось. Библиотеку не использовал из-за неприязни (кривой она показалась)...

Аналогично. Но вот, подбираюсь к USB, и, поскольку дело новое и, говорят, тяжелое, не знаю, что лучше - разбираться самому с битами или разбираться с функциями (и потом все равно с битами).

[Golikov A.]

2 раза на 2 разных процах написал без библиотек по мануалу.
В обоих случаях нашел несколько ошибок в предложенных примерах реализации, и пару неточностей...
Фиг знает, может это старость и консерватизм, но так я и не научился доверять чужому бесплатному коду без проверки...

[ViKo]

2 раза на 2 разных процах написал без библиотек по мануалу.

Вы говорите об USB или, вообще, о программе для микроконтроллера?

[Tahoe]

Проверьте, не установлен ли бит CLKEN в USART1->CR2

Сначала как раз так и было. И на выходе наблюдал клок от USART. Но на момент создания топика, режим USART был изменен на асинхронный.

Как раз при отказе от библиотечных функций часто и возникают ошибки, связанные с неправильной инициализацией периферии.

Именно потому и спросил, сталкивался кто-либо с подобным.

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

Скажу больше. Пришлось даже сделать то, что делать не люблю - самостоятельно задефайнить биты в регистрах, вроде:

Код

...
typedef    enum    STM32_USART_SR_e
{
    STM32_USART_SR_PE                            =     0,
    STM32_USART_SR_FE                            =     1,
    STM32_USART_SR_NE                            =     2,
    STM32_USART_SR_ORE                            =     3,
    STM32_USART_SR_IDLE                            =     4,
    STM32_USART_SR_RXNE                            =     5,
    STM32_USART_SR_TC                            =     6,
    STM32_USART_SR_TXE                            =     7,
    STM32_USART_SR_LBD                            =     8,
    STM32_USART_SR_CTS                            =     9
}    STM32_USART_SR;

typedef    enum    STM32_USART_CR1_e
{
    STM32_USART_CR1_SBK                            =     0,
    STM32_USART_CR1_RWU                            =     1,
    STM32_USART_CR1_RE                            =     2,
    STM32_USART_CR1_TE                            =     3,
    STM32_USART_CR1_IDLEIE                        =     4,
    STM32_USART_CR1_RXNEIE                        =     5,
    STM32_USART_CR1_TCIE                        =     6,
    STM32_USART_CR1_TXEIE                        =     7,
    STM32_USART_CR1_PEIE                        =     8,
    STM32_USART_CR1_PS                            =     9,
    STM32_USART_CR1_PCE                            =    10,
    STM32_USART_CR1_WAKE                        =    11,
    STM32_USART_CR1_M                            =    12,
    STM32_USART_CR1_UE                            =    13,
    STM32_USART_CR1_OVER8                        =    15
}    STM32_USART_CR1;

...

В реальности, с учетом нехватки времени, процесс выглядит немного иначе.при необходимости задействовать в очередном проекте ту или иную периферию, под нее создается библиотека. В общем, конечно, она проверяется на предмет всех режимов, но понятно дело, что проблемы вылезают только в тех режимах, которые используются в данном проекте. На примере того же USART - если на момент создания библиотеки, в проекте использовался асинхронный режим, по понятным причинам именно он протестирован наиболее тщательно.
С другой стороны, единообразие, при кодировании, позволяет свести потенциальные ошибки к минимуму.

Всегда манипулировал регистрами, опираясь только на Reference Manual. Всё получалось. Библиотеку не использовал из-за неприязни (кривой она показалась). Сейчас, однако, мог бы и потерпеть неприязнь, если библиотека реально ускоряет разработку: жизнь слишком коротка. Старею, наверное :-)

Подход, конечно, правильный. Но я, например, последнее время, постоянно сталкиваюсь с невысоким качеством кода. Собсно, последний раз, когда я видел/использовал пристойный код от производителей микроконтроллеров, это был USB-стек от Атмел - хорошо типизированый, с вменяемой структурой.
Что касается библиотек, то помнится напарывался у того же Атмел, в ней же была проблема при работе с SPI, что-то касательно SS. А про ST даже говорить не хочу.

Да никто не против, а еще лучше - привести кусок дизасма, но автор убежал.

Нет, .... Никто, никуда не убежал. Все банальнее:

2. ... нахожусь в сильном цейтноте.

[Golikov A.]

Вы говорите об USB или, вообще, о программе для микроконтроллера?

про УСБ конечно)), если бы я всего 2 программы написал, я бы постеснялся вообще говорить на армах и на 51 ядре на двух разных контроллерах с подержкой усб. Причем на 51 ядре было очень низкоуровневая поддержка, там очень много чего надо было руками делать, в армах намного проще сейчас. В первом случае ушло около 2 месяцев, но я там еще и стандарт усб изучал, во втором случае около месяца с отладкой.

[jcxz]

Аналогично. Но вот, подбираюсь к USB, и, поскольку дело новое и, говорят, тяжелое, не знаю, что лучше - разбираться самому с битами или разбираться с функциями (и потом все равно с битами).

Если на LPC (ARM7 и Cortex-M3) - я использовал стек из примеров NXP. Что-то в нём переделал/оптимизировал, на что-то закрыл глаза. Но можно его юзать и как есть - вполне работоспособный хоть и не оптимальный.
Использовал control- и изохронные передачи, с DMA и без.
На OMAP-L137 пришлось писать свой стек, так как варианты были - или брать готового кота в мешке со встроенной непонятной ОС и в бинарниках (а по объёму занимаемых ресурсов - не кота, а слона), или из-за стека тащить в нормально работающую реалтайм-систему линух.
Использовал и на 51-ядре, но это отдельная песня.
На написание стека на ARM-ядро OMAP у меня примерно так же как и у уважаемого Golikov A. ушло около месяца (на базе знаний полученных ранее при использовании стеков от NXP).