RE: Hard fault in Connection Parameter Update when changing ATT_MTU

Gergely Hollosi — Thu, 26 Mar 2020 13:41:03 GMT

Okay, I have managed to solve the problem, but I think it is a BUG in the nRF SDK. I have used the scheduler, so the BLE Connection Parameter Update timer (the APP_TIMER) used the scheduler also.

The main problem is the interaction between APP_TIMER and APP_SCHEDULER. If we choose APP_SCHEDULER's event size not mod 4 (i. e. 62, as I did), the APP_TIMER's timeout_handler is not forced to fall on 32 bit boundary, see app_scheduler.c:

uint32_t app_sched_event_put(void const              * p_event_data,

                             uint16_t                  event_data_size,

                             app_sched_event_handler_t handler)

{
...

memcpy(&m_queue_event_data[event_index * m_queue_event_size],

                       p_event_data,

                       event_data_size);

Of course, scheduler callbacks are properly aligned, however, app_timer callbacks stored in scheduler queues are not.

The solution for the problem is using event_size multiple of 4 bytes (words). I would be pleased if the SDK would not allow using event_size in scheduler not multiple of 4 bytes!

RE: Hard fault in Connection Parameter Update when changing ATT_MTU

Gergely Hollosi — Thu, 26 Mar 2020 11:56:04 GMT

I have some new information about the topic. When using -O3, compiler generates code as this:

0002b850 <scheduled_timeout_handler>:
  2b850:       e9d0 3000       ldrd    r3, r0, [r0]
  2b854:       4718            bx      r3
  2b856:       bf00            nop

The hard fault is at 2b850, having the issue:

<error> hardfault: HARD FAULT at 0x0002B850
<error> hardfault: R0: 0x20003052 R1: 0x00000008 R2: 0x20002EC4 R3: 0x0002B851
<error> hardfault: R12: 0x20002EEC LR: 0x0002B7F3 PSR: 0x810B0000
<error> hardfault: Cause: The processor has made an unaligned memory access.

Of course, R0 cannot be divided by 4 bytes, so unaligned access is present. However, I'm still searching for the solution.