-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
debug: coredump: add internal flash backend based on nrfx #21418
base: main
Are you sure you want to change the base?
Conversation
CI InformationTo view the history of this post, clich the 'edited' button above Inputs:Sources:sdk-nrf: PR head: 346ee03e6a264430ba88d3522a67cda38eb2a9b8 more detailssdk-nrf:
Github labels
List of changed files detected by CI (7)
Outputs:ToolchainVersion: 7cbc0036f4 Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
e609e22
to
905e41a
Compare
@@ -938,7 +938,8 @@ Common Application Framework | |||
Debug libraries | |||
--------------- | |||
|
|||
|no_changes_yet_note| | |||
* Added an experimental :ref:`Zephyr Core Dump <zephyr:coredump>` backend that writes a core dump to an internal flash or RRAM partition. | |||
To enable this backend set the :kconfig:option:`CONFIG_DEBUG_COREDUMP_BACKEND_OTHER` and :kconfig:option:`CONFIG_DEBUG_COREDUMP_BACKEND_NRF_FLASH_PARTITION` Kconfig options. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To enable this backend set the :kconfig:option:`CONFIG_DEBUG_COREDUMP_BACKEND_OTHER` and :kconfig:option:`CONFIG_DEBUG_COREDUMP_BACKEND_NRF_FLASH_PARTITION` Kconfig options. | |
To enable this backend, set the :kconfig:option:`CONFIG_DEBUG_COREDUMP_BACKEND_OTHER` and :kconfig:option:`CONFIG_DEBUG_COREDUMP_BACKEND_NRF_FLASH_PARTITION` Kconfig options. |
You can find the documentation preview for this PR here. Preview links for modified nRF Connect SDK documents: |
905e41a
to
5e677de
Compare
if ((offset % FLASH_WRITE_SIZE) != 0) { | ||
write_error = -EINVAL; | ||
return; | ||
} | ||
|
||
if (!is_within_partition(offset, size)) { | ||
write_error = -ENOMEM; | ||
return; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these should be asserts. There is nothing we can do at this point, there is no recovery and returning error from here is pointless, because the problem is with the caller not properly aligning buffers.
Tests here are just adding to code, while this is the last stand driver that should have minimal code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding alignment, I agree, though do you think it is OK to trigger another fatal error (assertion) while processing the previous one? Won't it cause a core dump loop? Maybe I can just remove this check and let driver layer underneath fail if the alignment is wrong?
Regarding is_within_partition
, I think we should keep it even when assertions are disabled - one may simply allocate to small partition (which is easy to misconfigure) and we don't want to do out of bounds writes in such a case. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding alignment, I agree, though do you think it is OK to trigger another fatal error (assertion) while processing the previous one? Won't it cause a core dump loop? Maybe I can just remove this check and let driver layer underneath fail if the alignment is wrong?
Yeah, I think we can just rely here on driver failing anyway.
Regarding
is_within_partition
, I think we should keep it even when assertions are disabled - one may simply allocate to small partition (which is easy to misconfigure) and we don't want to do out of bounds writes in such a case. What do you think?
Let it be as it as is.
The perfect solution here would be if we could run build in "test configuration" mode, where we could catch all problems that are misconfiguration at compile time. Because, notice that you will not have info that partition is too small until your core dump does not fit.
5e677de
to
262beaa
Compare
@nordic-krch @nordicjm could you please review? |
Add Zephyr core dump backend that saves a core dump to the internal flash or RRAM partition named "coredump_partition". This backend is an alternative to BACKEND_FLASH_PARTITION provided by Zephyr but it bypasses Zephyr flash device layer and uses nrfx directly, which offers the following benefits: 1. Bypasses synchronization primitives used by Zephyr flash or RRAM drivers. Currently, Zephyr flash drivers cannot be used to write to flash from a fault handler because of this. 2. Works with Partition Manager. 3. Minimizes the dependencies needed to successfully write a core dump, which is important as the core dump often needs to be written when the system is in the corrupted state. Only flash and RRAM are supported for now (no MRAM support). Signed-off-by: Damian Krolik <damian.krolik@nordicsemi.no>
262beaa
to
346ee03
Compare
Add Zephyr core dump backend that saves a core dump to the internal flash or RRAM partition named "coredump_partition".
This backend is an alternative to BACKEND_FLASH_PARTITION provided by Zephyr but it bypasses Zephyr flash device layer and uses nrfx directly, which offers the following benefits:
Only flash and RRAM are supported for now (no MRAM support).