SMRM 0 28 мая, 2013 Опубликовано 28 мая, 2013 · Жалоба Уважаемые коллеги подскажите в чем проблема. Кристалл MSP430F5418A. Использую DCO как клок для SMCLK. Калибрую через FLL кварцем 32kHz клок для UART. Ухожу в LPM3. При передачи в UART данных все запускается и ловит данные для ревизии revE. Все это работает и давно. Сейчас закупили ревизию F. Перестал работать UART(данные не ловятся). Но под JTAG работает и ревизия F. В errate пишут что в rev E оставался вкл SMCLK, а в rev F это устранили. Проверял под JTAG с помощью запрета SMCLKREQEN запускается ли процедура старта генерации для UART. Когда SMCLKREQEN = 1, прием UART работает. Когда SMCLKREQEN = 0 не работает. Делаю вывод что запуск клока для UART из LPM3 при правильной настройке SMCLKREQEN работает. Что не так? Заранее благодарю за помощь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 28 мая, 2013 Опубликовано 28 мая, 2013 · Жалоба Чтобы не гадать какие именно "чудеса" вносит сам отладчик, проверьте работу на "чистом железе" без использования отладчика. Скорректируйте свою программу. Выведите SMCLK на соответствующий пин (переключите функцию пина для вывода SMCLK) и в штатном режиме с использованием LPM3 проконтролируйте с помощью осциллографа активацию SMCLK при приеме UART. Когда SMCLKREQEN = 1, прием UART работает. Когда SMCLKREQEN = 0 не работает. Делаю вывод что запуск клока для UART из LPM3 при правильной настройке SMCLKREQEN работает. Что не так? Вывод некорректный. В том смысле, что SMCLKREQEN = 1 это условие необходимое, но не достаточное. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SMRM 0 30 мая, 2013 Опубликовано 30 мая, 2013 · Жалоба Чтобы не гадать какие именно "чудеса" вносит сам отладчик, проверьте работу на "чистом железе" без использования отладчика. Скорректируйте свою программу. Выведите SMCLK на соответствующий пин (переключите функцию пина для вывода SMCLK) и в штатном режиме с использованием LPM3 проконтролируйте с помощью осциллографа активацию SMCLK при приеме UART. Вывод некорректный. В том смысле, что SMCLKREQEN = 1 это условие необходимое, но не достаточное. Спасибо за подсказку! Сделал как предложили и увидел на осциллографе что старт SMCLK есть, но продолжительное время частота не та которую задаю с помощью DCO+FLL. Только значительно позже частота становится требуемой(8 мГц). За это время уже все данные пропали. Как я понял по документации по старт биту UART через SMCLKREQEN запускается только DCO(так как при вызове прерывания SCG0 остается в 1. Попробовал для решения вопроса организовать прерывание NMI в котором сбрасываю SCG0. Не помогло. Возможно при моей настройке нельзя из LPM3 организовать корректный запуск генератора и прием на UART(baud 115200, хотя пробовал и для 9600). Мои настройки: UCSCTL4 = (SELA__XT1CLK + SELM__DCOCLK + SELS__DCOCLK); __bis_SR_register(SCG0); // Disable the FLL control loop UCSCTL0 = 0x0000; // Set lowest possible DCOx, MODx UCSCTL1 = DCORSEL_4; // Set RSELx for DCO UCSCTL2 = FLLD_0 + 243; // Set DCO Multiplier for 8MHz __bic_SR_register(SCG0); // Enable the FLL control loop Может кто встречал такую ситуацию и что подскажет. Заранее благодарю за помощь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 30 мая, 2013 Опубликовано 30 мая, 2013 · Жалоба Насколько я понял вашу ситуацию, она описана прямо в Errata. См. баги UCS7 и UCS10. Суть в том, что включение DCO+FLL при выходе из LPMx приводит к такому эффекту, что частота "выводится" к заданному значению довольно длительное время. Чтобы этого избежать нужно ДО перехода в режим энергосбережения ВЫключить FLL, оставив DCO с теми значениями (в регистре UCSCTL0), которые ему "подкрутила" система FLL. Тогда при выходе из режима энергосбережения частота будет сразу близка к требуемой (той, что была "до того как"). Уход частоты будет обусловлен лишь дрейфом внешних факторов (температура и напряжение питания). Но внешние факторы можно контролировать и при значительном их изменении запускать подстройку частоты вновь. Есть еще один нюанс использования FLL вкупе с DCO - дрожание фазы сигнала битовой синхронизации BITCLK из-за постоянного изменения модуляции DCOCLK (а следовательно и SMCLK) системой FLL. Workaround аналогичный - использовать FLL только для начальной подстройки частоты DCO, а затем FLL отключать. Небольшую подстройку частоты можно делать аппаратно-программно, используя TimerB и сигнал ACLK. ACLK можно внутренне скоммутировать на вход захвата CCI6B (см. в datasheet Table 12. TB0 Signal Connections). Настроить таймер на непрерывный режим счета от SMCLK и режим захвата по фронту для CCR6. При каждой установке флага ССIFG в регистре TB0CCTL6 в регистре TB0CCR6 будет лежать величина пропорциональная отношению частот SMCLK и ACLK. Изменяя значения в регистре модуляции DCO следует добиться требуемого отношения (значения частоты DCOCLK, а значит и SMCLK) Такой способ подстройки DCO (с помощью таймера и ACLK) использовался для MSP430 еще с "незапамятных" времен даже на тех кристаллах, где FLL не было. И обязательно гляньте Аpplication report UCS10 Guidance (SLAA489). P.S. Еще один варант. Используйте для тактирования UART в режиме энергосбережения сигнал ACLK, получаемый от часового кварца. Такой вариант также описан в Workaround. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
arhiv6 14 4 декабря, 2015 Опубликовано 4 декабря, 2015 · Жалоба А может кто-то подробнее раскрыть эту тему? Пробую на МК MSP430F5529 и CC430F6147. Тактирую от DCO+FLL, в качестве опоры - часовой кварц (XT1CLK). UART 115200 тактируется от SMCLK (8МГц). Если переводить в LPM0 - всё работает. Если переводить в LPM2 или LPM3 - МК перестаёт отвечать. По совету rezident попробовал после того, как установится частота DCO, отключать FLL и только после этого переходить в сон, но это не помогает. Для отключения FLL достаточно выполнить __bis_SR_register(SCG0) ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mcheb 0 4 декабря, 2015 Опубликовано 4 декабря, 2015 · Жалоба 115200 для LPM3 много. 9600 нормально. Из LPM3 выход >5 мксек, а 115200 < 10 мксек. Вот данные и теряются. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 6 декабря, 2015 Опубликовано 6 декабря, 2015 · Жалоба Вариант устранения не причины, а последствий. В начале пакета данных, который принимаете, прикрутите "ракорд" из N байт. (для пробудки и выхода приемника на режим). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
arhiv6 14 5 января, 2016 Опубликовано 5 января, 2016 (изменено) · Жалоба Перевёл проект на скорость 9600. Тест такой же - по прерыванию от UART контроллер отправляет принятое обратно (UCA0TXBUF = UCA0RXBUF;). В LPM0 и LPM1 данные возвращаются без ошибок, в LPM2 и LPM3 данные возвращаются с ошибками. Если отправлять один байт - в нём данные сдвинуты на бит (отправили 0b01101100, приняли 0b10110110). Если отправлять несколько байт подряд - часть вообще теряется, остальные возвращаются с ошибками. В чём может быть проблема? У кого-нибудь есть практический опыт работы в таком режиме - на какой скорости обмена точно работало? Изменено 5 января, 2016 пользователем arhiv6 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mcheb 0 5 января, 2016 Опубликовано 5 января, 2016 · Жалоба Затактировать УАРТ от 32кГц (ACLK) на 9600 и всё Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
arhiv6 14 5 января, 2016 Опубликовано 5 января, 2016 · Жалоба В таком случае ошибка составит до 17.19% - слишком много. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mcheb 0 5 января, 2016 Опубликовано 5 января, 2016 · Жалоба В таком случае ошибка составит до 17.19% - слишком много. Нашёл в загашниках, на 9600 работало /* --COPYRIGHT--,BSD_EX * Copyright (c) 2012, Texas Instruments Incorporated * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * * Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * * Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * * Neither the name of Texas Instruments Incorporated nor the names of * its contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * ******************************************************************************* * * MSP430 CODE EXAMPLE DISCLAIMER * * MSP430 code examples are self-contained low-level programs that typically * demonstrate a single peripheral function or device feature in a highly * concise manner. For this the code may rely on the device's power-on default * register values and settings such as the clock configuration and care must * be taken when combining code from several examples to avoid potential side * effects. Also see www.ti.com/grace for a GUI- and www.ti.com/msp430ware * for an API functional library-approach to peripheral configuration. * * --/COPYRIGHT--*/ //****************************************************************************** // CC430F513x Demo - USCI_A0, UART 9600 Full-Duplex Transceiver, 32K ACLK // // Description: USCI_A0 communicates continuously as fast as possible // full-duplex with another device. Normal mode is LPM3, with activity only // during RX and TX ISR's. The TX ISR indicates the UART is ready to send // another character. The RX ISR indicates the UART has received a character. // At 9600 baud, a full character is tranceived ~1ms. // The levels on P1.4/5 are TX'ed. RX'ed value is displayed on P1.0/1. // ACLK = BRCLK = LFXT1 = 32768, MCLK = SMCLK = DCO~ 1048k // Baud rate divider with 32768hz XTAL @9600 = 32768Hz/9600 = 3.41 (0003h 4Ah) // // // CC430F5137 CC430F5137 // ----------------- ----------------- // /|\ | XIN|- /|\ | XIN|- // | | | 32KHz | | | 32KHz // --|RST XOUT|- --|RST XOUT|- // | | | | // | | | | // | | | | // ->|P1.4 | | P1.0|-> LED // ->|P1.5 | | P1.1|-> LED // LED <-|P1.0 | | P1.4|<- // LED <-|P1.1 | | P1.5|<- // | UCA0TXD/P2.7|--------->|P2.6/UCA0RXD | // | | 9600 | | // | UCA0RXD/P2.6|<---------|P2.7/UCA0TXD | // // // M Morales // Texas Instruments Inc. // April 2009 // Built with CCE Version: 3.2.2 and IAR Embedded Workbench Version: 4.11B //****************************************************************************** #include <msp430.h> int main(void) { WDTCTL = WDTPW+WDTHOLD; // Stop watchdog timer P5SEL |= 0x03; // Enable XT1 pins do { UCSCTL7 &= ~(XT1LFOFFG + DCOFFG); // Clear XT2,XT1,DCO fault flags SFRIFG1 &= ~OFIFG; // Clear fault flags __delay_cycles(100000); // Delay for Osc to stabilize }while (SFRIFG1&OFIFG); // Test oscillator fault flag P1OUT = 0x000; // P1.0/1 setup for LED output P1DIR |= BIT0+BIT1; // PMAPPWD = 0x02D52; // Get write-access to port mapping regs P2MAP6 = PM_UCA0RXD; // Map UCA0RXD output to P2.6 P2MAP7 = PM_UCA0TXD; // Map UCA0TXD output to P2.7 PMAPPWD = 0; // Lock port mapping registers P2DIR |= BIT7; // Set P2.7 as TX output P2SEL |= BIT6 + BIT7; // Select P2.6 & P2.7 to UART function UCA0CTL1 |= UCSWRST; // **Put state machine in reset** UCA0CTL1 |= UCSSEL_1; // CLK = ACLK UCA0BR0 = 0x03; // 32k/9600 - 3.41 UCA0BR1 = 0x00; // UCA0MCTL = 0x06; // Modulation UCA0CTL1 &= ~UCSWRST; // **Initialize USCI state machine** UCA0IE |= UCTXIE + UCRXIE; // Enable USCI_A0 TX/RX interrupt __bis_SR_register(LPM3_bits + GIE); // Enter LPM3 w/ interrupts enabled __no_operation(); // For debugger } #if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__) #pragma vector=USCI_A0_VECTOR __interrupt void USCI_A0_ISR(void) #elif defined(__GNUC__) void __attribute__ ((interrupt(USCI_A0_VECTOR))) USCI_A0_ISR (void) #else #error Compiler not supported! #endif { unsigned char tx_char; switch(__even_in_range(UCA0IV,4)) { case 0: break; // Vector 0 - no interrupt case 2: // Vector 2 - RXIFG P1OUT = UCA0RXBUF; // RXBUF1 to TXBUF1 break; case 4: // Vector 4 - TXIFG __delay_cycles(5000); // Add small gap between TX'ed bytes tx_char = P1IN; tx_char = tx_char >> 4; UCA0TXBUF = tx_char; // Transmit character break; default: break; } } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
arhiv6 14 5 января, 2016 Опубликовано 5 января, 2016 · Жалоба mcheb, спасибо. Попробовал затактироваться от ACLK - работает. Погонял тесты - данные не теряются. Тогда ещё один вопрос появился - а почему работает? Частота 32768/3=10922.66, от 9600 отклонение в 12.1%. uart calculator вообще выдаёт максимальное отклонение в 17.19%. Я всегда при расчёте частот UART ориентировался на отклонение не более 5%. А какая максимальная расстройка частоты допустима для UART? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mcheb 0 5 января, 2016 Опубликовано 5 января, 2016 · Жалоба Там есть модуляция частоты уарта // Baud rate divider with 32768hz XTAL @9600 = 32768Hz/9600 = 3.41 (0003h 4Ah) роде бы это. Я поставил 4МГц и 115200 и сильно не разбирался ;) ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться