nrf5340 2.6 to 2.9 migration issues

[IvanR]

We have developed device that used 2.6 and when moving to 2.9 everything broke apart and I cant get it to boot and I cant get any output from device. Be it from USB or SWD pins (as its custom board). 

It worked a week ago but one day it just broke, note that it worked for months on 2.9. I've isolated the issue to configuration and not code. 

As I need P0.11 and P0.09 I've remaped them based on 

 RE: nrf5340 Gpio forwarder availibility 

but that triggered something in build. It looked like there were some remnant 2.6 configs or something. 

Now, im totaly confused. Anything I do results in failed compilation and if it does not for some reason or a another (a lot of testing) the device wont boot and I cant get any debug information out of it. 

Please provide what files or info you need to help me diagnose this issue.

Regards, 

[Vidar Berg]

Hi,

Are you able to share a minimal version of your project that will allow me to review the configuration reproduce this booting issue on a nRF5340 DK board? If not, please provide as much relevant information as you can. For example, the complete build output showing the build errors and the project configuration file (prj.conf, sysbuild.conf, etc).

Best regards,

Vidar

[IvanR]

2308.New folder.zip

Thank you !

[Vidar Berg]

I've update some of the configurations to sysbuild, please review the changes. I also recommend reading the migration document here https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/migration/migration_sysbuild.html and this devacademy course https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-sysbuild/ 

new_folder.zip

[IvanR]

Thank you,I will keep in mind the migration documentation, 
it compiles but device wont turn on, no usb, cant see whats happening on it. :(
Its on custom board  that is programed using SWD pins (I need to emphasize that it worked for months before this, situation). 
Ive added 

CONFIG_USB_CDC_ACM=y

CONFIG_SERIAL=y

CONFIG_UART_CONSOLE=y


prior it was enough to just

BUILD_ASSERT(DT_NODE_HAS_COMPAT(DT_CHOSEN(zephyr_console), zephyr_cdc_acm_uart), "Console device is not ACM CDC UART device");
an have it defined in overlay. As I have a simplified version of current device that is on 2.6 and USB, "just works". I can printk to it. 

[Vidar Berg]

I suggest you try to debug your application in VS code and see if the program hangs in the bootloader or application. Does your custom board have the exact same QSPI FLASH IC as the DK? MCUBoot will not boot the application if communication with the external flash fails (current configuration has the secondary mcuboot slot in placed in this flash).