ATmega16 hängt sich scheinbar auf

teco schrieb:
> Vielleich hat jemand eine Idee was da los sein könnte!
> Danke!

http://www.youtube.com/watch?v=-Hgw5sqO88I

Gruß,
Magnetus   ;o)

Hier ein Auszug ausm Programmcode
Wenn der Master die Daten über SPI geschickt hat löst er beim Slave 
einen ext Interrupt auf und der liest dann das übertragene Byte aus dem 
SPDR Register und verarbeitet es.

Was brauchst du noch an Details?
Die beiden Platinen hängen im Betrieb auf einer gemeinsamen Versorgung.

Ich verstehe einfach nicht wie es ein kann, dass sich der Chip nach 
30Min Pause wieder normal verhält und dann wieder abschmiert...

lg

1

#define OFFSET 1100

2

3

typedef unsigned char ubyte;

4

5

void init();

6

void to_string(int val);

7

void uart_puts (char *s);

8

int uart_putc(unsigned char c);

9

10

int pwm_time_us=1500;

11

char hi_flag=0;

12

char string[10];

13

ubyte byte;

14

15

// External Interrupt 0 service routine

16

interrupt [EXT_INT0] void ext_int0_isr(void)

17

{       

18

    bit dummy, hi, lo;

19

    int val;    

20

21

    byte = SPDR;   

22

23

    dummy = (byte>>7)&0x01;

24

    lo = (SPDR>>6)&0x01;

25

    hi = (SPDR>>5)&0x01;

26

27

    if(!dummy)

28

    {        

29

        val = byte & 0x1F;

30

31

       //+++++++++++++++ HI-BYTE

32

        if(hi) 

33

        {     

34

            pwm_time_us = 0;

35

            pwm_time_us = val<<5;

36

            hi_flag = 1;

37

        }

38

39

       //+++++++++++++++ LO-BYTE

40

        if(lo) 

41

        {       

42

            pwm_time_us += val;

43

            pwm_time_us += OFFSET;

44

45

            if(hi_flag)

46

            {

47

                hi_flag = 0;

48

                OCR1A = pwm_time_us;

49

                to_string(pwm_time_us); 

50

                uart_puts("PWM_TIME: ");

51

                uart_puts(string);

52

            }   

53

        }

54

55

56

    }     

57

}

58

59

60

void main(void)

61

{    

62

    init();

63

    OCR1A = pwm_time_us;   

64

65

    uart_puts("Slave-Start\n");

66

67

    while(1);

68

}

hab jetzt mal wieder eine kleine Ewigkeit gewartet und ein Programm 
drauf gespielt, was nichts macht. Danach das Netzteil 3-4 mal aus und 
eingesteckt jetzt lässt er sich wieder nicht beschreiben.
bin echt ratlos

meinst du nicht, dass du mit dem "kleinen Drahtstück" den µC getötet 
(oder zumindest halbtot gemacht) hast? Ich will dir ja nicht die 
Hoffnung nehmen, aber mir gings mal ähnlich und wollte es auch nicht 
wahrhaben, dass die CPU übern Jordan ist.

ich mach immer wenn ich einen hartnääckigen µC hab einen Testaufbau auf 
meinen Breadboard. Dauert nur 5 min aber dann kannst du Einflüsse der 
umliegenden Hardware ausschließen. 5V Spannungsreglerr, externen Takt 
und eine Led. Anschließend schreibst 2 Zeilen Code damit die Led blinkt 
und dann lässt du sie mal ein paar Stunden blinken...

Die erste Halbzeit vom Champions League Finale blinkts schon ;)
Verstehs einfach nicht....nach ein paar mal Stecker ziehn  gehts nicht 
mehr aber einmal runterspielen ohne Interrupts oder der gleichen 
funktioniert
kann ein Controller halb tot sein? ;)

Hi

>kann ein Controller halb tot sein? ;)

Eher der Programmierer. Dein Vorgehen hört sich recht planlos an:

>hab jetzt mal wieder eine kleine Ewigkeit gewartet und ein Programm
>drauf gespielt, was nichts macht. Danach das Netzteil 3-4 mal aus und
>eingesteckt jetzt lässt er sich wieder nicht beschreiben.

Und was soll das eigentlich:

>Wenn der Master die Daten über SPI geschickt hat löst er beim Slave
>einen ext Interrupt auf und der liest dann das übertragene Byte aus dem
>SPDR Register und verarbeitet es.

Es gibt einen SPI-Interrupt. Wozu mag der wohl da sein?

MfG Spess

>Es gibt einen SPI-Interrupt. Wozu mag der wohl da sein?

Das hat folgenden Grund: In Summe hängen 4 Slaves nach dem Daisy Chain 
Prinzip am Bus.... Das Byte für den 4. Slave muss also bis dahin 
durchgeschoben werden. Um nun zu signalisieren, dass die richtigen Daten 
am richtigen Ort sind wird ein Interrupt erzeugt...


>Eher der Programmierer. Dein Vorgehen hört sich recht planlos an:

Mein Vorgehen ist auch planlos, weil ich einfach nicht verstehe, dass es 
kurzzeitig geht und dann nicht. Und Programmierer hab ich schon 
verschiedene getestet... (jedoch nur ISP, was anderes hab ich nicht)
Und für meinen anderen Controller gehts auch, bzw kackt dar µC auch ab 
ohne Programmiervorgang

Wär also froh über konstruktive Ratschläge, dass es Interrupts gibt weiß 
ich...

Das Problem scheint jetzt gelöst...
Das merkwürdige Verhalten wurde scheinbar durch einen schlechten Kontakt 
des Quarzes/def. Quarz hervorgerufen!