Asset_tracker_v2 mcuboot mainc.c run time issue

[mexco]

I added following lines to prj.conf in asset_tracker_v2. Th build and compile is successful. When debugger is launched and step through various functions, the problem is irq_lock() in main.c of mcuboot. see the image 1. When the at line number 274 (vt->reset) is executed, the disassembly as in image 2 appears.

 

CONFIG_UART_ASYNC_API=y

CONFIG_UART_0_INTERRUPT_DRIVEN=y

CONFIG_UART_0_NRF_HW_ASYNC=n

CONFIG_UART_1_INTERRUPT_DRIVEN=n

CONFIG_UART_1_ASYNC=y

CONFIG_UART_1_NRF_HW_ASYNC=y

CONFIG_UART_1_NRF_HW_ASYNC_TIMER=1

CONFIG_UART_2_INTERRUPT_DRIVEN=n

CONFIG_UART_2_ASYNC=y

CONFIG_UART_2_NRF_HW_ASYNC=y

CONFIG_UART_2_NRF_HW_ASYNC_TIMER=1

//*********

By default .kconfig file of asset_tracker_v2, following is written.

config UART_INTERRUPT_DRIVEN

    default y if SERIAL

I need UART1 and UART2 in UART_ASYNC DMA mode and do not change settings of UART0. With this motive, I added above lines to prj.conf.

   

[Simon]

If the failure happens right after ((void (*)(void))vt->reset)() in mcuboot, it is probably not mcuboot that is failing, but rather the application. What that line does is to boot the main application.

However, this ticket is quite similar to this one: How to use UART_ASYNC function in UART_ISR nRF9160 based Asset_tracker_v2  (use UART_ASYNC in asset_tracker_v2). Please continue the discussion in that thread.

Best regards,

Simon

[mexco]

1. How you identified the error is not due to mcuboot rather due o application ? 

2. This issue started after I commented 

CONFIG_SERIAL=n in over-lay-low-power.conf and child_image/spm.conf

 

[Simon]

mexco said:

1. How you identified the error is not due to mcuboot rather due o application ? 

I forgot that SPM was used. So mcuboot jumps to SPM after it's done, not the application. So the failure can also happen in SPM. See the following figure:

So if the error happens after ((void (*)(void))vt->reset)(), and this is the last command in mcuboot, it might fail in SPM as well. 

It could also be application that is failing, the only thing is that it probably happens after mcuboot.

Try set a break point in the start of main in SPM and the application and see if these images are reached.

mexco said:

CONFIG_SERIAL=n in over-lay-low-power.conf and child_image/spm.conf

I don't understand this. In NCS v1.9.1 (and v2.0.0) these are set to n already by default.

https://github.com/nrfconnect/sdk-nrf/blob/v1.9.1/applications/asset_tracker_v2/overlay-low-power.conf#L11

https://github.com/nrfconnect/sdk-nrf/blob/v1.9.1/applications/asset_tracker_v2/child_image/spm.conf#L8

Best regards,

Simon