Forum: Mikrocontroller und Digitale Elektronik STM32: suche Ursache HardFault Exception


von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Hallo,

Ich finde es einfach nicht... der Code:
1
void teste(void)
2
{
3
  uint16_t i = 0;
4
  i++;
5
  i--;
6
}
7
8
int main(void)
9
{
10
  teste();
11
  SCB->VTOR = NVIC_VectTab_FLASH | (0x2000 & (uint32_t)0x1FFFFF80);
12
  teste();
13
  NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x2000);

STM32F103RC

Die Routine teste(); wird angesprungen, "SCB->VTOR" wird auch 
beschrieben, das zweite teste(); wird auch gemacht.
der Aufruf:
NVIC_SetVectorTable();
landet sofort in der HardFaultException.

Das Programm hat schon mal funktioniert und jetzt nach 3 Jahren wollte 
ich es anpassen und neu einspielen. Seither hat sich der Compiler und 
Eclipse und die Segger Firmware geändert.
Aber irgendwie glaube ich fest daran, dass der Fehler vor dem Computer 
sitzt. Aber ich komme nicht drauf, nach was ich noch suchen sollte.
Compiler schreibt keine Fehler/Warnungen, Übersetzt mit -O0.

Hat jemand einen Tipp für mich was ich noch prüfen könnte?

Grüße Markus

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Ich habe jetzt mal den guten alten Olimex ARM-USB-OCD wieder 
installiert, siehe da, ich kann das Programm einspielen und es läuft 
dann auch.

Weiß jemand wieso das nicht mit dem J-LINK EDU geht?

von Lutz (Gast)


Lesenswert?

Bei NVIC_SetVectorTable den zweiten Parameter mal mit 32 bit 
ausprobiert?
Vielleicht hat sich die Funktion aus der Lib ja auch geändert.

Warum das nun gerade mit dem J-LINK nicht gehen sollte? Vielleicht 
irgendwelcge gdb-Einstellungen?

von Lutz H. (luhe)


Lesenswert?

Markus Müller schrieb:
> void teste(void)
> {
>   uint16_t i = 0;
>   i++;
>   i--;
> }

Möglicherweise optimiert hier der neue Compiler und macht nix?
Und deshalb ist das Programm zu schnell?

von Manax (Gast)


Lesenswert?

Mit derm J-Link EDU hab ich seit einigen Versionen auch das Problem mit 
den Hard Faults. Wenn ich dann einfach das Programm nochmal drauflade 
funktionierts.
mfg Manax

von Lutz (Gast)


Lesenswert?

Der J-LINK transportiert das Programm doch nur in den Chip. Mit dem 
ARM-USB-OCD soll das selbe File ja laufen (so hab ich's zumindest 
verstanden).

von Lutz H. (luhe)


Angehängte Dateien:

Lesenswert?

So läuft die Funktion bei mir.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

> Möglicherweise optimiert hier der neue Compiler und macht nix?
Nein, ist mit -O0 kompiliert, da wird nichts wegoptimiert.

>Mit dem ARM-USB-OCD soll das selbe File ja laufen
Ja, das Programm läuft. (Ist meine Heizungssteuerung.)

>Mit derm J-Link EDU hab ich seit einigen Versionen auch das Problem mit
>den Hard Faults. Wenn ich dann einfach das Programm nochmal drauflade
>funktionierts.
Wie meinst Du das?

Ich habe ca. 110KB programm.
NVIC_SetVectorTable() liegt irgendwo bei Adresse 0x0001230C, hingegen 
die Test-Funktion wie auch die main() bei 0x00002134.
Der J-LINK erkennt auch automatisch einen STM32F103RC (256KB Flash).

Ich habe das ganze mal auf einem Test-Board aufgespielt, der gleiche 
Effekt.
Hingegen kleine Programme (Blink-LED) funktionieren Problemlos.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Eine Änderung habe ich in der "core_cm3.c" gemacht, die lies sich mit 
dem neuen GCC nicht mehr übersetzen:
1
uint32_t __STREXB(uint8_t value, uint8_t *addr)
2
{
3
   uint32_t result=0;
4
  
5
   __ASM volatile ("strexb %0, %2, [%1]" : "=&r" (result) : "r" (addr), "r" (value) );
6
   return(result);
7
}

Das stand vorher drin:
1
__ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );

habe ich irgendwo im Forum gelesen, bin mir aber nicht wirklich sicher 
ob das korrekt ist. Vielleicht liegt es auch daran?

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

lutz h. schrieb:
> So läuft die Funktion bei mir.

Im Blink-LED Projekt funktioniert dieser Funktionsaufruf auch.

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Angehängte Dateien:

Lesenswert?

Der SEGGER ist schuld !!!!

Der kann nicht mehr Flashen!!!

Anbei der Screenshot vom Flash-Inhalt mit "JMem.exe" ausgelesen.

Da sieht man schön, dass der Segger JLINK nicht alles in das Flash 
schreibt!!!

Jetzt kommt die nächste Preisfrage:
Wie kann in dem J-LINK die alte Firmware wieder einspielen, so dass der 
wieder frunktioniert wie früher?

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.