Cortex M0-hardfault bei Zugriff auf Variable

[Thomas K. (thomaskroger)]

Im Atmel Studio mit einem SAM21 Cortex M0 läuft das Programm in einen
hardfault wenn ein Zugriff auf eine Variable stattfindet.

Die Deklaration von xy_lcd_cursorPosition ist problemlos:

bla.c
#include "bla.h" 

//uint8_t  xy_lcd_cursorPosition __attribute__((aligned(4)))=0;
//uint32_t  xy_lcd_cursorPosition =0;
//uint8_t  xy_lcd_cursorPosition;
uint8_t  xy_lcd_cursorPosition=0;

static const __packed uint8_t ssd1306_font6x8 [] = 
{   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // sp
    0x00, 0x00, 0x00, 0x2f, 0x00, 0x00, // !
...bla

Sobald aber ein Schreib(!)zugriff statt findet, läuft das Programm 
sofort beim Start in einen hardfault. Ohne Zugriff läuft das Programm:

status_code xy_lcd_init()
{   xy_lcd_cursorPosition=0;  //->HardFault
    //xy_lcd_cursorPosition=0;  //läuft

Ein Breakpoint bei

//startup_sam21.c
__libc_init_array();

geht. Danach im Disassembler weiter ist mühsam und bringt keine 
Erkenntnisse.

  __asm("BKPT #1\n") ; // Break into the debugger

R0 = 0x20000118
R1 = 0xfffffff9
R2 = 0x118
R3 = 0x9E9
R12 = 1
IPSRm = 3
APSR = 0x40000000
PSR = 0x40000003
AIRCR =0xfa050000
SCR = 0
CCR = 0x00000208

Übrigens, ein Breakpoint bei

status_code xy_lcd_init()
{   
-> xy_lcd_cursorPosition=0;  //->HardFault

wird nicht angelaufen.


Hat jemand eine Idee?
Besten Dank.

[Nop (Gast)]

Mach mal Singlestep, und zwar im im Disassembly.

[Adam P. (adamap)]

Kann es evtl. sein, dass da vom Aufbau etwas nicht passt...
weil wenn der Breakpoint nicht angesprungen wird, dann stimmt da was 
nicht.

Hast vllt. die ganze Datei? Das man den Aufbau erkennt.

Schau mal in die Aufrufliste im Debug-Mode von wo er in den Hard-Fault 
springt.

[Sebi (Gast)]

Kannst du dir die Adresse deiner Variable anschauen und überprüfen ob 
die Adresse zum RAM deines Mikrocontrollers gehört? Vielleicht geht 
irgendwas mit deinem Linkerscript durcheinander. Funktionieren denn 
lokale Variablen oder die auch nicht?

[Schrumpfkopf (Gast)]

Vielleicht helfen Erkenntnisse aus:

https://mcuoneclipse.com/2012/11/24/debugging-hard-faults-on-arm-cortex-m/

[Dr. Sommer (Gast)]

Thomas K. schrieb:
> __packed

Sehr verdächtig. Unaligned-Zugriffe gehen auf dem Cortex-M0 nicht 
(->Absturz). Benutzt du so etwas noch bei anderen Typen? Kompilierst du 
mit -munaligned-access?

Wie sehen die Register beim Hard Fault aus? Insbesondere das LR? Was 
steht im CFSR? Wie sieht der Assembler-Code an der Stelle, die im LR 
steht, aus?

Ansonsten Assembler Step-By-Step.

[Thomas K. (thomaskroger)]

Vielen Dank für die vielen Anregungen!

__packed
ist natürlich obsolet.


Im Watch war der erste Hinweis:

xy_lcd_cursorPosition  0x10  uint8_t(static storage at address 0x0)

address bei 0x0 ist Unsinn und Inhalt 0x10 ist verdächtig.

Das zentrale Problem war offenbar ein Durcheinander in der Make-Datei 
bzw. Müll im SolutionExplorer. Ich arbeite mit Links auf Dateien da die 
Sources für mehrerer Projekte verfügbar sein müssen. Da hatte sich tief 
versteckt ein Link auf eine alte *.c im Backup-Ordner eingeschlichen und 
die *.d und *.o-Files wollten sich auch nicht finden lassen.

Nach dem gründlichen Aufräumen des SolutionExplorer und Neustart(!) 
gehts:

xy_lcd_cursorPosition  0x00  uint8_t(static storage at address 0x20001048)

Es war also so, dass unbemerkt eine alte *.c, die nicht in das Projekt 
gehört, mit dem gleichen Namen wie die aktuelle *.cpp den Compiler an 
die Wand gespielt hat.

[Jim M. (turboj)]

Thomas K. schrieb:
> Ich arbeite mit Links auf Dateien da die
> Sources für mehrerer Projekte verfügbar sein müssen.

Damit zerschießt man sich make recht zuverlässig, da sich bei Links das 
Datum nicht ändert, wenn man das Original angefasst hat.

Du solltest also ein "make clean" in dein default Build Skript einbauen, 
denn so werden nur komplette rebuilds tun.

[Dr. Sommer (Gast)]

Thomas K. schrieb:
> Ich arbeite mit Links auf Dateien da die
> Sources für mehrerer Projekte verfügbar sein müssen.

Oje, sowas macht man lieber mit Libraries...

[Thomas K. (thomaskroger)]

Danke für die Tipps.

Auffällig ist, dass in der Funktion

syscalls.c

extern caddr_t _sbrk(int incr)
{  static unsigned char *heap = NULL;
  unsigned char *prev_heap;

  if (heap == NULL) {
    heap = (unsigned char *)&_end;
  }

  prev_heap = heap;

  heap += incr;

  return (caddr_t) prev_heap;
}

incr=0x9f8 und  heap=0x20007898

Dann ist nach

  heap += incr;

heap=0x20008290 und damit außerhalb des SRAM-Bereiches.

[Dr. Sommer (Gast)]

Thomas K. schrieb:
> heap=0x20008290 und damit außerhalb des SRAM-Bereiches.

Dann fehlt in der _sbrk-Funktion dringend eine Bereichsprüfung. Und 
natürlich benutzt dein Programm zu viel malloc(). Das "extern" ist hier 
übrigens überflüssig. Das hat überhaupt nur eine Wirkung an globalen 
Variablen und keine an Funktionen.

[Vincent H. (vinci)]

Bei der _sbrk Implementierung brennts auf einem M0 sowieso. Wenn "incr" 
kein vielfaches von 4x ist dann verliert man das notwendige Alignment.

[Dr. Sommer (Gast)]

Vincent H. schrieb:
> Bei der _sbrk Implementierung brennts auf einem M0 sowieso. Wenn "incr"
> kein vielfaches von 4x ist dann verliert man das notwendige Alignment.

Sollte nicht malloc dafür sorgen? Im Zweifelfall so aufrunden:

incr = (incr + 3) & 0xFFFFFFFC;

[Vincent H. (vinci)]

Dr. Sommer schrieb:
> Vincent H. schrieb:
>> Bei der _sbrk Implementierung brennts auf einem M0 sowieso. Wenn "incr"
>> kein vielfaches von 4x ist dann verliert man das notwendige Alignment.
>
> Sollte nicht malloc dafür sorgen? Im Zweifelfall so aufrunden:
>

incr = (incr + 3) & 0xFFFFFFFC;

Hm, da bin ich mir nicht sicher. GNU MCU Ecplise etwa liefert in seiner 
newlib Variante genau das was du grad vorgeschlagen hast (inkl. Limit 
Prüfung):

caddr_t
_sbrk(int incr)
{
  extern char _Heap_Begin; // Defined by the linker.
  extern char _Heap_Limit; // Defined by the linker.

  static char* current_heap_end;
  char* current_block_address;

  if (current_heap_end == 0)
    {
      current_heap_end = &_Heap_Begin;
    }

  current_block_address = current_heap_end;

  // Need to align heap to word boundary, else will get
  // hard faults on Cortex-M0. So we assume that heap starts on
  // word boundary, hence make sure we always add a multiple of
  // 4 to it.
  incr = (incr + 3) & (~3); // align value to 4
  if (current_heap_end + incr > &_Heap_Limit)
    {
      // Some of the libstdc++-v3 tests rely upon detecting
      // out of memory errors, so do not abort here.
#if 0
      extern void abort (void);

      _write (1, "_sbrk: Heap and stack collision\n", 32);

      abort ();
#else
      // Heap has overflowed
      errno = ENOMEM;
      return (caddr_t) - 1;
#endif
    }

  current_heap_end += incr;

  return (caddr_t) current_block_address;
}