Hi, I'm using the J-Link EDU and STLink debugger present on the Nucleo boards from ST. For testing, the bootloader code is present at 0x8000000 and just jumps to 0x8020000 where the main app code is present. When I use the Jlink EDU, it can't program the flash at 0x8020000 every time successfully and if i modify the program and start debugging, the Jlink erases the flash but does not program it successfully and after the bootloader makes the jump, the MCU gets HardFault. Now this happens whether I use Jlink or the STLINK (converted to Jlink). Usually I see it stuck at 0xFFFFFFFE. At that point the JLINK has erased the app code but failed to program it.
The interesting thing is that the STlink debugger when converted back and used with openocd has no issues whatsoever with the bootloader jumping to main app code and debugging from there.
I also find that if I program the main app code at 0x8020000 by STLink and OpenOCD and then switch to JLINK EDU for debug, it works as long as the JLINK does't reprogram it. If in the log, i see that the JLINK flashes the code, then the ST crashes after jumping from bootloader. So I definitely think it has something to do with how the JLINK is erasing and programming the ST during debug.
I also tried programming with JLINK commander and that seems to fail as well. Unless I fully erase the chip.
I'm using System Workbench 2.0 with GNU ARM Eclipse plugin for Jlink debugging with the latest ARM toolchain as of this date and Jlink 616c. I'm using the STM32F765VI with the flash in dual bank configuration.
I'm also attaching the GDB logs from JLINK and STLINK for clarity. I would like to use JLINK for debugging since I can have SWO console in eclipse whereas its very cumbersome in OpenOCD so would like to resolve it.
Thanks in advance!
The interesting thing is that the STlink debugger when converted back and used with openocd has no issues whatsoever with the bootloader jumping to main app code and debugging from there.
I also find that if I program the main app code at 0x8020000 by STLink and OpenOCD and then switch to JLINK EDU for debug, it works as long as the JLINK does't reprogram it. If in the log, i see that the JLINK flashes the code, then the ST crashes after jumping from bootloader. So I definitely think it has something to do with how the JLINK is erasing and programming the ST during debug.
I also tried programming with JLINK commander and that seems to fail as well. Unless I fully erase the chip.
I'm using System Workbench 2.0 with GNU ARM Eclipse plugin for Jlink debugging with the latest ARM toolchain as of this date and Jlink 616c. I'm using the STM32F765VI with the flash in dual bank configuration.
I'm also attaching the GDB logs from JLINK and STLINK for clarity. I would like to use JLINK for debugging since I can have SWO console in eclipse whereas its very cumbersome in OpenOCD so would like to resolve it.
Thanks in advance!