Crash on allocation

Technical Support Standard SDK
1

Hi All,
I faced with problem that malloc fails from http callback with a following crash dump.

 file = malloc(sizeof(FIL));

or

 file = new FIL;

Hard Fault Patch (Secure)

Security Fault: 

Secure State: 1

Stacked: 

R0 = 0x28206669
R1 = 0x00000000
R2 = 0x0a3b28e7
R3 = 0xdeadbeef
R12 = 0x28206669
LR = 0x1000c7e1
PC = 0x0e066bee
PSR = 0x21000000


Current: 

EXC_RETURN = 0xffffffb9
MSP = 0x10033048
PSP = 0x10033048
xPSR = 0xa0000007
CFSR  = 0x00000400
HFSR  = 0x00000000
DFSR  = 0x00000000
MMFAR = 0x00000000
BFAR  = 0x00000000
AFSR  = 0x00000000
PriMask = 0x00000000
SVC priority: 0x00
PendSVC priority: 0x00
Systick priority: 0x00
MSP_NS = 0x10004fd8
PSP_NS = 0x10033048
CFSR_NS  = 0x00000400
HFSR_NS  = 0x00000000
DFSR_NS  = 0x00000000
MMFAR_NS = 0x00000000
BFAR_NS  = 0x00000000
AFSR_NS  = 0x00000000
SVC priority NS: 0x00
PendSVC priority NS: 0xe0
Systick priority NS: 0xe0

What does mean “Hard Fault Patch (Secure)” and why code is closed for this handler? And is it possible to replace this handler?

2

Hello @Tuxford,

May I check with you, which standard SDK version and example are you currently running?

3

Hi @pammyleong
Problem was that I switched to C++ and operators new and delete were not implemented.
When I added next code everything works fine.

void *operator new(std::size_t sz)
{
    return pvPortMalloc(sz);
}

void operator delete(void *p)
{
    vPortFree(p);
}
5

Hi @Tuxford ,

Do you mind sharing where did you include these 2 functions (In which c++ file)? If you are using Arduino, you can make used of “malloc” and “free” instead. You can refer to ambpro2_arduino/BLECharacteristic.cpp at dev · ambiot/ambpro2_arduino · GitHub (Line 14 and 18). Previously you got hard fault, it could be because you did not typecast file = malloc(sizeof(FIL)); correctly.

6

Hi @pammyleong
I don’t use arduino. I use SDK only.

7

Hi @pammyleong
It seems it was side effect because I often have mem hard fault like that below without clear resolution. What is suspicious that it is impossible to debug rtlk_* functions. E.g.


Breakpoint 1, wifi_disconn_hdl (buf="", buf_len=8, flags=0, userdata=) at /home/[skp]/Src/Honsel/ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/xml/asdk/../../../../../component/common/api/wifi/wifi_conf.c:496
496                     wifi_link_err_parse(disconn_reason);
(gdb) s
wifi_link_err_parse (reason_code=0) at /home/[skp]/Src/Honsel/ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/xml/asdk/../../../../../component/common/api/wifi/wifi_conf.c:395
395             link_err = rltk_wlan_get_link_err();
(gdb) n
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
INT_MemFault_Patch () at /home/[skp/Src/Honsel/ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/xml/asdk/../../../../../component/soc/realtek/amebad/fwlib/ram_hp/rtl8721dhp_app_start.c:230
230             __ASM volatile(
(gdb) info threads 
  Id   Target Id         Frame 
* 1    Thread 57005      INT_MemFault_Patch () at /home/[skp]/Src/Honsel/ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/xml/asdk/../../../../../component/soc/realtek/amebad/fwlib/ram_hp/rtl8721dhp_app_start.c:230
(gdb)

Is it protection against debugging?

Than I checked if I made all correct fires for C++ support in AN, para 2.2. Are the addresses of wrapped functions always the same?

Can those warning be a problem? Why they occur after switching to C++?

./build/ram/httpd.o: warning: multiple common of `RDBuf'

./build/ram/example_fatfs.o: warning: previous common is here

./build/ram/httpd.o: warning: multiple common of `WRBuf'

./build/ram/example_fatfs.o: warning: previous common is here

/home/[skip]/Src/Honsel/ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/xml/toolchain/linux/asdk-6.4.1/linux/newlib/bin/../lib/gcc/arm-none-eabi/6.4.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .ram_image2.data by 2 bytes

/home/[skip]/Src/Honsel/ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/xml/toolchain/linux/asdk-6.4.1/linux/newlib/bin/../lib/gcc/arm-none-eabi/6.4.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .ram_image2.bss by 16 bytes

/home/[skip]/Src/Honsel/ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/xml/toolchain/linux/asdk-6.4.1/linux/newlib/bin/../lib/gcc/arm-none-eabi/6.4.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .ram_image2.bss by 16 bytes

/home/[skip]/Src/Honsel/ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/xml/toolchain/linux/asdk-6.4.1/linux/newlib/bin/../lib/gcc/arm-none-eabi/6.4.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .ram_image2.bss by 16 bytes

/home/[skip]/Src/Honsel/ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/xml/toolchain/linux/asdk-6.4.1/linux/newlib/bin/../lib/gcc/arm-none-eabi/6.4.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .ram_image2.bss by 16 bytes

/home/[skip]/Src/Honsel/ambd_sdk/project/realtek_amebaD_va0_example/GCC-RELEASE/xml/toolchain/linux/asdk-6.4.1/linux/newlib/bin/../lib/gcc/arm-none-eabi/6.4.1/../../../../arm-none-eabi/bin/ld: warning: changing start of section .ram_image2.bss by 16 bytes