Not applicable
Aug 21, 2014
08:10 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 21, 2014
08:10 AM
Hi,
I'm running a Dave project for XMC4500 useing FreeRtos.
The heap for FreeRtos is allocated to DSRAM1 section (.bss) togheter with all other variables.
A wrapper is added to use the OS corresponding functions for malloc() and free() in the project. This will leave the "Heap_Bank1" unused i hope.
The size of Heap_Bank1 will be what's left in section DSRAM1. If at least 4kB is left for Heap_Bank1 the program is running without exception interrupt,
but if an increased .bss variable makes the remaining size less than 4kB a bus fault will interrupt.
It looks like the bus fault exception is caused in vsprintf(), called from printf(). Normaly an array of float values will be constantly printed to a uart debug port.
What causes the bus fault ?
Why does Heap_Bank1 needs 4kB RAM (no error from linker) ?
As we need RAM we would like to use RAM sections DSRAM2 and PSRAM1 if possible.
How is that done ?
It would be great if the heap could be moved to another section.
Regards, Peter Widetun
I'm running a Dave project for XMC4500 useing FreeRtos.
The heap for FreeRtos is allocated to DSRAM1 section (.bss) togheter with all other variables.
A wrapper is added to use the OS corresponding functions for malloc() and free() in the project. This will leave the "Heap_Bank1" unused i hope.
The size of Heap_Bank1 will be what's left in section DSRAM1. If at least 4kB is left for Heap_Bank1 the program is running without exception interrupt,
but if an increased .bss variable makes the remaining size less than 4kB a bus fault will interrupt.
It looks like the bus fault exception is caused in vsprintf(), called from printf(). Normaly an array of float values will be constantly printed to a uart debug port.
What causes the bus fault ?
Why does Heap_Bank1 needs 4kB RAM (no error from linker) ?
As we need RAM we would like to use RAM sections DSRAM2 and PSRAM1 if possible.
How is that done ?
It would be great if the heap could be moved to another section.
Regards, Peter Widetun
2 Replies
Not applicable
Aug 25, 2014
05:27 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 25, 2014
05:27 AM
I maneged to move the OS-heap to section ETH_RAM (DSRAM2) with the following attribute.
__attribute__((section ("ETH_RAM"))) unsigned char ucHeap[ configTOTAL_HEAP_SIZE ];
By moving the heap from section .data (DSRAM1) the Heap_Bank2 could increase.
This seems to solv the problem for now, no exception for bus error, but I assume the error will return if Heat_bank2 becomes to small.
I hade another problem when I tried to move ucHeap to section .data3 (PSRAM1). No error from compiler and linker but when the program was loaded the debugger could not start
and an error occurs: "Loading failed: A problem occurd during downloading: memory at 0x100008dc was written to sucessfully, but the value read back does not match."
We use Segger J-link Plus debugger.
Any hints of what could cause that error ?
/Peter
__attribute__((section ("ETH_RAM"))) unsigned char ucHeap[ configTOTAL_HEAP_SIZE ];
By moving the heap from section .data (DSRAM1) the Heap_Bank2 could increase.
This seems to solv the problem for now, no exception for bus error, but I assume the error will return if Heat_bank2 becomes to small.
I hade another problem when I tried to move ucHeap to section .data3 (PSRAM1). No error from compiler and linker but when the program was loaded the debugger could not start
and an error occurs: "Loading failed: A problem occurd during downloading: memory at 0x100008dc was written to sucessfully, but the value read back does not match."
We use Segger J-link Plus debugger.
Any hints of what could cause that error ?
/Peter
Not applicable
Oct 28, 2014
11:28 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oct 28, 2014
11:28 PM
Hi Peter,
Because of the holes in the SRAM memory map, you can try to map the heap to .ram_code instead of .data3.
.data3 is for uninitialized variables whereas .ram_code is for initialized code and data.
Best regards,
Sophia
Because of the holes in the SRAM memory map, you can try to map the heap to .ram_code instead of .data3.
.data3 is for uninitialized variables whereas .ram_code is for initialized code and data.
Best regards,
Sophia