stbenn opened a new issue, #16416:
URL: https://github.com/apache/nuttx/issues/16416
### Description / Steps to reproduce the issue
I am running into issues when loading and debugging the basic H5 NSH
configuration when the flash banks are swapped on the Nucleo H563ZI. Has anyone
run into similar issues on this or other STM architectures?
This effectively prevents debugging on H5 MCUs where the bank swap option
bit is active. This could be a debugger issue, but it is occurring on both
JLink and STLink. So, I want to see if there is something wrong with the H5
architecture that could be causing this.
Board: Nucleo-H563ZI
Configuration: nucleo-h563zi:nsh
GCC: arm-none-eabi-gcc 13.3.1 20240614
Host OS: Ubuntu 24.04 container on Ubuntu 24.04 host (WSL2)
### Steps to reproduce
1. Connect device to STM32CubeProgrammer.
2. Mass erase flash memory for a clean slate.
3. Under Option bytes, select `SWAP_BANK` and hit Apply.
4. Reset the board by removing power and reconnecting. (Bank swap only takes
effect after reset)
5. In Nuttx: `./tools/configure.sh -l nucleo-h563zi:nsh`
6. Start programming and debugging. This will succeed and behave as expected.
7. Stop debug session.
8. Program and debug a second time. This will reach the beginning of
`__start()`, but fail after getting to code described below.
9. Only way to restore ability to debug: Connect to STM32CubeProgrammer and
mass erase flash. Can repeat steps 5-8, same thing will happen.
I have tried JLink + JLink server and STLink + OpenOCD (ST Fork), same thing
occurs in both.
Interestingly, if just resetting the device and letting it run instead of
program/debugging again after step 7, I get a nutshell and it seems to be
running properly.
**Also:** If I kill debugging when it reaches the beginning of `__start()`
in step 8, without continuing to debug. Then I reset the device and let it run
without the debugger, I get a nutshell and it seems to run properly. However,
as soon as I continue debugging after reaching the beginning of `__start()` the
2+ time loading/debugging, it will forever break even if resetting without
debugging. To recover from this, have to wipe flash memory.
### Where the issue occurs
I have narrowed down the issue to occurring in this step at the beginning of
`__start()`:
```c
for (src = (const uint32_t *)_eronly,
dest = (uint32_t *)_sdata; dest < (uint32_t *)_edata;
)
{
*dest++ = *src++;
}
```
Placing a breakpoint on `stm32_clockconfig()` (occurs immediately after the
for loop in question), the breakpoint will hit on the first time through but
will never hit the second time debugging.
Note: I went back a ways (all the way to 9078ffa4) to before this block was
moved to the top of `__start`. All code before it successfully executed,
including `stm32_clockconfig()`, but it fails immediately after this block just
as it does currently.
### Log files
[System.map](https://github.com/user-attachments/files/20352237/System_map.txt)
These debugger output logs are from the failing (second) attempt in the
steps described above.
[gdb-server.log](https://github.com/user-attachments/files/20352246/gdb-server.log)
[dbg_console.log](https://github.com/user-attachments/files/20352247/dbg_console.log)
### Notes
If there are any other things that I am missing that would help diagnose
this issue, please let me know and I will do my best to get those ASAP.
### On which OS does this issue occur?
[OS: Linux]
### What is the version of your OS?
Ubuntu 24.04
### NuttX Version
master
### Issue Architecture
[Arch: arm]
### Issue Area
[Area: Drivers]
### Host information
Output of `make host_info`:
[host_info.log](https://github.com/user-attachments/files/20352227/host_info.log)
### Verification
- [x] I have verified before submitting the report.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
