Arduino 328P Resettet sich bei Programmstelle

[Chris J. (Gast)]

Hallo,

ich befasse mich mal wieder mit dem AVR nach langer Zrit, eine 
Umstellung wenn man vom STM32 kommt.

Da kein richtiges JTAG Debugging möglich ist ist es schwer 
Programabstürze einzukreisen, vor allem wenn sie hier mit dem 
Verschicken von sms erzeugt werden. Nach dem versenden der sms "aus dem 
RAM", resettet sich der 328P. Die Routine kann mit PROGMEN Inhalten 
befüllt werden aber eben auch mit RAM.

Im DebugMode, wo keine sms verschickt wird, sondern nur der Inhalt per 
debugln() dargestellt wird resettet er sich nicht.

Wenn ich mich recht erinnere kommt dieser Reset gerne vor, wenn das RAM 
knapp wird oder der Stack in den RAM rein läuft. Den WDT habe ich auf 
eine ISR umgelegt.

Wie könnte ich es festellen, ob
int SIM800_SendSMS(const char* text,int mode)
SIM800_CheckForSMS()

und dann noch sprintf vielleicht zu viel RAM brauchen? Die sind ja 
abhängig voneinander.  Die Ausgabe beim Kompilieren sagt mir

954 global
1500 für lokale Variablen frei.

Hat das schon mal jemand gehabt und es gelöst?

Gruss,
Christian

  else if (strstr(buf,"info"))
  {
    char tm[6];
    if (flags.AlarmEnable)  strcpy(tm,"ON");
    else           strcpy(tm,"OFF");
    sprintf(buf,"Mode: %d\rAlarm: %s\rCelsius: %d Grad\rBatterie: %02u%%",modus,tm,(int)Temperature,BattProzent);
    SIM800_SendSMS(buf,RAM);
  }

 /* Kopiert einen Text aus dem Flash ins Ram */
void ReadFromFlash(char* target, const char* source)
{
  for (word k = 0; k < strlen_P(source);k++) {
    *(target + k)    = pgm_read_byte_near(source + k);
    *(target + k + 1) = '\0';  /* NUL Terminieren */
  }
}

[Carl D. (jcw2)]

Sicher daß ihm nicht das GSM-Teil einfach nur den Strom unter dem 
Hintern wegzieht?

[Carl D. (jcw2)]

Hab mal das Attachment angeschaut. Wenn man so lange Funktionen hat und 
all lokalen Variablen auf dem albernsten Scope (innerhalb der Funktion) 
hat, dann braucht man max. Stack. Wenn die Debug-Puffer nicht mehr 
benötigt werden, dann sollte man die nicht länger existieren lassen. Der 
Trick sind die geschweiften Klammern. So wie geschrieben, braucht das 
SMS-Senden 256+128+256+Kleinzeug Bytes an Stack.

[Chris J. (Gast)]

Carl D. schrieb:
> Sicher daß ihm nicht das GSM-Teil einfach nur den Strom unter dem
> Hintern wegzieht?

Nee, das ist mit 4700uf+100nf direkt über dem GSM schon sauber, 200mW 
zieht er maximal nur runter.

Debug hat keine Puffer, die Puffer brauche ich nur für die Strings. 
sprintf dürfte sicherlich aber auch einiges brauchen. Es stürtzt ja nur 
da ab, alles andere läuft einwandfrei.

Wie ginge es denn noch? Die Funktionen entschachteln, zb mit Flags? 
Malloc?
Wichtig wäre mir zu klären, ob das überhaupt die Ursache ist aber wenn 
man nur ein printf als Ausgabe hat, dann kann man das schlecht 
einkreisen.

Christian

[Joachim B. (jar)]

Chris J. schrieb:
> ....die Puffer brauche ich nur für die Strings.
> sprintf dürfte sicherlich aber auch einiges brauchen. Es stürtzt ja nur
> da ab, alles andere läuft einwandfrei.

aus dem flash oder aus dem SRAM?

nutzt du progmem für die Strings und PSTR()?

[Chris J. (Gast)]

Joachim B. schrieb:
> Chris J. schrieb:
>> ....die Puffer brauche ich nur für die Strings.
>> sprintf dürfte sicherlich aber auch einiges brauchen. Es stürtzt ja nur
>> da ab, alles andere läuft einwandfrei.
>
> aus dem flash oder aus dem SRAM?
>
> nutzt du progmem für die Strings und PSTR()?

Yupp..... daher muss ich auch unterscheiden wo was her kommt

const char flash_sms_empty[]    PROGMEM = "Batterie leer! Powerdown!";
const char flash_admin[]        PROGMEM = "Admin OK";
const char flash_sysdown[]      PROGMEM = "Shutdown!";

Zum Auslesen ins RAM

 /* Kopiert einen Text aus dem Flash ins Ram */
void ReadFromFlash(char* target, const char* source)
{
  for (word k = 0; k < strlen_P(source);k++) {
    *(target + k)    = pgm_read_byte_near(source + k);
    *(target + k + 1) = '\0';  /* NUL Terminieren */
  }
}

[Jim M. (turboj)]

Chris J. schrieb:
> 1500 für lokale Variablen frei.

Nur die lokalen Variablen im o.g. Codeschnipsel brauchen schon 720 
Bytes.

Wenn anderer Code ähnlich aussieht, würde ich hier auf Stack Overflow 
tippen.

[Chris J. (Gast)]

Jim M. schrieb:
> Wenn anderer Code ähnlich aussieht, würde ich hier auf Stack Overflow
> tippen.

Kann man das irgendwie nachweisen? Ich meine je größer das Programm 
wird, desto enger ist man an den Grenzen und weiss nie ob man sie 
erreicht hat oder knapp verfehlt.

[Oliver S. (oliverso)]

Z.b. So:

https://www.avrfreaks.net/forum/soft-c-avrgcc-monitoring-stack-usage?page=all

Oliver

[Joachim B. (jar)]

Chris J. schrieb:
> Joachim B. schrieb:
>> nutzt du progmem für die Strings und PSTR()?
>
> Yupp..... daher muss ich auch unterscheiden wo was her kommt
> Zum Auslesen ins RAM
>
>

>  /* Kopiert einen Text aus dem Flash ins Ram */
>

warum machst du das wenn das RAM knapp wird?

[Thorsten R. (Gast)]

Joachim B. schrieb:
> warum machst du das wenn das RAM knapp wird?

Weil es nicht möglich ist Strings aus dem Flash direkt als Parameter zu 
übergeben bei Arduino. Die müssen erst einzeln ins Ram geholt werden.

Die Schose läuft aber jetzt, nachdem ich den Speicher dynamisch belegt 
habe und wieder freigebe.

Christian

[Christian J. (Gast)]

Blöde Autoergänzung...

also nochmal: Scheinbar ist es nicht möglich das zur Kompilierzeit raus 
zu kriegen, sondern nur abzuschätzen oder eben genau zu zählen. In 
diversen Foren wird davon abgeraten den heap zu benutzen, zudem ich 
nicht weiss wie gross dieser überhaupt ist. Kann man ja einstellen in 
der Linker Datei.

Somit bleibt es beim Ausprobieren und hoffen.....

Gruss,
Christian