[cornflyer 0]

Плата разведена так: XIN - Vcc, XOUT - болтается в воздухе....

XT2IN/XT2OUT - кварцевый резонатор 3.6 МГц

через UART с периодом 1 сек приходят и отправляются пакеты...

примерно через час после включения и успешной работы процессор намертво виснет...

причем не помогает включенный watchdog и svs ...

даже MSPFET не видит его на JTAG шине в момент зависания....

помогает только передергивание питания...

 

С такой же прошивкой отладочная плата Olimex не виснет.....

Отличие платы Olimex от моей - отсутствие на моей плате на ножках XIN/XOUT часового кварца 32кГц...

Тогда я запаял на свою плату часовой кварц на ноги XIN/XOUT и плата перестала виснуть !!!!!!!!!!!

В чем глюк? Этот проц не работает без LFXT1 (XIN/XOUT) !?

P.S. прошивка везде - одинаковая! См. ниже

 

// ***** мой конфиг для базового тайминга:

 

void clock_Init ( void )

{

//asm ( " xor SR, 0x20 " ) ;

_BIS_SR ( 0x20 ) ;

 

BCSCTL1 = 0 ; // &= ~XT2OFF; // XT2 = HF XTAL

do

{

IFG1 &= ~OFIFG; // Clear OSCFault flag

for (i = 0xFF; i > 0; i--); // Time for flag to set

}

while ((IFG1 & OFIFG)); // OSCFault flag still set?

 

BCSCTL2 |= BIT7 | // MCLK = XT2CLK when XT2 oscillator present on-chip

BIT4 | BIT5 | // ACLK = MCLK/8

BIT3 ; // SMCLK = XT2

 

// Timer_A setup

TACTL = 0x00; // stop timer before config

TACCR0 = 0xFFFF ; // 0xFFFF ;

TACCTL0 = BIT4 ; // Timer_A compare interrupt enable

TAR = 0x0000 ;

TACTL = BIT4 | // Up mode: the timer counts up to TACCR0

BIT7 | BIT6 | // CLK/8

BIT9 ; // Timer_A clock source = SMCLK

 

 

// Timer_B setup

TBCTL = 0x00; // stop timer before config

TBCCR0 = 0xFFFF ;

TBCCTL0 = BIT4 ; // Timer_B compare interrupt enable

TBR = 0x0000 ;

TBCTL = BIT4 | // Up mode: the timer counts up to TBCCR0

BIT7 | BIT6 | // CLK/8

BIT9 ; // Timer_B clock source = SMCLK

}

 

// ***** мой конфиг для UART1:

 

void serial_Init ( void )

{

UCTL1 |= SWRST ; // Set SWRST

UCTL1 = CHAR ;

UTCTL1 = BIT5 ; // SMCLK

UBR01 = 0x80 ; // 3.6864 Mhz / 9600 - 384

UBR11 = 0x01 ;

UMCTL1 = 0x00 ; // no modulation

URCTL1 = URXEIE ; // Receive interrupt enable

ME2 |= UTXE1 + URXE1 ; // Enable USART1 TXD/RXD

P3SEL |= BIT6 | BIT7 ; // P3.6,7 = USART1 TXD/RXD

UCTL1 &= ~SWRST ; // clear SWRST

IE2 |= URXIE1 ; // Enable USART0 RX/TX interrupt

 

cmd_byte_cnt = 0 ;

RX_time_cnt = 0 ;

}

 

спасибо тебе за внимание!

[Kaplinsky 0]

Плата разведена так: XIN - Vcc, XOUT - болтается в воздухе....

Работаю от DCO. XIN, XOUT, XT2IN, XT2OUT висят в воздухе. Не виснет никогда.

Интересно, а перестанет ли виснуть если XIN отрезать от Vcc ?

[cornflyer 0]

Работаю от DCO. XIN, XOUT, XT2IN, XT2OUT висят в воздухе. Не виснет никогда.

Интересно, а перестанет ли виснуть если XIN отрезать от Vcc ?

В мануале на семейство MSP430x1xx Family User's Guide (Rev. F).pdf

написано, как надо делать:

 

2.5 Connection of Unused Pins

The correct termination of all unused pins is listed in Table 2−2.

Table 2−2.Connection of Unused Pins

Pin Potential Comment

AVCC DVCC

AVSS DVSS

VREF+ Open

VeREF+ DVSS

VREF−/VeREF− DVSS

XIN DVCC

XOUT Open

XT2IN DVSS 13x, 14x, 15x and 16x devices

XT2OUT Open 13x, 14x, 15x and 16x devices

 

т.е. XIN вешать надо на питание, а XOUT - оставить в воздухе...

[rezident 0]

Если нет необходимости иметь кварцованный MCLK и частоты тактирования ядра порядка 5,5МГц хватает для работы программных алгоритмов, то источником MCLK нужно назначать DCO. Помехоустойчивость MSP430 при этом значительно увеличивается!

Подключение неиспользованного входа

XIN DVCC

появилось в MSP430x1xx Family User's Guide rev.D. До этого во всех ревизиях было

XIN DVss

специально просмотрел все User's Guide rev. A, B, C, D, E, F.

Кстати, в вашей программе нет обработки ошибки кварцевого генератора, которую нужно делать в прерывании NMI. Там по сути та же самая процедура, что у вас в clock_Init описана. Только перед выходом из прерывания нужно разрешать прерывание ошибки осциллятора установкой OFIE в регистре IE1, т.к. при входе в обработчик оно автоматически сбрасывается. Или можно вообще оставить процедуру инициализации только в преывании NMI, что я обычно и делаю.

Пример ниже

// Инициализация источников тактирования ACLK, MCLK, SMCLK
#pragma vector=NMI_VECTOR
#pragma type_attribute=__interrupt
void osc_fault(void)
{ BCSCTL2=SELM_0|DIVM_0|DIVS_0;                   //перейдем на такт. DCO
  BCSCTL1=DIVA_3|RSEL2|RSEL1|RSEL0;               //ACLK=XT1/1=32768Гц
  DCOCTL=DCO0|DCO1|DCO2;                          //DCO около 5МГц
  do
  { IFG1&=~OFIFG;
  } while ((IFG1&OFIFG)!=0);                      //Ожидаем стабилиз. колебаний
                                                  //кварца XT1
  BCSCTL2=SELM_2|DIVM_0|SELS|DIVS_0;              //MCLK=XT2/1=7327,8кГц,
                                                  //SMCLK=XT2/1=7327,8кГц
  IE1|=OFIE;                                      //разр. прерывания от детектора
}

а в main-е пишем попросту

#pragma type_attribute=__task
void main(void)
{ WDTCTL=WDTPW+WDTHOLD;
  IFG1|=OFIFG;                                    //Принудительно установим флаг ошибки осциллятора
  IE1=OFIE;                                       //Разрешим прерывание для вызова процедуры инициализации источников тактирования
...
}

[cornflyer 0]

Спасибо !!! Так и сделаю !

Если даже осциллятор взглюкнет (может какая-нить ВЧ помеха высаживаеца на ножку проца), то он должен вернуца в норму после обработчика NMI прерывания !!!

[DogPawlowa 0]

даже MSPFET не видит его на JTAG шине в момент зависания....

помогает только передергивание питания...

Ein frage. В момент зависания JTAG подключен?

[cornflyer 0]

Ein frage. В момент зависания JTAG подключен?

Зависает как с JTAG'ом так и без него.

Когда я использовал JTAG debugger - в момент зависания появлялась ошибка соединения - типа "нет связи с устройством." И пока не передернешь питание - устройство не видно на шине.

[DogPawlowa 0]

Зависает как с JTAG'ом так и без него.

Когда я использовал JTAG debugger - в момент зависания появлялась ошибка соединения - типа "нет связи с устройством." И пока не передернешь питание - устройство не видно на шине.

Ну тогда дело хуже - плата разведена совсем плохо, хотя не так все просто.

Во влияние входов генератора трудно поверить.

Проще поверить в то, что brown-out detector не используется, и микроконтроллер виснет из-за помех.

Хотя в 169 контроллере TI вроде улучшил работу bod, не стоит забывать, что наличие внешнего супервизора питания официально было названо тексасом как условие стабильной работы младших моделей в условиях помех.

[cornflyer 0]

brown-out detector используется, питание беру с отладочной платы Olimex (припаялся к ней двумя проводками по 5 см).

Вообще у меня на плате используюца все входы АЦП, компаратор, оба таймера, почти все ноги - порты ввода - вывода, uart1, даже температуру измеряю... Еще есть I2C.... но встроенный контроллер - клюкавый, написал свой.... так что проц пашет на все 90%

 

Мне не понятно, почему не срабатывает watch dog ?

Когда ту же прошивку загружаю в olimex - работает без сбоев 8 часов...

Когда подключаю свою платку с припаянным на XIN/XOUT часовым кварцем - работает без сбоев 8 часов...

Но когда я подключаю свою вторую платку, где XIN - Vcc, XOUT - в воздухе, то примерно через час проц зависает намертво...

Непонятно каким образом можно понять что происходит.... (??????????!!!!!!)

Пока решил остановица на рабочем эмпирическом варианте - часовом кварце на ногах XIN/XOUT.

Но тут у меня народ ходит и высказывает что-то типа "откуда ты знаешь что у тя все заработало? может период глюков просто увеличился... "

А плата реально разведена хреново... Однослойная топология... качество изготовления - полный ахтунг... (некоторые ноги плохо были запаялись)

Эх, не я разводил ее... я бы уж сделал 2 внутр. слоя - Vcc и GND, а на внешних слоях нарисовал бы дорожки... И отдал бы ее делать в Зеленоград.

Короче, правильно было выше сказано - если нужна частота не больше 5 MHz - юзать надо часовой кварц и DCO. А меня позвали в самом конце - типа "вот тебе плата - иди программируй!"

[DogPawlowa 0]

Короче, правильно было выше сказано - если нужна частота не больше 5 MHz - юзать надо часовой кварц и DCO. А меня позвали в самом конце - типа "вот тебе плата - иди программируй!"

С вершин :) своего скромного опыта скажу (по крайней мере базируясь на 133-149 кристаллах), что DCO спасает не всегда ( в случае помех программа сбивается все равно).

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

[aag 0]

Добавлю пять копеек. Пробовал запускать UART от DCO и от часового кварца - почему-то иногда в пакете данных возникала ошибка примерно на 1 бит из 20.

 

XIN может действительно на землю посадить?

[DogPawlowa 0]

Добавлю пять копеек. Пробовал запускать UART от DCO и от часового кварца - почему-то иногда в пакете данных возникала ошибка примерно на 1 бит из 20.

Неубедительно. DCO очень нестабилен, а от часового кварца больше 1200 не получить.

[Kurt 0]

Обработка ошибки OSC_ FAULT в любом случае не помешает.

Плюс внешную собаку, если уж такая плата кривая.

Год назад выкладывал пример с тактированием, может пригодится http://kurt.embedders.org/wiki/sources:xtal

Там же работа с уартом и т.д.

Редактируйте, дополняйте.

[cornflyer 0]

Внешний watchdog - реально повышает помехоустойчивость системы....

Внутренний как оказалось не спасает ( в первые столкнулся с такой ситуацией.... имею успешный опыт использования 149, 449, но с 169 что-то не так)

[DogPawlowa 0]

Внешний watchdog - реально повышает помехоустойчивость системы....

Внутренний как оказалось не спасает ( в первые столкнулся с такой ситуацией.... имею успешный опыт использования 149, 449, но с 169 что-то не так)

А что ставили?

Дело в том, что реально повышает помехоустойчивость не столько watchdog, сколько супервизор питания, которого в 149 и 449 не было.

Watchdog - это уже собирать крошки зависаний, когда сброс от супервизора все-таки не прошел.