Verstehe den Reset vom Atmega328P nicht

[Stefan S. (sschultewolter)]

Hallo,

ich habe gerade ein Problem, dass ich nicht versteh, wieso mein 
Atmega328P (Sparkfun Pro Mini) Probleme bei dem UART hat.

er springt nicht in die while Schleife sondern zuvor neu. F_CPU wurde in 
Projekteigenschaften auf 16000000UL gesetzt.

// main.c
#include <avr/io.h>
#include <avr/interrupt.h>

#include <util/delay.h>

#include <stdio.h>

#include "uart.h"

char buffer[64];

uint16_t getSeed(void)
{
  uint16_t seed = 0;
  uint16_t *p = (uint16_t*) (RAMEND+1);
  extern uint16_t __heap_start;
  
  while(p >= &__heap_start + 1)
  seed ^= *(--p);
  
  return seed;
}

int main(void)
{
  uart_init();
  srand(getSeed());
  
  sprintf(buffer, "Hallo Welt, Random %d\r\n", rand()%256);
  uart_puts(buffer);
  DDRB |= 1<<5;
  
  while (1)
  {
    _delay_ms(500);
    PORTB ^= 1<<5;
    sprintf(buffer, "Neues Random %d\r\n", rand()%256);
    uart_puts(buffer);
  }
}

//uart.c
extern void uart_init(void)
{
  UBRR0 = UBRR_VALUE;
  
  #if USE_2X
  UCSR0A |= (1 << U2X0);
  #else
  UCSR0A &= ~(1 << U2X0);
  #endif
  
  // UART Tx, Rx Interrupt, Rx einschalten
  UCSR0B |= (1 << TXEN0) | (1 << RXEN0);
  // Asynchron 8N1
  UCSR0C = (1 << UCSZ01) | (1 << UCSZ00);
}

extern void uart_putc(char c)
{
  while(!(UCSR0A & (1 << UDRE0))) ;
  UDR0 = c;
}

extern void uart_puts(char *s)
{
  while(*s)
  {
    uart_putc(*s);
    s++;
  }
}

//uart.h
#ifndef UART_H_
#define UART_H_

#define BAUD        250000

#include <avr/io.h>
#include <util/setbaud.h>

extern void uart_init(void);

extern void uart_putc(char c);
extern void uart_puts(char *s);

#endif /* UART_H_ */

Als Ausgabe auf dem Terminal (Putty) erfolgt nur

Hallo Welt, Random 241
Hallo Welt, Random 252
Hallo Welt, Random 241
Hallo Welt, Random 252
Hallo Welt, Random 241
Hallo Welt, Random 252
Hallo Welt, Random 241
Hallo Welt, Random 252
[...]

[Karl H. (kbuchegg)]

Watchdog per Fuse abgeschaltet?

[Stefan S. (sschultewolter)]

Entferne ich das delay, geht es genau 12x

  while (1)
  {
    static uint16_t ct = 0;
    //_delay_ms(500);
    PORTB ^= 1<<5;
    sprintf(buffer, "%4d : Neues Random %d\r\n", ct++, rand()%256);
    uart_puts(buffer);
  }

Ehe es zum Reset kommt.

[Stefan S. (sschultewolter)]

Hallo Karl-Heinz,

bewusst habe ich an den Fuses nichts geändert. Habe testweise WDTON 
gesetzt und wieder gelöscht. Keine Auswirkung.

BODLEVEL = 2V7
RSTDISBL = [ ]
DWEN = [ ]
SPIEN = [X]
WDTON = [ ]
EESAVE = [X]
BOOTSZ = 1024W_3C00
BOOTRST = [X]
CKDIV8 = [ ]
CKOUT = [ ]
SUT_CKSEL = EXTXOSC_8MHZ_XX_16KCK_14CK_65MS

EXTENDED = 0xFD (valid)
HIGH = 0xD2 (valid)
LOW = 0xFF (valid)

Programmiert wird der Controller über einen Atmel ICE mit ISP Interface.

Habe das ganze nur noch auf ein Blink-Testsketch heruntergebrochen. Hier 
kommt es zum gleichen Fehler. Irgendwas scheint mit dem Controller nicht 
zu stimmen. Doof, der ist bereits auf Platine gelötet, werde aber gleich 
mal einen weiteren besorgen udn testen.

[Marc V. (Firma: Vescomp) (logarithmus)]

Stefan S. schrieb:
> Habe das ganze nur noch auf ein Blink-Testsketch heruntergebrochen. Hier
> kommt es zum gleichen Fehler. Irgendwas scheint mit dem Controller nicht
> zu stimmen. Doof, der ist bereits auf Platine gelötet, werde aber gleich
> mal einen weiteren besorgen udn testen.

 Und ohne LED-Blinkerei ?

  DDRB |= 1<<5;
  
  PORTB ^= 1<<5;

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Stefan S. schrieb:
> BOOTSZ = 1024W_3C00
> BOOTRST = [X]

Wenn dein Mega keinen Bootloader ab Adresse 0x3C00 hat, sollte BOOTRST 
nicht gesetzt sein.
Da du über ISP programmierst, ist das auch für weitere Experimente kein 
Problem.

[Dieter F. (Gast)]

Sparkfun Pro Mini unterstützt den sog. Auto-Reset - kannte ich auch noch 
nicht.

The auto reset feature from arduino boards enables the PC to reset the 
board by toggling the DTR line of the serial connection.

https://cdn.sparkfun.com/assets/0/7/5/5/1/51eec304ce395f104c000000.png

[Joachim (Gast)]

Dieter F. schrieb:
> Sparkfun Pro Mini unterstützt den sog. Auto-Reset - kannte ich auch noch
> nicht.

Der TE programmiert den uC aber ganz normal per ISP, nicht über den 
Arduino Bootloader. Daher dürfte an der seriellen Schnittstelle des 
Bords nichts angeschlossen sein. Außerdem wäre weiterhin fraglich, warum 
der PC dann das Bord regelmäßig in den Reset ziehen sollte.

Das kann also nicht der Fehler sein.

Gruß Joachim

[Joachim (Gast)]

Argh.... Überlesen, dass er den UART nutzt. Vergesst meine Einwände.
Dann muss allerdings DTR wenigstens angeschlossen sein. Sollten nur 
RX/TX/GND angeschlossen sein, kann es auch nicht die Ursache sein.

@Stefan

Wie kommuniziert dein Bord per USART mit wem? Kann der Reset per DTR das 
Problem sein?

Gruß Joachim

[Karl H. (kbuchegg)]

Joachim schrieb:

> Wie kommuniziert dein Bord per USART mit wem? Kann der Reset per DTR das
> Problem sein?

Das lässt sich ja leicht feststellen.
Einfach alle Verbindungen zum PC kappen, inklusive Brenner falls 
vorhanden, und wenn dann das Board aufhört mit dem ständigen Reseten, 
dann wars wohl irgendeine dieser Verbindungen.

[Dieter F. (Gast)]

Joachim schrieb:
> Der TE programmiert den uC aber ganz normal per ISP, nicht über den
> Arduino Bootloader. Daher dürfte an der seriellen Schnittstelle des
> Bords nichts angeschlossen sein. Außerdem wäre weiterhin fraglich, warum
> der PC dann das Bord regelmäßig in den Reset ziehen sollte.

Es geht nicht um die Programmierung sondern um die serielle 
Kommunikation. Diese funktioniert nur selten ohne serielle Schnittstelle 
:-)

Wenn der TO das passende FTDI-Modul angeschlossen hat (wovon ich 
ausgehe), dann wird die Leitung scheinbar vom Terminal-Programm auf den 
angeschlossenen (Annahme) PC getoggelt - nämlich bei DTR nach dem 
Empfang der ersten Datenladung -> und Reset

[Kirsch (Gast)]

In Putty mal die Flusssteuerung auf None setzen.

Standard ist aber XON/XOFF, da muss der TE sie schon manuell auf DSR/DTR 
gesetzt haben.

[Stefan F. (Gast)]

> Es geht nicht um die Programmierung sondern um die
> serielle Kommunikation.

Das sehe ich anders. An den Ausgaben sehen wir, dass der Controller 
scheinbar unerwartet Resetted. Und das könnte durchaus eine andere 
Ursache haben, als die direkten (gewollten) Zugriffe aus den seriellen 
port.

Ich würde mal den Aufruf von getSeed() durch eine konstante Zahl 
ersetzen, um zu sehen, ob dort etwas faul ist.

Als nächstes würde ich prüfen, was passiert, wenn du die Ausgaben via 
uart_puts(buffer); verdoppelst und das Delau auskommentierst. Kommt der 
Reset dann nach 6 Wiederholungen (=12 Ausgaben) oder nach immer noch 
nach 12 Widerholungen (=24 Ausgaben) vor?

[Stefan F. (Gast)]

Wie schreibst du eigentlich "extern void"?

[Dieter F. (Gast)]

Stefan U. schrieb:
> Das sehe ich anders.

Ich meinte die Programmierung mit dem ISP ...

Aber: Respekt!

Hast Du das (wie ich gerade) auch ausprobiert

Stefan U. schrieb:
> Ich würde mal den Aufruf von getSeed() durch eine konstante Zahl
> ersetzen, um zu sehen, ob dort etwas faul ist.

oder Kraft Wissens erkannt?

Wenn man das weglässt "resettet" er nicht mehr ...

Ich habe die "extern" weggelassen und alles in ein File gesteckt - mein 
AVR-Studio hat sich hat mit dem Original kräftig rumgemeckert.

[Stefan F. (Gast)]

extern benutze ich nur für Variablen, die sich in einer andere 
Quelltextdatei befinden. Aber das mache ich nur sehr selten, 
normalerwesie kapsele ich den Zugriff durch getter und setter.

Beispiel (main.c):

extern int counter;

void main() 
{
  counter++;
}

(wasauchimmer.c):

int counter;

Ich schätze, du hast den Compiler oder den Linker nicht richtig 
verwendet. Denn ich sehe keinen Grund, warum du "extern" benötigst. Die 
Header Datei macht die Funktionen für den UART bekannt und du hast sie 
ja auch eingebunden.

Schau Dir mal meine Kopiervorlage an, vor allem das Makefile: 
http://stefanfrings.de/avr_hello_world/index.html
Das passt ganz gut zu deiner konkreten Anwendung.

Ich habe dir den Tip mit der seed Funktion gegeben, weil ich nicht 
nachvollziehen kann, was genau diese Funktion eigentlich machen soll. 
Darin befindet sich Pointer-Arithmetik der übelsten Art. Genau wegen 
solchen Konstrukten hassen manche Entwickler die Sprache C.

RAMEND+1 finde ich ganz besonders merkwürdig. Auf den ersten Blick 
greifst du damit aufs Nirvana zu.

Und __heap_start+1 finde ich auch seltsam. Warum sollte man an der 
Speicherverwaltung des Systems vorbei auf den Heap zugreifen? Ich würde 
sowas nur tun, wenn absolut kein anderer Weg daran vorbei führt.

Tu Dir selbst einen Gefallen und nutze Pointer ausschließlich dazu, um 
auf die eigenen Variablen zuzugreifen. Auf Pointer-Arithmetik sollte man 
weitgehend verzichten, denn damit brockt man sich leicht Fehler ein, die 
man selbst nicht versteht.

[Georg G. (df2au)]

Stefan U. schrieb:
> RAMEND+1 finde ich ganz besonders merkwürdig. Auf den ersten Blick
> greifst du damit aufs Nirvana zu.

Der zweite Blick zeigt dann, dass er mit Predecrement zufasst, also 
durchaus ins reale Leben. Und da er nur lesend zufasst, würde auch ein 
Griff ins Nirvana nicht tödlich enden.


> Und __heap_start+1 finde ich auch seltsam. Warum sollte man an der
> Speicherverwaltung des Systems vorbei auf den Heap zugreifen? Ich würde
> sowas nur tun, wenn absolut kein anderer Weg daran vorbei führt.

Er möchte eine Pseudo Zufallszahl haben und nutzt dazu den Inhalt des 
RAM. Ob das sinnvoll und zufällig genug ist, sei dahin gestellt, legitim 
ist es.


> Tu Dir selbst einen Gefallen und nutze Pointer ausschließlich dazu, um
> auf die eigenen Variablen zuzugreifen. Auf Pointer-Arithmetik sollte man
> weitgehend verzichten, denn damit brockt man sich leicht Fehler ein, die
> man selbst nicht versteht.

Der Absatz ist voll daneben. Es spricht absolut nichts gegen Pointer 
Arithmetik. Man muss nur wissen, was man tut. Das gilt aber auch in 
allen anderen Lebenslagen.

Die seed() Funktion sieh erst einmal sauber aus. Was da genau zum 
Absturz führt, muss noch erforscht werden. Mir fehlt momentan leider die 
Zeit dazu.

[Dieter F. (Gast)]

Da kommt es scheinbar her:

http://rn-wissen.de/wiki/index.php/Zufallszahlen_mit_avr-gcc

[Georg G. (df2au)]

Dieter F. schrieb:
> Da kommt es scheinbar her:

Das macht die Funktion nicht besser :-)
Nach einem Kaltstart ist das RAM 0x00 oder 0xff, abhängig von der 
Technologie und dem Chip Layout. Wirklich zufällige Inhalte habe ich 
noch bei keinem Typ gefunden.

[Karl H. (kbuchegg)]

Georg G. schrieb:
> Dieter F. schrieb:
>> Da kommt es scheinbar her:
>
> Das macht die Funktion nicht besser :-)
> Nach einem Kaltstart ist das RAM 0x00 oder 0xff, abhängig von der
> Technologie und dem Chip Layout. Wirklich zufällige Inhalte habe ich
> noch bei keinem Typ gefunden.

Alles richtig.
Da aber ein AVR keinen Memory Manager hat und auch keinen Busfault 
auslösen kann, kann er von jeder beliebigen Adresse lesen, wie er lustig 
ist. Abschmieren wird dadurch nichts.

[Stefan F. (Gast)]

Und warum läuft das Programm stabil, seit er diese Funktion nicht mehr 
verwendet? Es wäre ja schon interessant, diese Frage zu klären.

[Georg G. (df2au)]

Stefan U. schrieb:
> Es wäre ja schon interessant, diese Frage zu klären.

Bestimmt. "Man" muss nur die Zeit zur Fehlersuche haben. So kurz vor 
Jahresende ist das immer etwas kritisch.

[Dieter F. (Gast)]

Stefan U. schrieb:
> Und warum läuft das Programm stabil, seit er diese Funktion nicht mehr
> verwendet?

Woher weißt Du das? Er hüllt sich in Schweigen - das ist lediglich meine 
Erfahrung mit der angepassten Version (ohne extern ...).

Beim ersten compilieren meckert er (nur eine Warnung) die fehlende 
Deklaration von srand() an, weil <...stdlib.h> nicht eingebunden ist - 
die habe ich reingepackt und es funktioniert.

Die "seed"-Routine ist halt ziemlich funktionslos, weil

Georg G. schrieb:
> Nach einem Kaltstart ist das RAM 0x00 oder 0xff,

tatsächlich lauter 0x00-en drin stehen. Hier die absturzfreie Version 
(ich habe die "Original-seed"-Routine aus dem Link genommen):

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include <stdio.h>
#include <stdlib.h>

#define BAUD        250000

#include <util/setbaud.h>


void uart_init(void);
void uart_putc(char c);
void uart_puts(char *s);

char buffer[64];

unsigned short get_seed()
{
  unsigned short seed = 0;
  unsigned short *p = (unsigned short*) (RAMEND+1);
  extern unsigned short __heap_start;
  
  while (p >= &__heap_start + 1)
  seed ^= * (--p);
  
  return seed;
}

int main(void)
{
  uart_init();
  srand(get_seed());
  
  sprintf(buffer, "Hallo Welt, Random %d\r\n", rand()%256);
  uart_puts(buffer);
  DDRB |= 1<<5;
  
  while (1)
  {
    _delay_ms(100);
    PORTB ^= 1<<5;
    sprintf(buffer, "Neues Random %d\r\n", rand()%256);
    uart_puts(buffer);
  }
}

void uart_init(void)
{
  UBRR0 = UBRR_VALUE;
  
  #if USE_2X
  UCSR0A |= (1 << U2X0);
  #else
  UCSR0A &= ~(1 << U2X0);
  #endif
  
  // UART Tx, Rx Interrupt, Rx einschalten
  UCSR0B |= (1 << TXEN0) | (1 << RXEN0);
  // Asynchron 8N1
  UCSR0C = (1 << UCSZ01) | (1 << UCSZ00);
}

void uart_putc(char c)
{
  while(!(UCSR0A & (1 << UDRE0))) ;
  UDR0 = c;
}

void uart_puts(char *s)
{
  while(*s)
  {
    uart_putc(*s);
    s++;
  }
}

[Stefan F. (Gast)]

>> Und warum läuft das Programm stabil, seit er diese Funktion nicht mehr
>> verwendet?

> Woher weißt Du das? Er hüllt sich in Schweigen

Das hatte ich deiner Antwort entnommen:

>> Ich würde mal den Aufruf von getSeed() durch eine konstante Zahl
>> ersetzen, um zu sehen, ob dort etwas faul ist.

> Wenn man das weglässt "resettet" er nicht mehr ...

Jedenfalls war das nur so ein Bauchgefühl von mir. Die Funktion kam mir 
komisch vor, deswegen hatte ich sie auf dem Kieker.