Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Глюк UART у STR91x
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Aprox
Долго искал свой случай непонятного поведения UART на этом форуме и не нашел. Обращаюсь за помощью к коллегам.
Возникла проблема с установкой BaudRate для UART кристалла STR910FAM32. Исходные данные самые обычные 8бит, NoParity,1stop, скорость 9600. Отклонение от рекомендаций- отключил FiFo приемника. Частота кварца 25 MГц, стандартно использую PLL для генерации 96Мгц, для конфигурации устройства использую фирменную StdLib. Короче, все абсолютно стандартно и в точном соответствии с мануалом и примерами в нем. Однако, вместо заявленной скорости следования битов 9600 вижу осциллографом скорость на 2.2% меньше, т.е. 9403. И такое занижение в 2% наблюдаю на всех скоростях, какие бы не устанавливал. Работать невозможно! Проверял частоту задающего кварца- 25.00002 МГц, т.е. отклонением в 2% и не пахнет. Мысли иссякли и попросту стал конфигурировать BaudRate генератор на 9800, чтобы он все-таки заработал на стандарте в 9600. Но хочется все-таки разобраться. Кто сталкивался с подобной проблемой? В чем дело? Может кто видел подобную багу на других форумах?
MALLOY2
у нас активно применяются STR912, UART использовал по разному и с разных сторон smile.gif, никаких нареканий на работу нет! это вы что то не так конфигурируете.

Библиотеку ST не пользую, чего и вам советую.

Вот для примера мой драйвер уарта, может чего присмотрите.

На всяк код инициализации PLL

Код
SCU_CLKCNTR_bit.MCLKSEL   = 2;            //fMSTR = fOSC;
  __no_operation();
  __no_operation();
  __no_operation();
  __no_operation();
  __no_operation();
  __no_operation();
  __no_operation();
  __no_operation();
  __no_operation();
  __no_operation();
  SCU_CLKCNTR_bit.RCLKDIV   = RCLK_DIV;
  SCU_CLKCNTR_bit.AHBDIV    = HCLK_DIV;
  SCU_CLKCNTR_bit.APBDIV    = PCLK_DIV;
  SCU_CLKCNTR_bit.BRSEL     = BRCLK_DIV;
  SCU_CLKCNTR_bit.USBSEL    = USBCLK_DIV;
  SCU_CLKCNTR_bit.PHYSEL    = 0;//MII_PHYCLK output disabled (default)
  SCU_CLKCNTR_bit.TIM01SEL  = 0;//timer External clock disabled
  SCU_CLKCNTR_bit.TIM23SEL  = 0;//timer External clock disabled
  SCU_CLKCNTR_bit.FMISEL    = FMICLK_DIV;
  SCU_CLKCNTR_bit.EMIRATIO  = EMI_BCLK_DIV;        
  SCU_PWRMNG = 0x80;          //run mode,The Flash is not to enter power down mode during debug mode, Interrupt code executes at the speed defined by the RCLKDIV[2:0]
  SCU_ITCMSK = 0x1F;          //all masked
  SCU_SCR0_bit.P30_SELEDBG =  0;//Port 3.0 not configured for External Debug Request / ETM trigger
  /************************* FLASH & SRAM CONFIG ************************************/
  //PCGR0
  SCU_PCGR0_bit.FMI =1;
  SCU_PCGR0_bit.PQFBC =1;
  SCU_PCGR0_bit.SRAM_ARBITER =1;
  SCU_PCGR0_bit.SRAM = 1;
  //PRR0
  SCU_PRR0_bit.RST_PFQBC_AHB = 1;
  SCU_PRR0_bit.RST_SRAM_ARBITER = 1;
  SCU_PRR0_bit.RST_PQFBC = 1;
  SCU_PRR0_bit.RST_FMI = 1;
  //MGR0
  SCU_MGR0_bit.MSK_SRAM_ARBITER = 1;
  SCU_MGR0_bit.MSK_SRAM = 1;
  SCU_MGR0_bit.MSK_PQFBC = 1;
  //PECGR0
  SCU_PECGR0_bit.SRAM_ARBITER = 1;
  SCU_PECGR0_bit.SRAM = 1;
  SCU_PECGR0_bit.PQFBC = 1;
  SCU_PECGR0_bit.FMI = 1;
  /************************* PLL INIT **********************************************/
  SCU_PLLCONF = 0;                   //disable PLL clear divider
  SCU_PLLCONF |= (192<<8);           //update PLLN field
  SCU_PLLCONF |=  25;                //update PLLM field
  SCU_PLLCONF |= (2<<16);            //update PLLP field
  SCU_PLLCONF_bit.PLL_EN = 1;        //enable PLL 96 MGz
  while (!(SCU_SYSSTATUS&bPLL_LOCK));//ждем захвата PLL
  SCU_CLKCNTR_bit.MCLKSEL   = 0;     //fMSTR = fPLL;
scifi
Цитата(Aprox @ Jan 30 2010, 11:19) *
Однако, вместо заявленной скорости следования битов 9600 вижу осциллографом скорость на 2.2% меньше, т.е. 9403. И такое занижение в 2% наблюдаю на всех скоростях, какие бы не устанавливал. Работать невозможно! Проверял частоту задающего кварца- 25.00002 МГц, т.е. отклонением в 2% и не пахнет.

Даже если бы PLL был настроен неверно, отклонение было бы существенно больше. Поэтому следующий кандидат - тот самый StdLib: возможно, они напортачили в формуле расчёта BaudRate.
Лично я программирую регистры сам, по мануалу. Считаю, что эта их библиотека - всего лишь ещё один источник глюков. Сидят какие-то непонятные деятели в Тунисе и Чехии и строгают какой-то непонятный код. Мне и стиль форматирования их исходников не нравится :-)
Aprox
Цитата(scifi @ Jan 30 2010, 22:50) *
Даже если бы PLL был настроен неверно, отклонение было бы существенно больше. Поэтому следующий кандидат - тот самый StdLib: возможно, они напортачили в формуле расчёта BaudRate.
Лично я программирую регистры сам, по мануалу. Считаю, что эта их библиотека - всего лишь ещё один источник глюков. Сидят какие-то непонятные деятели в Тунисе и Чехии и строгают какой-то непонятный код. Мне и стиль форматирования их исходников не нравится :-)
Тут, для экономии времени выбирать особо не приходится. Удивительно другое, я проверял отладчиком реального времени, какие именно значения грузятся в главный делитель и в фракшион. Все точно считает и грузит библиотека! В точности по мануалу и даже совпадает с таблицей примеров установки скорости передачи. А в реале скорость на 2% меньше.! Тут уж полный писец какой-то! Скорей ошибка в мануале, в формулах расчета скорости. Или, есть еще вероятность, что отключение FiFo как-то может влиять на скорость, например, добавляет клоки в автомат. Где-нибудь, такое уже обсуждали?


Цитата(MALLOY2 @ Jan 30 2010, 11:40) *
у нас активно применяются STR912, UART использовал по разному и с разных сторон smile.gif, никаких нареканий на работу нет! это вы что то не так конфигурируете.

Библиотеку ST не пользую, чего и вам советую.
Вот для примера мой драйвер уарта, может чего присмотрите.
Спасибо большое. Hо на разбирательства нет времени. По поводу ST библиотеки пока претензий не имею. В моем случае, она конфигурирует UART точно по мануалу (проверялось JTAG отладчиком содержимое регистров). Думаю, проблема в другом месте.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.