LPC1769 und Rowleys. Ist die main zu groß überscreibt er wahllos den Speicher

[Johannes V. (johannes_v)]

Guten Tag,

Betreff sagt eigentlich schon fast alles.

Alles funtkioniert super, nur wenn ich in der main code einfüge hinter 
das printf, dann wird mir die SPeicherposition 0x100000f8 
kaputgeschrieben.
Dabei spielt es keine rolle welcher Wert dort steht.

Aufmerksam auf den Kern des Problems wurde ich erst als mir auffiel, 
dass die private member variable des Nunchuk nur einmal auf den I2C 
zugreifen kann bevor ihre Address Daten zerstört werde. Bzw, ist nicht 
ganz richtig. sie konnte nur einmal lesend zugreifen.

während System::init wird ein anderer I2C Sensor am selben Port mit der 
gleichen I2C klasse ausgelesen, alles funktioniert.

Bin das ganze jetzt schon zig mal durchgegangen, im Endeffekt kommt der 
Fehlzugriff während dem Intterrupt ansprung, also nicht davor oder 
danach, sondern während und auch nur wenn meine main "zu lang" ist.

ziemlich weit unten sieht man wie der IRQ verschatelt ist.

Ich weiss nicht mehr was ich machen soll ~_+ Hilfe

int main()
{
  System::init();

  Nunchuk::init();

  printf("done");

  short stick[3];
  float acc[3];
  int Power[3];

  while(1)
  {
    Nunchuk::read(acc, stick);
    printf("%f %f %f\n", acc[0], acc[1], acc[2]);

    Power[0] = acc[0] * 300 + 1500;
    PWM::set(Power[0], 1);
    Power[1] = acc[1] * 300 + 1500;
    PWM::set(Power[1], 2);
    Power[2] = acc[2] * 300 + 1500;
    PWM::set(Power[2], 3);

  }
  return 0;
}

class Nunchuk {
  static I2Cslot I2C;
  static unsigned char Stick_Zero[2];
  static short Acc_Zero[3];           <--- Die wird Im Moment zerstört

  static char raw(short *Acc, short *Stick);

  static inline short constrain(short &value, short &constr) {
    constr += NUNCHsmooth;
    if(value > constr)  return constr;
    constr -= (NUNCHsmooth << 1);
    if(value < constr)  return constr;
    return value; }

public:

  static int init();

  static char read(float *Acc, short *Stick);
};

#pragma once

class I2Cslot{
  unsigned char port;                   // holds port of this slot
  unsigned char address;                // holds address of this slot

  static unsigned char count;           // counts up through the bytes transmitted and received
  static unsigned char curadd;          // holds address of currently active slot
  static volatile unsigned char error;  // holds error code of currently active Port
  static unsigned char *pI2Cmsg;        // points on currently active I2C message
public:
  /*  Constructor to create slots for devices  */
  I2Cslot(unsigned char address, unsigned char port);
  /*  initializes all active I2C ports  */
  static int init();
  /*  IRQ to handle the transfers  */
  static void irq(unsigned int *pI2Cper);
  /*  send n bytes on this slot, n has to be in the first spot of the byte array pMsg points at */
  /*  returns 0 if no error occured of the transaction  */
  int send(unsigned char *pMsg);
  /*  receive n bytes on this slot, n has to be in the first spot of the byte array pMsg points at  */
  /*  returns 0 if no error occured of the transaction  */
  int rec(unsigned char *pMsg);
};

extern "C" {
void I2C0_IRQHandler(void);
void I2C1_IRQHandler(void);
void I2C2_IRQHandler(void);
}

int I2Cslot::send(unsigned char *pMsg)
{
  curadd = address;    //assign slot address
  pI2Cmsg = pMsg;      //assign message pointer
  unsigned int *pI2Cper = 0;
  int ttl = (pMsg[0] << 8);
  switch (port)
  {
#ifdef I2C0active
  case 0:
    pI2Cper = (unsigned int*)&LPC_I2C0->I2CONSET;
    break;
#endif
#ifdef I2C1active
  case 1:
    pI2Cper = (unsigned int*)&LPC_I2C1->I2CONSET;
    break;
#endif
#ifdef I2C2active
  case 2:
    pI2Cper = (unsigned int*)&LPC_I2C2->I2CONSET;
    break;
#endif
  default:
    return(1);
  }

#ifdef DEBUG
  printf("I2C%d: %d Bytes to %X\n", port, pI2Cmsg[0], curadd);
#endif
  error = 1;        //reset error
  count = 1;        //reset counter

>>>>> Hier ist noch alles i.O.  <<<<<<<
>>>>> Sobald der Porzess mit der nächsten Zeile in Gang gesetzt wird ist aber schluss, siehe IRQ.    <<<<<<<<<

  *pI2Cper = 0x20;    //generate start
  for(; ttl > 0; ttl--)  //check error status. stays 1 as long as the transmission isn't complete or the bus is in a good status
    if(!error)      //if the bus times out leave the loop
      break;
  if(error)
  {
    *pI2Cper = 0x10;  //generate a stop condition to recover bad bus and release it
#ifdef DEBUG
    printf("I2CError: %d\n", error);
#endif
  }
  return(error);      //error turns 0 if everything went well
}


int I2Cslot::rec(unsigned char *pMsg)
{
  address++;
  int temp = send(pMsg);
  address--;
  return (temp);
}


void I2Cslot::irq(unsigned int *pI2Cper)
{
 >>>> Hier ist der Fehlzugriff schon geschehen <<<<

  switch(*(pI2Cper+1))        //switch depending on currently active status register
  {
  case 0x08:              //start has been transmitted
    *(pI2Cper+2) = curadd;      //master receive -> address + 1
    *(pI2Cper+6) = 0x20;      //clear start
    break;

(..snip..)

void I2C1_IRQHandler( void )
{
>>>>>>>  Alles noch In Ordnung  <<<<<<
  I2Cslot::irq((unsigned int*)&LPC_I2C1->I2CONSET);
}

Ich vermute der Hund liegt irgendwo im stack vergraben, und das die 
Registersicherung nicht ganz einheitlich abläuft. Aber wieso das Problem 
erst bei längerer main auftritt, da bin ich einfach überfragt.

ich habe mal mit __attribute__((interrupt)) vor der C++ routine 
probiert, aber da ging dann gar nichts mehr.

Bin für jeden Tip dankbar, wenn mehr code gebraucht wird oder ich 
irgendwas ausprobieren soll, nur zu.

MfG
Johannes

[willibald (Gast)]

Johannes V. schrieb:
> nur wenn meine main "zu lang" ist.

Das ist bestimmt nicht die Ursache, die liegt woanders.

_attribute_ ((interrupt)) gehört ggfs. an die Funktion 
I2C1_IRQHandler, aber auch da bin ich beim Cortex-M3 nicht ganz sicher.

Was anderes: Es kann sein, dass du für printf("%f") eine erweiterte 
Runtime-Lib dazulinken musst, hast du das gemacht? Ansonsten ersetz mal 
float acc[3] durch int acc[3] und printf("%f") durch printf("%d").

[(prx) A. K. (prx)]

willibald schrieb:

> _attribute_ ((interrupt)) gehört ggfs. an die Funktion
> I2C1_IRQHandler, aber auch da bin ich beim Cortex-M3 nicht ganz sicher.

CM3 Interrupt Handler benötigen keinen speziellen Stackframe, sondern 
werden wie normale C Funktionen aufgerufen. Irgendwelche Attribute sind 
also nicht erforderlich.

[Johannes V. (johannes_v)]

Hallo,

ich habe zwischenzeitlich den Interrupt jetzt einfach mit in die send()
eingebaut, da sie vorher ja auch nicht verlassen wurde während den 
wartezeiten.

Aber das ist ansich ja auf Dauer auch keine Lösung. Zum einen weil dann 
andere Intterrupts unter umständen meine SCL zu weit strecken (bleibt 
low sobald I2C irq flag steht) und zum anderen weil ich mir sicher bin, 
dass ich Interrupts noch brauchen werde sobald ich die RF12Bs zum laufen 
kriege.

_attribute_((irq)) habe ich auch probiert, aber das hat dann auch den 
aufruf komplett zu nichte gemacht und der controller geht in eine 
dauerschleife.

Also nochmal kurz und knapp, der Fehler kommt Zustande während dem 
Übergang vom C IRQ Handler der nichts anderes macht als den C++ IRQ 
Handler zu callen.

Dabei können auch andere I2C transfers vorher stattfinden ohne das der 
Speicher, oder zumindes was ich davon sehe, überrschrieben wird.

Zu Printf: in der tat muss man floatingpoint erst freischalten. habe ich 
auch gemacht und mittlerweile gibt er mir die messwerte auch 
entsprechend aus.

Das es nicht an einer zu großem main liegt ist mir auch klar, nur im 
ersten Atemzug ist das der zu beobachtende grund. Es muss irgendwas mit 
dem Übergang zwischen C und C++ zu tun haben. Ich gehe mittlerweile 
davon aus das ein weiterer Interrupt den ich in ähnlichem still betreibe 
auch irgendwo den Speicher überrschreibt, nur merkt man es nicht.

Wäre es denkbar die C++ IRQ Handler direkt in die Vectortabelle zu 
schreiben wenn innerhalb eh nur mit statischen variablen gearbeitet wird 
oder fehlt mir dann der this pointer?

Tut mir leid wenn das jetzt teilweise dumme fragen sind, aber ich habe 
auch erst vor 3 monaten angefangen mich intensiv mit programmieren zu 
beschäftigen.

[Peter D. (peda)]

Johannes V. schrieb:
> Aufmerksam auf den Kern des Problems wurde ich erst als mir auffiel,
> dass die private member variable des Nunchuk nur einmal auf den I2C
> zugreifen kann bevor ihre Address Daten zerstört werde.

Ich kenne mich mit C++ nicht aus, aber unter C ist das klassisch ein 
Pointer, der in den Wald zeigt oder ein zu großes Displacement auf den 
Pointer.
So bequem Pointer auch sind, manchmal sollte man lieber einen Index 
nehmen. Ein Index läßt sich nämlich immer auf Gültigkeit prüfen, ein 
Pointer aber nicht.
Innerhalb einer Funktion kann man den Pointer überblicken. Aber 
funktionsübergreifend nehme ich lieber einen Index und jede Funktion 
prüft ihn bei Übergabe auf Gültigkeit.

Auch würde ich nicht gleich alle 3 I2C-Ports zusammen mengen, sondern 
erstmal nur ein I2C zum Laufen bringen.
Danach sollte man das doch einfach mit Vererbung auf 3 erweitern können.
Ständige Auswahlentscheidungen mit switch/case sind dann unnötig.


Johannes V. schrieb:
> Tut mir leid wenn das jetzt teilweise dumme fragen sind, aber ich habe
> auch erst vor 3 monaten angefangen mich intensiv mit programmieren zu
> beschäftigen.

Und dann gleich mit so einem Boliden anfangen, Hut ab.
Ich würde mir das nicht zutrauen.


Peter

[Peter (Gast)]

Stack zu klein?

[Johannes V. (johannes_v)]

Dürfte eigentlich nicht das Problem sein, 16kb hat er, und laut Rowleys 
verbrauche ich ca 500 byte.

Es läuft ja auch noch kein richtiges Programm, bin noch mit Treiber 
Entwicklung beschäftigt.

Einen exessiven Aufruf der mir den stack während der Laufzeit abschmatzt 
schließe ich auch aus, habe bis jetzt nicht einen rekursiven Aufruf und 
die tiefste Ebene müsste bei 3 liegen.

[Johannes V. (johannes_v)]

Guten Tag,

das Problem saß natürlich vor dem Bildschirm.

Rowleys Crossworks bieted eine Schöne Ansicht des verwendeten Speichers 
mit farbigen Balken. Ich dachte es wäre eine Art "Real-Time" Anzeige.
Aber weit gefehlt, es zeigt nur an wie viel Stack und Heap der Linker 
zuteilt.

Und da waren dann wohl 128 byte doch zu knapp ~_^

Ich habe es noch nicht getested, nur gerade erfahren wie man das 
einstellen kann das er mehr Speicher reserviert.

Aber dazu eine andere Frage. Ich würde gerne eine ISR im Ram ablegen. 
Dazu eine neue Sektion im Linker eintragen und mit 
__attribute__((section"whatever")) die Funktion bereitstellen. Wird nach 
POR der code automatisch in den RAM copiert? Oder muss ich dann noch das 
startupscript manipulieren? Gibt es schon eine section die ich einfach 
mit nutzen könnte (fast_run z.b.)

MfG
Johannes