www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Cortex M3 "hängt" bei Initialsierung - (wilde Zeilensprünge)


Important announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Martin (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Hallo zusammen,

ich bin dabei ein CM3 Projekt in Betrieb zu nehme.
Die Firmware läuft auch auf einem anderem Projekt zu 98% Gleichheit.

Anders ist lediglich die ADC Config und es gibt keinen ext. Interrupt 
mehr.

So, nun habe ich das Teil (in Eclipse mit ST-Link im Debug mode) 
angeschlossen und festgestellt dass sich er sich in der Initialiserung 
irgendwo wohl verläuft.

Also bin ich Schritt für Schritt durchgegangen und habe folgendes 
festgestellt:

- wenn in einer Anweisung z.b. 4 einfach Variablenzuweisungen o.ä. 
hintereinander kommen werden diese in wilder Reihenfolge abgearbeitet. 
Cursor springt gleich zur 3. dann mal zur 1. dann wieder zur 3., dann 
zur 2. usw. Woher kann das kommen - habe sowas noch nie gesehen?

- in der NVIC_INIT hängt er sich auf, bzw. er geht einfach nicht rein 
und es heißt der Controller ist im Run mode, als würde er sich nicht 
finden. Komischerweiße bin ich diese ini routine auch schon step by step 
durchgegangen und es hat funktioniert. Also wieder "zufällige" 
Abarbeitung. Jetzt habe ich sie auskommentiert und der Controller geht 
bis zur Hauptschleife durch und arbeitet diese ab.

- Am Anfang habe ich die LED_OK und LED_ERR gesetzt und rückgesetzt um 
zu sehen ob das ausgeführt wird. "Manchmal" werden die LEDs gesetzt, 
manchmal wiederrum nicht.


Wo kann so ein seltsames Verhalten vorkommen.
Wie gesagt die Software ist bis den Ext. Interrupt (der nun deaktiviert 
ist) exakt gleich zu einem problemlos laufendem System.

Danke für eure Vorschläge

Gruß Michl
int main(void)
{
  // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  // System startup

  MainGpioInit();                                           // GPIO configuration
  //A. Martin debug
  GPIO_SetBits(LED_OK_PORT, LED_OK_PIN);
  GPIO_ResetBits(LED_ERR_PORT, LED_ERR_PIN);

  RCC_Configuration();                                      // System clocks configuration
  RCC_ClockSecuritySystemCmd(ENABLE);                       // Enable clock security system(CSS)
  EH_Init();                                                // Error Code Handling initialization
  //A. Martin debug
  //NVIC_Configuration();                                     // NVIC configuration
  //MainGpioInit();                                           // GPIO configuration

  if (SysTick_Config(SystemCoreClock / SYSTICK_FREQ))       // Setup SysTick Timer for 1 msec interrupts
    while (1)
      ;

  // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  // Initialize internal peripherals

  I2c_Configuration();                                        // I2C configuration
  Timer_Configuration();                                      // Timer configuration
  //ExtInt_Configuration();                                   // External hardware interrupt configuration
                                // was only used for overtemp sensor which is not used in DLX
  Adc_Configuration();                                        // ADC_ configuration


  // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  // Initialize system control and get system informations

  ParameterInit();                                            // initialize internal parameters and structures
  GetStartupInformation();                                    // request static system information

  // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  // Prepare command reception and command buffer

  nCanRxCounter = 0;
  pCBWritePtr = pCBReadPtr = szCmdQueue;              // set circular buffer pointer to first element of buffer
  Can_Configuration();                                        // CAN configuration

  // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  // Prepare program execution

  FncDispEnable(true);                                        // enable periodically function dispatcher
  WatchdogConfig();                                           // configure independent watchdog

  // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  // Start program execution
  while (1)
  {
  //A. Martin debug
  GPIO_SetBits(LED_OK_PORT, LED_OK_PIN);

    GPIO_SetBits(TEST2_PORT, TEST2_PIN);        // switch On Testpin, to check if app runs


    // check permanently for errors
    if( EH_GetErrorCounter() != 0)
    {
      nStatusByte |= (1<<UC_ERR_FLAG);      // set error flag in global status byte
      SetStatusLED(UC_ERR);
    }
    else
    {
      nStatusByte &= ~(1<<UC_ERR_FLAG);      // clear error flag in global status byte
      SetStatusLED(UC_OK);
    }

  //A. Martin debug
  GPIO_SetBits(LED_OK_PORT, LED_OK_PIN);
/************************OVERTEMPERATURE-Handling***********************************************************/

    // check if over-temperature error is always active
    if (((nStatusByte & (1<<OVERTEMP_FLAG)) == !0) && (GPIO_ReadInputDataBit(OVT_PORT, OVT_PIN) == 0x00))   // read OV flag and input pin status (PORTE Pin11)/low active
    {
     EXTI_ClearITPendingBit(EXTI_LINE_OVT);             // Clear the supervisor board over-temperature EXTI line pending bit
     OVFailureCount++;                                   // increase failure counter
     if (OVFailureCount >= 500)                          // does counter reach end point?
     {
       Overtemp_Shutdown ();                          // call over temperature shutdown
       //nStatusByte &= ~(1<<OVERTEMP_FLAG);            // clear over temperature flag
       OVFailureCount = 0;                            // clear counter
     }
    }
    else if (GPIO_ReadInputDataBit(OVT_PORT, OVT_PIN) == 0x01)
   {
//      if ((nStatusByte & (1<<OVERTEMP_FLAG)) == !0)       // overtemp_flag was set
//      {
        nStatusByte &= ~(1<<OVERTEMP_FLAG);             // clear over temperature flag
         EXTI_ClearITPendingBit(EXTI_LINE_OVT);          // Clear the supervisor board over-temperature EXTI line pending bit
//      }
     //EH_ClearErrorCode(ERR_OVT);                         // clear error code
     OVFailureCount = 0;                                 // clear counter
   }

    // reset watchdog counter
    WatchdogReset();

    // call command interpreter
    CmdEval();

    // reset watchdog counter
    WatchdogReset();
  }
}



void NVIC_Configuration(void)
{
  NVIC_InitTypeDef NVIC_InitStructure;

  /* Configure the Priority Grouping with 1 bit */
  NVIC_PriorityGroupConfig(NVIC_PriorityGroup_1);

  /* Configure and enable CAN interrupt */
  NVIC_InitStructure.NVIC_IRQChannel = USB_LP_CAN1_RX0_IRQn;
  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1;
  NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
  NVIC_Init(&NVIC_InitStructure);

  // Enable ADC1_2 IRQChannel
  NVIC_InitStructure.NVIC_IRQChannel = ADC1_2_IRQn;
  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 3;
  NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
  NVIC_Init(&NVIC_InitStructure);

  /* Enable the EXTI15_10 Interrupt */
  /*
  NVIC_InitStructure.NVIC_IRQChannel = EXTI15_10_IRQn;
  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 5;
  NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
  NVIC_Init(&NVIC_InitStructure);
  */
}

Autor: Martin (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
PS:
- wenn ich mit F5 (Einzelschritte) debugge, geht er in alle Ini/Config 
gehe führt er alle sauber aus

- wenn ich mit F8 (bis zu nächsten Breakpoint - den ich immer in die 
Zeile der nächsten Config Hauptroutine setze) debugge "verläuft" er sich 
meißtens, sprich er zeigt weder an wo er sich, noch kann ich ihn 
kontrollieren, zeigt RUN_MODE an.

- in die ParameterInit Funktion komme ich nie rein, selbst mit F5 
verläuft er sich einfach wenn er reinspringen soll


Es scheint irgendwo etwas im Argen zu liegen wenn "alles" so sporadisch 
abgearbeitet wird....

Merci

Autor: Martin (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Sorry
void ParameterInit(void)
{
  uint8_t i;

  // get block identifier depending on codification on IO pin
  if (GPIO_ReadInputDataBit(BLKSEL_PORT, BLKSEL_PIN) == 0x01)
  {
    nBlockIdentifier = 'R';
    nCanReceiveID = CAN_PFBR_ID;                  // distinct CAN ID for addressing the peltier frame board of right thermo block
    nCanSendID = nCanReceiveID - CAN_ID_OFFSET;   // distinct CAN ID to mark the peltier frame board of right thermo block as sender towards the supervisor controller
  }
  else
  {
    nBlockIdentifier = 'L';
    nCanReceiveID = CAN_PFBL_ID;                  // distinct CAN ID for addressing the peltier frame board of left thermo block
    nCanSendID = nCanReceiveID - CAN_ID_OFFSET;   // distinct CAN ID to mark the peltier frame board of left thermo block as sender towards the supervisor controller
  }

  // get HW revision information from pattern of I/O pins
  nHwVersion = GPIO_ReadInputDataBit(REV3_PORT, REV3_PIN) << 3;     // get HW revision information from pattern of I/O pins
  nHwVersion += GPIO_ReadInputDataBit(REV2_PORT, REV2_PIN) << 2;
  nHwVersion += GPIO_ReadInputDataBit(REV1_PORT, REV1_PIN) << 1;
  nHwVersion += GPIO_ReadInputDataBit(REV0_PORT, REV0_PIN);

  // LUT to build HW major/minor version information from HW revision code
  switch (nHwVersion)
  {
    case 0:
      nHwMajor = 1; nHwMinor = 0; break;
    case 1:
      nHwMajor = 1; nHwMinor = 1; break;
    case 2:
      break;
    case 3:
      break;
    case 4:
      break;
    case 5:
      break;
    case 6:
      break;
    //....
    default:
      nHwMajor = 0;       // set 0.0 to indicate an unknown hardware revision
      nHwMinor = 0;

      // set error code if no known hardware revision has been detected
      EH_SetErrorCode(ERR_HWSUPPORT);
    break;
  }

Autor: Rangi Jones (rangi)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Das mit den "wilden Sprüngen" sieht nach optimierung aus. Das kenne ich 
und ist nicht ungwöhnlich. Der Debugger kann die Assemblerbefahler nicht 
richtig zum Quelltext zuordnen. Schau dirs mal im Mixed-Mode oder im 
Assembler an, dort wirst du feststellen, das die Adressen auch schon 
wild durcheinander stehen.
Versuchs mal die optimierung auszuschalten (-O0)

Autor: Roland H. (batchman)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Martin schrieb:
> ich bin dabei ein CM3 Projekt in Betrieb zu nehme.
> Die Firmware läuft auch auf einem anderem Projekt zu 98% Gleichheit.

"Den" CM3 gibt es nicht. Welcher ist es konkret? Compiler-Version und 
ggf. Version der "driver library" schadet auch nicht.

Und für welche MCU steht das "andere Projekt"?

Was war die Ausgangslage für die Portierung, auf welcher Plattform lief 
das ganze System fehlerfrei?

Autor: Martin (Gast)
Datum:
Angehängte Dateien:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
STM32F103VCT6

gcc compiler.

Das andere Projekt ist auf dem exakt gleichem controller gelaufen, nur 
wie gesagt mit der minimalen Änderung der Hardware.

Nun habe ich rausgefunden:

- es scheint ein problem mit dem ext. EEPROM zu geben, weil er sich an 
dieser Stelle an der Initialisierung aufhängt. Gut... muss man mal 
schauen woran das liegen kann.

- Wenn ich den EEPROM Teil herausnehme hängt er sich (wie im bild 
gezeigt) in der NVIC_Config und der darauffolgendenen NVIC_Init auf. Die 
Init wird aufgerufen, und scheinbar auch durchlaufen, den der debugger 
sagt dass er in Zeile 144 in misc.c hängt. Und genau das ist die letzte 
Klammer der Init funktion... also hää? warum gehts dann nicht weiter?

Danke!

Autor: Roland H. (batchman)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Martin schrieb:
> Wenn ich den EEPROM Teil herausnehme hängt er sich (wie im bild
> gezeigt) in der NVIC_Config und der darauffolgendenen NVIC_Init auf.

Auf dem Screenshot sieht es so aus, als ob er sich bereis im 
ADC-Interrupt-Handler befindet.

Wann wird ADC gestartet? Vor dem NVIC-Setup?

Wie sieht denn der Handler aus? Hängt er evtl. in einem Default-Handler 
in einer Endlosschleife?

Autor: Martin (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Also eigentlich dachte ich ist mir nicht aufgefallen, dass der ADC VOR 
der NVIC konfiguriert wird.
Nun wird er aber wie im code oben erst danach konfiguriert.

Warum also springt er dann in die ADC_IRQ rein und erledigt dort richtig 
seine Arbeit.

Das ist auch das was ich durchs debuggen jetzt nachvollziehen kann:
Er bleibt in der besagten NVIC_Config stehen (warum auch immer) und es 
wird immer und immer wieder die ADC_IRQ ausgelöst und in der main 
schleife geht es auch garnicht mehr weiter...

Die frage ist also warum wird an dieser Stelle bereits der ADC 
ausgeführt obwohl er laut code (siehe Reihenfolge oben) noch nicht 
initialisiert ist.

PS: oben ist die NVIC_config auskommentiert, war nur kurzfristig so, 
jetzt ist sie natürlich wieder drin.

Autor: Martin (Gast)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Nachschub:

- Die Reihenfolge wann NVIC_Config ausgeführt wird ist egal, er bleibt 
dann immer  an besagter Stelle stehen und es wird nur noch die ADC_IRQ 
ausgeführt

- kommentiere ich NVIC_Config aus (zum Test) wird die main "normal" 
abgearbeitet, allerdings natürlich ohne ADC werte weil die ADC_IRQ nicht 
mehr ausgeführt wird (wegen fehlender NVIC confi)

Autor: Jojo S. (jojos)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
ist denn die ADC init ok? Ich habe auch gerade mit einem LPC1769 und 
internem ADC gespielt. Dabei habe ich den ADC-Takt zu klein gemacht und 
der zu grosse Teiler hat dann das Burst-Bit erwischt und aktiviert.
Ein anderer Fehler war das im ADC_IRQ Handler der IRQ nicht gelöscht 
wurde, das ist meiner Ansicht nach schon in den CMSIS Beispielen falsch 
die ich als Muster genommen hatte, dort wurde das falsche Register 
gelesen. Das führte dazu das nur noch IRQs ausgelöst wurden.

Autor: Roland H. (batchman)
Datum:

Diesen Beitrag bewerten:
lesenswert
nicht lesenswert
Irgendwie passt das alles nicht zusammen: Hat das Programm auf dem 
gleichen Controller jemals funktioniert? Obwohl immer mehr abgeschaltet 
wird, kommt es nicht zum Laufen.

Ich zweifle daran, dass der ADC ohne Konfiguration einfach an der Stelle 
zufällig losläuft.

Also: Nochmals prüfen, testen, und letzten Programmstand und 
Beobachtungen posten. Das macht aber nur dann Sinn, wenn alle im ersten 
Posting genannten Funktionen enthalten sind.

Im Zweifel das Ding komplett entkernen, solange bis es funktioniert. 
Dann schrittweise die weitere HW dazunehmen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel




Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder GIF-Format hochladen.
Siehe Bildformate
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken erkennst du die Nutzungsbedingungen an.

webmaster@mikrocontroller.netImpressumNutzungsbedingungenWerbung auf Mikrocontroller.net