I am trying to get the 6LowPAN+Destiny stack running on the STM32F3 boards. I am currently using Powerline Communication as the physical medium to work with this uC. I have abstracted out the powerline PHY using the transceiver module from RIOT. I am able to send and receive UDP messages using the sockets api. However, after exchanging about 25 messages, I get to a hard fault when I receive packets.
I have used the debugger and am fairly confident that the fault occurs in the 6LowPAN part of the stack. Specifically, in the function new_packet_buffer, in the file /sys/net/network_layer/lowpan.c . Every time a new packet is received, memory is allocated to new_buf in this function and I am guessing we eventually run out of place. The memory allocated to this buffer never seems to be freed. Is this a bug with the stack or am I doing something wrong here?
Thank you for the quick reply. I am trying to figure out work around this problem. Do you think it makes sense for me to use the libc malloc and free functions? I am a bit hesitant to include the library because it might be too big and/or interfere with how the RIOT core is using the syscalls.
Hi,
currently the reassembly buffer is implemented with libc’s malloc/free but my new implementation will utilize a static approach via my own packet buffer implementation [1]. For your purposes I think it is ok for now to use malloc/free as a workaround, but keep in mind that for some boards where the libc is not offering this, there is currently not even a free implementation [2].
I have been using the oneway_malloc.c implementation and not libc! I will change that now. I definitely like the idea of a static implementation much better.
I am trying to get the 6LowPAN+Destiny stack running on the STM32F3
boards. I am currently using Powerline Communication as the physical
medium to work with this uC. I have abstracted out the powerline PHY
using the transceiver module from RIOT. I am able to send and receive
UDP messages using the sockets api. However, after exchanging about 25
messages, I get to a hard fault when I receive packets.
I have used the debugger and am fairly confident that the fault occurs
in the 6LowPAN part of the stack. Specifically, in the function
new_packet_buffer, in the file /sys/net/network_layer/lowpan.c . Every
time a new packet is received, memory is allocated to new_buf in this
function and I am guessing we eventually run out of place. The memory
allocated to this buffer never seems to be freed. Is this a bug with the
stack or am I doing something wrong here?
This still sounds a bit mysterious to me. We had the whole 6LowPAN stack
running with exchanging much more than 25 packets without a hard fault not so
long ago. So, either a recent change has had some unforeseen side effects or
your setting (i.e. data rate or/and packet size) differs in an error causing
way. Can you tell me at which data rate and with what packet sizes (physical
layer limitation and application layer payload) you were trying?
sorry for the late reply, just came back from holidays…
You have to be careful about using dynamic memory allocation on the Arm Cortex-M platforms (especially the ones I ported, which include the discovery boards). As malloc is implemented, free does nothing. So switching from oneway_malloc.c to libc calls won’t really bring any benefits at the moment. The only viable workaround is to use static memory and manage it yourself (-> which is what Martine is preparing as we speak…).
Hi Hauke,
hope you had a nice holiday and thank you for the input. I have removed oneway_malloc.c from my build paths and the malloc and free are now working fine for me. It is a bit strange but I am not able to tell for sure how this is working. It seems that there is a some standard implementation of these calls that the gnu-arm compiler knows where to find. So right now my program is working okay. I will let you know how things are going if I find out more.
Regards,
Abhinav
in the cpu/stm32f3 folder you find the syscalls.c. The malloc implementation of the newlib should end up somewhere in the _sbrk_r() call, not sure actually how the free call is implemented… But if its working for you for now.