Saving coredump to flash

user115422 over 4 years ago

I'm trying to enable saving of coredump to flash. I'm running on nrf52840 with NRF SDK 1.6.1.

I have defined the following:

CONFIG_DEBUG_COREDUMP=y

CONFIG_DEBUG_COREDUMP_BACKEND_FLASH_PARTITION=y

CONFIG_DEBUG_COREDUMP_MEMORY_DUMP_MIN=y

I set up a partition using pm_static.yml:

coredump_partition:

address: 0xff000

size: 0x1000

region: flash_primary

and added the entry in the dts file under &flash0:

coredump_partition: partition@ff000 {
label = "coredump_partition";
reg = <0x000ff000 DT_SIZE_K(4)>;
};

I then added a crash shell command that invokes a crash using either k_oops(); or __asm__ volatile("udf #0" : : : );. In either case, I verified that a coredump is generated if using LOGGING.

However, when I tried to use the BACKEND_FLASH_PARTITION it first complained about not being able to find an MSPL timeslot. There were no instructions regarding MPSL but I checked and saw that the default settings has 0 timeslots. I set it to 1 timeslot. Then I'm getting the following error when it's trying to erase the flash partition in preparation for coredump.

<err> flash_sync_mpsl: timeout

<err> coredump: Cannot start coredump!

I did verify that I can successfully erase the coredump using coredump erase

< coredump erase
00> coredump erase
00> Stored coredump erased.

There seems to be some issue with accessing flash during a coredump. There are no examples specific to nrf52 anywhere.

Top Replies

0 user15146 over 4 years ago in reply to user115422

NRF SDK 1.6.1.
ST-Kon said:
coredump_flash_backend_start() adds an offset for the header but does not adjust the size but the same amount

I see there was a fix here recently(fixed in NCS v1.9.x), see these 2 commits:

https://github.com/nrfconnect/sdk-zephyr/commit/1dc74d70f265ab753b9ef3f00450426bc2ccf296

https://github.com/nrfconnect/sdk-zephyr/commit/d5520f2e59b7d6d65bb8f4b6e848df1d46e95836
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 user115422 over 4 years ago in reply to user15146

user15146 said:
Seems like it's stream_flash_init() that returns an error-code. Could you print the error-code, and post it here? E.g. change the line to something like this to print the value:

I traced the issue down to nrf_flash_sync_exe() in flash_sync_mpsl.c. The error happens when that function tries to obtain the semaphore (with my slight modification to print the status):

int status = k_sem_take(&_context.timeout_sem, K_MSEC(FLASH_TIMEOUT_MS));

LOG_ERR("Sem take result: %d (%ld)\n", status, FLASH_TIMEOUT_MS);

if (status < 0) {

LOG_ERR("timeout");

atomic_set(&_context.timeout_occured, 1);

}

This results in EAGAIN:

<err> flash_sync_mpsl: Sem take result: -11 (22963)

I tried to play with the number of slots. I've tried 0, 1, and 2. All result in the same error.

CONFIG_MPSL_TIMESLOT_SESSION_COUNT=2
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 user115422 over 4 years ago in reply to user115422

After more digging, it appears that the issue is with how nrf uses k_sem_take(). According to Zephyr docs (https://docs.zephyrproject.org/3.0.0/reference/kernel/synchronization/semaphores.html), if k_sem_take is called from ISR, it must use K_NO_WAIT for timeout.

However, NRF SDK uses K_FOREVER or actual timeout values in various places that are involved in the coredump. Because coredump is happening in the ISR, those timeout values are not valid. An assert gets triggered, or if asserts are disabled, I imagine Zephyr is unhappy, which is why we fail to take the semaphore.

__ASSERT(((arch_is_in_isr() == false) ||

K_TIMEOUT_EQ(timeout, K_NO_WAIT)), "");

Same issue exists with mutexes. nrf_flash_sync_exe() acquires a mutex but mutex lock has this assert

__ASSERT(!arch_is_in_isr(), "mutexes cannot be used inside ISRs");
Cancel
Vote Up +1 Vote Down

Sign in to reply

Verify Answer

Cancel
0 user115422 over 4 years ago in reply to user115422

Any update on this? Is there a plan to support coredump to flash with BT enabled?

user15146
Cancel
Vote Up +1 Vote Down

Sign in to reply

Verify Answer

Cancel
0 user103823 over 4 years ago in reply to user115422

Yes, user15146 , has there been any follow up?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel