Hello,
I've a "follow up" issue related to this ticket: BL653 crashes when working with CONFIG_MCUMGR_SMP_BT & CONFIG_ESB
In an earlier state of our project, we've adopted the smp_svr application as our "DFU".
But during maturation of our project, we developed our own DFU.
Now, it happens that we have ~40 assembled units running smp_svr and we would like to switch by our DFU.
I perform the following steps:
1. Upload my new DFU image to the device OTA and switch slots (permanent)
Result: Works!
2. Now I upload our application (regular application)
Result: Works!
3. Now I click on "Confirm" and switch slots 1 to 0
I: Swap type: none
writing swap_info; fa_id=5 off=0x39fd8 (0x7ffd8), swap_type=0x3 image_num=0x0func img_mgmt_state_read
func img_mgmt_state_flags, 0
func img_mgmt_impl_swap_type, 0
I: Swap type: perm
func img_mgmt_state_flags, 1
func img_mgmt_impl_swap_type, 0
I: Swap type: perm
Result: Works!
4. I reset my device and expect the Mcuboot to switch the image slots (to run my application)
*** Booting Zephyr OS build v2.7.99-ncs1-1 ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x3, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
I: Jumping to the first image slot
Result: it still runs my DFU application instead of my regular application 
What could lead to such behavior? Any ideas on how to debug this?
Disclaimer: in case I flash my DFU Application first, I'm able to run my application, rollback to DFU, upgrade my application image as much as I want. It seems like the smp_svr puts my device's flash in an invalid state (in the slot it use to be).
