Cortex M0-hardfault bei Zugriff auf Variable

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.

Vielen Dank für die vielen Anregungen!

__packed
ist natürlich obsolet.


Im Watch war der erste Hinweis:

1

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:

1

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.

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.

Danke für die Tipps.

Auffällig ist, dass in der Funktion

syscalls.c

1

extern caddr_t _sbrk(int incr)

2

{  static unsigned char *heap = NULL;

3

  unsigned char *prev_heap;

4

5

  if (heap == NULL) {

6

    heap = (unsigned char *)&_end;

7

  }

8

9

  prev_heap = heap;

10

11

  heap += incr;

12

13

  return (caddr_t) prev_heap;

14

}

incr=0x9f8 und  heap=0x20007898

Dann ist nach

1

  heap += incr;

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

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

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:
>

1

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):

1

caddr_t

2

_sbrk(int incr)

3

{

4

  extern char _Heap_Begin; // Defined by the linker.

5

  extern char _Heap_Limit; // Defined by the linker.

6

7

  static char* current_heap_end;

8

  char* current_block_address;

9

10

  if (current_heap_end == 0)

11

    {

12

      current_heap_end = &_Heap_Begin;

13

    }

14

15

  current_block_address = current_heap_end;

16

17

  // Need to align heap to word boundary, else will get

18

  // hard faults on Cortex-M0. So we assume that heap starts on

19

  // word boundary, hence make sure we always add a multiple of

20

  // 4 to it.

21

  incr = (incr + 3) & (~3); // align value to 4

22

  if (current_heap_end + incr > &_Heap_Limit)

23

    {

24

      // Some of the libstdc++-v3 tests rely upon detecting

25

      // out of memory errors, so do not abort here.

26

#if 0

27

      extern void abort (void);

28

29

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

30

31

      abort ();

32

#else

33

      // Heap has overflowed

34

      errno = ENOMEM;

35

      return (caddr_t) - 1;

36

#endif

37

    }

38

39

  current_heap_end += incr;

40

41

  return (caddr_t) current_block_address;

42

}