Device: STM32U5A9-DK
Bootloader AN: AN2606
Reference Manual: RM0456
I was trying to enter the system bootloader (UART mode) through programming the NBOOT0 and NSWBOOT0 bit which is present in the FLASH_OPTR register of the option byte region.
Now, this writing to the option byte through the application code worked just fine. And we successfully entered the bootloader from the application.
However I had to get out of the bootloader and enter the application. For this we need to put the NBOOT0 and NSWBOOT0 bit back to its original state to boot to the application since the Go command will only get acknowledged depending on the NBOOT0 and NSWBOOT0 bit.
While trying to execute the above, i.e. re-writing the option byte (FLASH_OPTR register), by using the "Write" command of the bootloader, it messed up the other option bytes as well. Two of them being the registers NSBOOTADD0 and NSBOOTADD1 that contain the system bootloader starting address and the application starting address as well. Therefore, the device cannot boot neither to the bootloader nor the application.
This resulted in the device being on constant reset or whatsoever I am unable to connect to the device, and seeing the error "DEV_TARGET_HELD_UNDER_RESET".
I believe I will be able to connect to the device with the ST-link in SWD mode, even there I cannot connect to the device anymore and program normally. Thus resulted into a bricked device kind of scenario.
Interestingly I see whenever I try to connect to the device using the STM Cube programmer, in the console I see uploading option bytes, So I believe that the correct option byte will be written once I am able to connect to the device. Currently I am getting this error since the device is not able to connect.
I tried various ways to somehow connect the device with the st-link like even selecting the connection mode as "under reset", "hot plug", but I am not able to connect it anyway.
Please help me in this scenario what can be done to get my device back alive and hence the peripheral rich devboard back.
Hi @Deblina
Just to understand correctly the issue, NSBOOTADD0 and NSBOOTADD1 contains messed up addresses when programming NBOOT0 and NSWBOOT0 Option Bytes. According to the the snapshot below, which of the 2 highlighted lines correspond to your chip configuration ?
Best Regards,
Younes
