utilisation de malloc dans les programmes contiki

Considérez le programme contiki suivant.

#include #include"contiki.h" #include  static char *mem; static int x; /*---------------------------------------------------------------------------*/ PROCESS(test, "test"); AUTOSTART_PROCESSES(&test); /*---------------------------------------------------------------------------*/ PROCESS_THREAD(test, ev, data) { PROCESS_BEGIN(); printf("before malloc\n"); mem=(char*)malloc(10); for(x=0;x<10;x++) mem[x]=x+1; printf("after malloc\n"); PROCESS_END(); } 

Lorsque ce programme est compilé pour native / z1 / wismote / cooja, il s’exécute parfaitement et les deux instructions printf sont exécutées. Toutefois, lorsqu’elles sont compilées pour la cible mbxxx, puis exécutées sur du matériel, seules les premières instructions printf sont exécutées et le code bloqué. dans le malloc. Une conjecture ou une raison derrière ce comportement? Je joins également la trace GDB ici.

 (gdb) mon reset init target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08000efc msp: 0x20000500 (gdb) b test.c:16 Breakpoint 1 at 0x8000ec8: file test.c, line 16. (gdb) b test.c:17 Breakpoint 2 at 0x8000ece: file test.c, line 17. (gdb) b test.c:18 Breakpoint 3 at 0x8000ed8: file test.c, line 18. (gdb) load Loading section .isr_vector, size 0x84 lma 0x8000000 Loading section .text, size 0xc5c4 lma 0x8000084 Loading section .data, size 0x660 lma 0x800c648 Start address 0x8000084, load size 52392 Transfer rate: 15 KB/sec, 8732 bytes/write. (gdb) c Continuing. Note: automatically using hardware breakpoints for read-only addresses. Breakpoint 1, process_thread_test (process_pt=0x2000050c , ev=129 '\201', data=0x0) at test.c:16 16 printf("before malloc\n"); (gdb) c Continuing. Breakpoint 2, process_thread_test (process_pt=0x2000050c , ev=, data=) at test.c:17 17 mem=(char*)malloc(10); (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. Default_Handler () at ../../cpu/stm32w108/hal/micro/cortexm3/stm32w108/crt-stm32w108.c:87 87 { (gdb) bt #0 Default_Handler () at ../../cpu/stm32w108/hal/micro/cortexm3/stm32w108/crt-stm32w108.c:87 #1  #2 0x08000440 in _malloc_r () #3 0x08000ed4 in process_thread_test (process_pt=0x2000050c , ev=, data=) at test.c:17 #4 0x0800272c in call_process (p=0x20000500 , ev=, data=) at ../../core/sys/process.c:190 #5 0x080028e6 in process_post_synch (p=, ev=ev@entry=129 '\201', data=) at ../../core/sys/process.c:366 #6 0x0800291a in process_start (p=, arg=arg@entry=0x0) at ../../core/sys/process.c:120 #7 0x08002964 in autostart_start (processes=) at ../../core/sys/autostart.c:57 #8 0x08001134 in main () at ../../platform/mbxxx/./contiki-main.c:210 (gdb) 

Ahhh … Enfin résolu le problème. Ce problème particulier était là parce que stm32w108 n’était pas configuré pour utiliser la mémoire dynamic.

Il suffisait d’ouvrir le fichier suivant: contiki-2.7 / cpu / stm32w108 / hal / micro / cortexm3 / stm32w108 / crt-stm32w108.c et d’append #define USE_HEAP en haut du fichier ou avant l’implémentation de _sbrk! La taille du tas peut également être modifiée ici, pas à partir du script de l’éditeur de liens, bien que la taille de la stack

Remarque secondaire: l’ utilisation de l’allocation de mémoire dynamic dans les systèmes embarqués est une très mauvaise idée, évitez-la! C’est sale, croyez-moi! Finalement, je supprimerai également toutes les références d’allocation de mémoire dynamic! 🙂