There is a bug in arch_main.c
The cs_table is currently declared as an uint8_t array and therefore has alignment 1. However, during the booting there are store instructions that stores 16-bit data into this buffer.
I happen to have variables in my app that makes the cs_table getting an odd address when I look at the .map file. Then the hardfault handler gets executed during the booting.
After I change __attribute__((section("cs_area"), zero_init)) to __attribute__((section("cs_area"), zero_init, aligned(2))), it works good again.
Keywords:
Device:
Thanks Joacimwe, i will repor this back to the SW team. BR JE_Dialog
Hi Joacimwe,
The zero_init region will be fully initialized as all ZERO during booting, so the storing operation won't happen on cs_table at that time.
As I tested, the global variables assigned with an odd start address in zero_init region won't cause hardfault:
notAligned 0x200090f0 Data 3 arch_main.o(cs_area)
notAligned2 0x200090f3 Data 8 arch_main.o(cs_area)
So I guess the hardfault is not caused by storing cs_table, but caused by the access to the other global variables whose address are influenced by cs_table start address.
Could you help to upload your scatter loading file and outputted map file for us to check?
Thanks!
Hi. These are steps to reproduce:
1.解压缩DA14580_581_SDK_3.0.8.0.zip.
2. Open the project template_581.uvproj in Keil.
3. Set maximum connections to 8 in da14580_config.h:
/*Maximum user connections*/
#define BLE_CONNECTION_MAX_USER 8
4. Add the following code to app_init_func() in app_template_proj.c:
static volatile char buf[1357];
buf[0] = 0;
5. Press Build (F7).
6. Configure the correct SW debugger and start debug on DA14581 (I use a devkit BASIC).
7. You will now reach HardFault_HandlerC.
The relevant part extracted from the generated .map file:
init.s 0x00000000 Number 0 init.o ABSOLUTE
retention_mem_area0 0x00080328 Section 28 uart2.o(retention_mem_area0)
uart2_env 0x00080328 Data 28 uart2.o(retention_mem_area0)
.bss 0x00080908 Section 188 gpio.o(.bss)
.bss 0x000809c4 Section 1365 app_template_proj.o(.bss)
buf 0x000809cc Data 1357 app_template_proj.o(.bss)
cs_area 0x00080f19 Section 120 arch_main.o(cs_area)
heap_msg_area 0x00080f94 Section 6252 jump_table.o(heap_msg_area)
retention_mem_area0 0x00082800 Section 36 app_sec.o(retention_mem_area0)
在这里，您可以看到，CS_AREA放在奇数地址。如果我开始调试并在Arch_main中设置一个断点并通过每个代码行踩下，当下一行是“RWIP_INIT（错误）;”我按“步骤”，调用硬盘处理程序。
(Ignore the fact that you normally would set the device role to Central to make 8 connections reasonable, since the hardfault handler is called before app_configuration_func is called).
Dear customer,
Thanks for your detailed information.
We’ve reproduced this issue and we get to know the root cause is the section cs_area is assigned with an odd start address following the bss region of app_template_proj.o, so during the initialization of cs_area, the 16 bits access offences the 0x00080f18 address belonging to another bss region. So, yes, your judge is right.
0x00080908 0x000000bc Zero RW 630 .bss gpio.o
0x000809c4 0x00000555 Zero RW 1431 .bss app_template_proj.o
0x00080f19 0x00000078 Zero RW 117 cs_area arch_main.o
0x00080f91 0x00000003 PAD
0x00080f94 0x0000186c Zero RW 288 heap_msg_area jump_table.o
0x00082800 0x00000024 Zero RW 1373 retention_mem_area0 app_sec.o
Also we confirm that your fix is the best way on this bug.
Because cs_area is the first section from the aspect of address, while the following explicitly defined sections heap_env_area, heap_msg_area and heap_db_area will be automatically padded by linker, if we can assure that the start address of cs_area is aligned, then this bug can be surely fixed.
Thanks again for your finding!
We will add following fix into next release SDK version.
#ifndef __DA14581__
#if (BLE_CONNECTION_MAX_USER > 4)
volatile uint8_t cs_table[EM_BLE_CS_COUNT_USER * REG_BLE_EM_CS_SIZE] __attribute__((section("cs_area"), zero_init, aligned(4)));
#endif
#else
#if (BLE_CONNECTION_MAX_USER > 1)
volatile uint8_t cs_table[(BLE_CONNECTION_MAX + 2) * REG_BLE_EM_WPB_SIZE * 2]__attribute__((section("cs_area"), zero_init, aligned(4)));
#endif
#endif