MSP430F169D зависает когда работает от XT2, UART работает ~ 1 час, потом процессор зависает.... Опции

[cornflyer]

Плата разведена так: 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]

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

Работаю от DCO. XIN, XOUT, XT2IN, XT2OUT висят в воздухе. Не виснет никогда.
Интересно, а перестанет ли виснуть если XIN отрезать от Vcc ?

[cornflyer]

Работаю от 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]

Если нет необходимости иметь кварцованный 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]

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

[Dog Pawlowa]

даже MSPFET не видит его на JTAG шине в момент зависания....
помогает только передергивание питания...

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

[cornflyer]

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

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

[Dog Pawlowa]

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

Ну тогда дело хуже - плата разведена совсем плохо, хотя не так все просто.
Во влияние входов генератора трудно поверить.
Проще поверить в то, что brown-out detector не используется, и микроконтроллер виснет из-за помех.
Хотя в 169 контроллере TI вроде улучшил работу bod, не стоит забывать, что наличие внешнего супервизора питания официально было названо тексасом как условие стабильной работы младших моделей в условиях помех.

[cornflyer]

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. А меня позвали в самом конце - типа "вот тебе плата - иди программируй!"

[Dog Pawlowa]

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

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

[aag]

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

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

[Dog Pawlowa]

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

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

[Kurt]

Обработка ошибки OSC_ FAULT в любом случае не помешает.
Плюс внешную собаку, если уж такая плата кривая.
Год назад выкладывал пример с тактированием, может пригодится http://kurt.embedders.org/wiki/sources:xtal
Там же работа с уартом и т.д.
Редактируйте, дополняйте.

[cornflyer]

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

[Dog Pawlowa]

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

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

[NoName]

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

{ U1CTL = 0x10; U1TCTL= 0x50; U1BR1 = 0x00; U1BR0 = 0x03; U1MCTL = 0x4A; } // 9600
больше 9600 на 32 кГц действительно не получить.

[cornflyer]

У меня как раз 9600 - скорость UART'а )))
Кроме SVS, WatchDOG у меня еще есть синхронизация UART.
Т.е. если какой-либо пакет не пришел вовремя, счетчик приемника сбрасывается по таймауту в ноль.
Для этого у меня работает TIMERA.
Более того, у меня многобайтовые посылки:
адрес утройства, код команды, параметры команды, CRC16
Так что кроме всего прочего у меня есть CRC проверка...
Проверял по всякому - дело было в железе. Повесил на XIN/XOUT часовой кварц - больше проц намертво не виснет. Вообще не виснет. Даже байты не теряюца.
Хотя прошивку оставил без изменений - т.е. ту, когда был только XT2.
Просто припаял на ноги часовой кварц, который у меня не используеца.
И все теперь работает без глюков.

[Dog Pawlowa]

Хотя прошивку оставил без изменений - т.е. ту, когда был только XT2.
Просто припаял на ноги часовой кварц, который у меня не используеца.
И все теперь работает без глюков.

Очень интересная информация. Поверить трудно.
Может, все-таки XT1 используется как-то в прошивке ?
У меня несколько приборов с разными комбинациями генераторов, но действительно наиболее устойчиво работают приборы с синхронизацией от часового кварца. Хотя эти кварцы чаще отказывают.
Но другие приборы работают тоже месяцами не выключаясь.

А по 9600 - похоже, перебдел

[cornflyer]

Может, все-таки XT1 используется как-то в прошивке ?

void app_Init ( void )
{
WDTCTL = WDTPW + WDTHOLD ; // stop watchdog
IFG1 |= OFIFG ;
IE1 |= OFIE ;
watch_dog_Reset () ;
_DINT () ; // disanable interrupts
/////////////////////////
svs_Init () ;
port_Init () ;
select_HV_U () ; // select data source connected to ADS1100
clock_Init () ;
serial_Init () ;
adc_Init () ;
HV_Init () ;
var_Init () ;
comparator_Init () ;
flash_init () ;
_EINT () ; // enable interrupts
adc_Start () ;
}


void clock_Init ( void )
{
//asm ( " xor SR, 0x20 " ) ;
_BIS_SR ( 0x20 ) ; // disable XT1

// 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
}


#pragma vector = NMI_VECTOR
__interrupt void osc_fault (void)
{

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

do
{ IFG1&=~OFIFG;
} while ((IFG1&OFIFG)!=0); //Îæèäàåì ñòàáèëèç. êîëåáàíèé

BCSCTL2 |= BIT7 | // MCLK = XT2CLK when XT2 oscillator present on-chip
BIT4 | BIT5 | // ACLK = MCLK/8
BIT3 ; // SMCLK = XT2

IE1|=OFIE;
}

[rezident]

В моем примере выше не зря первой командой в обработчике ошибки кварцевого осциллятора стоит

Код

BCSCTL2=SELM_0|DIVM_0|DIVS_0;                   //перейдем на такт. DCO

Это не чистая блажь и не перестраховка. Я уже неоднократно здесь обращал внимание, что при сбое кварца MCLK переходит на тактирование от DCO автоматически. А вот SMCLK - нет. Нужно сначала переключить его тактирование на DCO, а затем можно переключать снова на тактирование от кварцевого генератора. Не помню описано ли это в errata, но этот глюк известен еще с давних времен. По-моему впервые я про него прочитал в сообщениях Сергея Борща. А потом уже и сам с этим встречался.

[Сергей Борщ]

Не помню описано ли это в errata, но этот глюк известен еще с давних времен. По-моему впервые я про него прочитал в сообщениях Сергея Борща. А потом уже и сам с этим встречался.

Угу, было дело. Как я понимаю, механизм там такой - при сбое кварца происходит переключение MCLK на DCO, но на битах SELM это не отражается. И когда потом в эти биты записывается то же значение, переключения обратно не происходит - я думаю, что там переключение происходит по изменению битов, а поскольку изменения нет, то нет и переключения.

[aag]

переходит на тактирование от DCO автоматически. А вот SMCLK - нет. Нужно сначала переключить его тактирование на DCO, а затем можно переключать снова на тактирование от кварцевого генератора

Хм. интересное замечатие. Не знал.

2 cornflyer: У вас теперь получается два кварца используется или с XT2IN/XT2OUT резонатор убрали?

[cornflyer]

2 cornflyer: У вас теперь получается два кварца используется или с XT2IN/XT2OUT резонатор убрали?

используеца только XT2IN/XT2OUT, а на XIN/XOUT просто повешен часовой кварцевый резонатор 32768 Гц.

[shasik]

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

А когда у F449 убрать "Supply Voltage Supervisor/Monitor With Programmable Level Detection" успели?
Люди его используют, а его нет оказывается. Странно как то...

[rezident]

А когда у F449 убрать "Supply Voltage Supervisor/Monitor With Programmable Level Detection" успели?
Люди его используют, а его нет оказывается. Странно как то...

У MSP430F149 SVS не было и нет, у MSP430F449 был и есть. Dog Pawlowa, перепутал чего-то.

[cornflyer]

несмотря на все усилия - svs, watchdog, UART sync, часовой кварц на XIN/XOUT, обработчик NMI (восстанавливает настройки basic timer, timerA, timerB) - все равно проц завис !!!!!!!!
так что скорее всего это что-то программное....
буду смотреть стэк - может он переполняеца....
у меня один раз был такой глюк - если слишком много прерываний возникает - проц зависает

[rezident]

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

Такое не может быть, если только вы не используете вложенные прерывания. ИМХО скорее всего у вас имеется какое-то разрешенное прерывание у которого не описан обработчик. Вы бы определили все имеющиеся в кристалле вектора прерываний и NOPами или запретом соответствующего прерывания их забили. Так проще баг выловить.

[cornflyer]

похоже глюк может быть в опциях оптимизации компилятора.
я использую IAR C/C++ Compiler for MSP430 V3.41
в опциях компилятора я поставил галочку Optimizations / Area -> High (Maximum optimization)
видимо так лучше не делать
поставил Optimizations / Speed -> High (Maximum optimization)
уже 30 минут работает без глюков

если опять взглюкнет - откомпиляю свой проект в mspgcc

[rezident]

похоже глюк может быть в опциях оптимизации компилятора.

При высоких уровнях оптимизации я отключаю некоторые опции, по крайней мере опцию Code motion всегда.

[cornflyer]

написал тестовую программу и откомпилировал ее mspgcc
загрузил MSPFET'ом в проц и теперь смотрю сколько проработает....
Итак, программа состоит из 4-х файлов:
main.c
app.с
uart.c
clock.c

/////// main.c //////////////////////////////////////////////////////////////////////////////

#include "io.h"
#include "app.h"

int main(void)
{
app_Init(); // setup device
app_Loop(); // start events processing FSM
return 0 ;
}

/////// app.с ////////////////////////////////////////////////////////////////////////////////

#include "io.h"
#include "app.h"
#include "clock.h"
#include "uart.h"
#include "signal.h"

static unsigned char i = 0 ;

void app_Init (void)
{
WDTCTL = WDTPW + WDTHOLD; // stop watchdog

_BIS_SR(0x20); // OSCOFF - Oscillator Off. This bit, when set, turns off the LFXT1 crystal oscillator.

IFG1 |= OFIFG ; // setup clock failure NMI interrupt flag
IE1 |= OFIE ; // enable NMI interrupt
for (i = 0xFF; i > 0; i--) __no_operation(); // Time to debounce

dint();

uart_Init(); // first init UART
TIMERA_Init();

eint(); // enable interrupts
}

void app_Loop (void)
{
for (;;)
{
__no_operation();
}
}

/////// uart.c ////////////////////////////////////////////////////////////////////////////////

#include "io.h"
#include "uart.h"
#include "signal.h"

void uart_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 USART0 TXD/RXD
P3SEL |= BIT6 | BIT7 ; // P2.4,5 = USART0 TXD/RXD
UCTL1 &= ~SWRST ; // clear SWRST
//IE2 |= URXIE1 ; // Enable USART0 RX/TX interrupt
}

/*
interrupt (UART1RX_VECTOR) usart1RcvIsr(void)
{
while ( !( IFG2 & UTXIFG1 ) ) __no_operation () ; // Дождаться готовности передатчика к приему новых данных
TXBUF1 = RXBUF1 ;
}
*/

/////// clock.c ////////////////////////////////////////////////////////////////////////////////

#include "io.h"
#include "clock.h"
#include "signal.h"

static unsigned char i = 0 ;

void TIMERA_Init (void)
{
TACTL = 0x00; // stop timer before config
TACCR0 = 0xFFFF ;
TACCTL0 = BIT4 ; // Timer_A capture/compare interrupt enable
TAR = 0x0000 ;
TACTL = BIT4 | // Up mode: the timer counts up to TACCR0
BIT7 | BIT6 | // CLK/8
// BIT1 | // This bit enables the TAIFG interrupt request
BIT9 ; // Timer_A clock source = SMCLK

// HV LED
P5DIR |= BIT5 ; // output
P5SEL &= ~BIT5 ; // port
}

void toggle_HV_LED ( void )
{
P5OUT ^= BIT5 ;
}

interrupt (TIMERA0_VECTOR) timerA0Isr (void) // T = 1.5 sec
{
if ( ++ i > 10 )
{
i = 0 ;
TXBUF1 = 0x78 ; // x
toggle_HV_LED () ;
}
}

interrupt (NMI_VECTOR) osc_fault (void)
{
BCSCTL2=SELM_0|DIVM_0|DIVS_0;
BCSCTL1 = 0 ; // &= ~XT2OFF; // XT2 = HF XTAL
do
{
IFG1 &= ~OFIFG ;
for (i = 0xFF; i > 0; i--) __no_operation(); // Time for flag to set
}
while ((IFG1 & OFIFG)!=0);

BCSCTL2 |= BIT7 | // MCLK = XT2CLK when XT2 oscillator present on-chip
BIT4 | BIT5 | // ACLK = MCLK/8
BIT3 ; // SMCLK = XT2
IE1|=OFIE;
}


/////// makefile ////////////////////////////////////////////////////////////////////////////////

# makfile configuration
NAME = bpv
OBJECTS = main.o uart.o clock.o app.o
CPU = msp430x169

ASFLAGS = -mmcu=${CPU} -D_GNU_ASSEMBLER_
CFLAGS = -mmcu=${CPU} -O2 -Wall -g

#switch the compiler (for the internal make rules)
CC = msp430-gcc
AS = msp430-gcc
LD = msp430-ld

.PHONY: all FORCE clean download download-jtag download-bsl dist

#all should be the first target. it's built when make is run without args
all: ${NAME}.elf ${NAME}.a43 ${NAME}.lst

#confgigure the next line if you want to use the serial download
download: download-jtag
#download: download-bsl

#additional rules for files
${NAME}.elf: ${OBJECTS}
${CC} -mmcu=${CPU} -o $@ ${OBJECTS}

${NAME}.a43: ${NAME}.elf
msp430-objcopy -O ihex $^ $@

${NAME}.lst: ${NAME}.elf
msp430-objdump -dSt $^ >$@

download-jtag: all
msp430-jtag -e ${NAME}.elf

download-bsl: all
msp430-bsl -e ${NAME}.elf

clean:
rm -f ${NAME}.elf ${NAME}.a43 ${NAME}.lst ${OBJECTS}

#backup archive
dist:
tar czf dist.tgz *.c *.h *.txt makefile

#dummy target as dependecy if something has to be build everytime
FORCE:

#project dependencies

main.o: main.c app.h
uart.o: uart.c uart.h
clock.o: clock.c clock.h
app.o: app.c clock.h uart.h



Открыл hyperterminal и наблюдаю как мой проц шлёт с периодом T~1.5 сек букву "x" (ASCII 0x78)

[cornflyer]

проц часок поработал и завис...
щас ту же самую прошивку загрузил в отладочную платку olimex и тестирую.... работает
похоже дело в качестве разводки моей платы
но мне не понятно как можно так плату развести чтобы проц вис!

[VAI]

http://www.caxapa.ru/faq/emc_immunity.html
Там посмотрите про разводку кварца

[cornflyer]

спасибо! хорошая статья!
Действительно моя плата разведена плохо.
Скорее всего наносекундные помехи на входе тактирования вводят проц в "третье" состояние.
Думаю это "лечица" переразводкой - 4-е слоя, разделение "чистой" и "грязной" земель вырезами в питающих полигонах... Возможно для разделения земель где-то придеца ставить опторазвязку, например AQY210...

[cornflyer]

итак, наконец-то нашел причину зависания....
написал простую программу, которая моргает светодиодом:

#include "io.h"
#include "signal.h"

unsigned int i = 0 ;
unsigned int j = 0 ;

int main(void)
{
WDTCTL = WDTPW + WDTHOLD; // Stop WDT

BCSCTL1=DIVA_3|RSEL2|RSEL1|RSEL0;
DCOCTL=DCO0|DCO1|DCO2; //DCO около 5МГц
BCSCTL2=SELM_0|DIVM_0|DIVS_0; //перейдем на такт. DCO

do
{
IFG1 &= ~OFIFG; // Clear OSCFault flag
for (i = 0xFF; i > 0; i--); // Time for flag to set
}
while ((IFG1 & OFIFG) != 0); // OSCFault flag still set?

BCSCTL2=SELM_0|DIVM_0|DIVS_0; //перейдем на такт. DCO

// TI рекомендуют неиспользуемые порты делать выходами
P1DIR = 0xFF ;
P2DIR = 0xFF ;
P3DIR = 0xFF ;
P4DIR = 0xFF ;
P5DIR = 0xFF ;
P6DIR = 0xFF ;

// test pin
P5DIR |= BIT5 ; // output
P5SEL &= ~BIT5 ; // port

for (;;)
{
for (i=0;i<0xFFFF;i++)
for (j=0;j<0x60;j++);

P5OUT ^= BIT5 ;
}
return 0 ;
}

все равно в течение часа проц завис...
стал сравнивать мою плату и плату olimex.....
и тут нашел!!!!!
когда проверял разводку ноги RST
обнаружил, что вместо шунта 47k на питание в производстве запаяли кондюк !!!!!
поэтому при включении кондюк заряжался и потом в течение часа разряжался
и потом ставил проц в вечный reset....

[AHTOXA]

и тут нашел!!!!!
когда проверял разводку ноги RST
обнаружил, что вместо шунта 47k на питание в производстве запаяли кондюк !!!!!
поэтому при включении кондюк заряжался и потом в течение часа разряжался
и потом ставил проц в вечный reset....

Да уж, такого нарочно не придумаешь:-)

[aag]

Бляха муха, да резистор от конденсатора даже по цвету различается

Ну зачем ругаетесь? Мало ли на плате кондеров и резисторов. Проверить какой из них к чему подключен никому бы в голову не пришло даже. Тем более проверять резисторы, не имеющие к кварцу отношения...

Вобщем баг подлый получился.

[cornflyer]

да, это были очень жёсткие грабли....
самое интересное что проц работает какое-то время
поэтому если глюки - первым делом смотреть на качество шунтирования ноги RST к Vcc!

[Dog Pawlowa]

да, это были очень жёсткие грабли....
самое интересное что проц работает какое-то время
поэтому если глюки - первым делом смотреть на качество шунтирования ноги RST к Vcc!

Странно. Ненормальность цепи сброса обычно заметна при отладке через JTAG.
Когда я "для большей лучшести" поставил 100нФ на землю, то программирование и отладка вообще невозможны были.