Unable to debug due to flashregion locked on Thingy91

RE: Unable to debug due to flashregion locked on Thingy91

marco.peli — Wed, 06 Dec 2023 13:35:35 GMT

Hi Hakon,

ok thank you!

I will buy a nrf9160dk and debug on it ;)

Thank you!

Best regards

Marco Peli

RE: Unable to debug due to flashregion locked on Thingy91

Håkon Alseth — Wed, 06 Dec 2023 13:33:23 GMT

Hi Marco,

I would strongly recommend using the nRF9160-DK for development purposes.

[quote user="marco.peli"]The fact is that i cannot build my real application using the secure board because i get the error that pm_config.h, which file nrf_modem_os imports, cannot be found (and i need the modem library for my project)[/quote]

Sorry for misunderstand the context, I thought you were debugging the secure image, but you configure the board itself as "thingy91_nrf9160" - ie. the secure board.

This will not work when trying to communicate with the modem, as there is a hardware restriction in nRF9160 that enforces all communication with the modem to be in non-secure mode.

Kind regards,

Håkon

RE: Unable to debug due to flashregion locked on Thingy91

marco.peli — Wed, 06 Dec 2023 10:49:49 GMT

Hi Hakon,

here's the output: debug secure with -0g - Pastebin.com

Do you suggest to debug the application on the nrf9160dk? I don't have so much time thus if debugging the application on that board solves my issues i can go for that.

Thank you!

Best Ragards

Marco Peli

RE: Unable to debug due to flashregion locked on Thingy91

Håkon Alseth — Wed, 06 Dec 2023 10:02:04 GMT

Hi,

The assert seems to only occur in thingy91, when TFM is built with DEBUG_OPTIMIZATIONS. Sorry for not spotting this earlier. I will report this internally.

As a workaround to this, you can set any other optimization level on configuration (ie. in vscode), and then use "nRF Kconfig GUI" to change only your application optimization level:

This will not re-compile tf-m image.

Over to your root problem:

Can you share the build output?

Thingy91 is not the best platform to develop on, as it has a hard restriction on the partition layout of a project. It will enforce a static partition layout, to ensure that DFU can be done on the thingy91.

Kind regards,

Håkon

RE: Unable to debug due to flashregion locked on Thingy91

marco.peli — Wed, 06 Dec 2023 09:09:27 GMT

Hi Hakon,

a small update, i can successfully debug the blinky example if i build using the secure board (i was using the unsecure board until now).
The fact is that i cannot build my real application using the secure board because i get the error that pm_config.h, which file nrf_modem_os imports, cannot be found (and i need the modem library for my project)

Any thoughts on that?

Thank you!

RE: Unable to debug due to flashregion locked on Thingy91

marco.peli — Tue, 05 Dec 2023 21:05:11 GMT

Hi Hakon,

i tried to set CONFIG_MAIN_STACK_SIZE to 32768 bytes with no result .

As last resort, i tried debugging the very basic zephyr blinky example and i the code gets stuck in the same instruction during debug.

i also tried to set the CONFIG_MAIN_STACK_SIZE to 65536 bytes (just to test) with the blinky sample, but same result: the code gets stuck in the same exact instruction during debug with -Og.

I attach a screenshot of the cpu registers: https://ibb.co/L8HcKTm

Thank you!

Best regards

Marco Peli

RE: Unable to debug due to flashregion locked on Thingy91

Håkon Alseth — Tue, 05 Dec 2023 14:49:12 GMT

Hi Marco,

The second thread there, seems to be in a fault handler.

Can you expand all debug fields here?

Also, did you try to adjust the stack sizes (CONFIG_MAIN_STACK_SIZE) to see if this has any effect on the boot procedure?

Kind regards,

Håkon

RE: Unable to debug due to flashregion locked on Thingy91

marco.peli — Tue, 05 Dec 2023 14:36:13 GMT

Hi Hakon,

thank you for your support.

Here's the screenshot of the stacktrace: https://ibb.co/CnkM198
What registers would you like to see?

thank you!

Marco Peli

RE: Unable to debug due to flashregion locked on Thingy91

Håkon Alseth — Tue, 05 Dec 2023 14:14:28 GMT

Hi,

That assert indicates that the p_reg that goes in is problematic.

When compiling with no optimization and debug optimization, the firmware will use more stacked memory. In most cases, you will have to adjust your thread stack sizes to accommodate for debug build (usually MAIN_STACK_SIZE). Is there other .conf files loaded into your project? It does not look like asserts are enabled?

NRFX_ASSERT should become a "zephyr assert":

https://github.com/nrfconnect/sdk-zephyr/blob/v3.4.99-ncs1/modules/hal_nordic/nrfx/nrfx_glue.h#L35

Could you share the callstack (backtrace) and cpu registers when this occurs?

Kind regards,

Håkon