STM32F and STARTUP_FROM_RESET
I'm hoping someone has a `best practices' for this.
I programmed an STM32F `Flash Release' to check a timing concern and have discovered that I have set STARTUP_FROM_RESET and cannot regain control of the CPU via JTAG, as warned in the STM32F10s_Startup.s. (This project was derived from another, so that may well not be a Crossworks setting).
I think I can get back control by setting the boot0/boot1 pins to system_memory, reflashing, then setting the boot pins back to flash, but as I don't have a switch this presently will mean soldering wires to the pins on the pack, which is not exectly ideal.
Am I right that this is the only way to regain control? I guess I'll soon know if it works, at least.
Is there a better/best way to handle this? Maybe it always need a switch or jumper?
Thanks.
-
With the board as originally built, with boot0 to 0V via 10k and boot1 open, I could debug fine via the JTAG port.
I then selected build "Thumb Flash Release" to check something.
I then reverted to "Thumb Flash Debug" but the load fails to verify Loader_rpc.elf
I then short boot0 to +3V3 and it appears I can reprogram the chip, but my program will not run properly, it jumps to the bootloader somewhere within the CTL library.
I cut the short to +3V3 and again I can flash the chip and debug, though I may have to repower the board between each flashing.
That means I'm back working, but also suggests I must fit a switch or something to change boot modes.
It seems that if boot0 is low and the CPU has been programmed with STARTUP_FROM_RESET, then the CPU declines to allow the JTAG to reprogram it.
-
Once your JTAG is in charge to debug processor, you lose it only when JTAG peripheral in STM32 gets out of power, e.g. in low power modes.
The STARTUP_FROM_RESET does not provide any window to communicate with debugger. Without this definition you get the window at the beginning in which you get debugger in the communication with JTAG peripheral. This happens also if you run System Memory ROM code of STM32.
There is also another possiblity: to force JTAG peripheral to synchronize with CPU via "Attach debugger". As I told, this can be possible only when you are not in low power mode.
-
Crossworks says I have the latest CPU package:
STMicroelectronics STM32 CPU Support Package 2.10 Installed
STMicroelectronics STM32F10x CPU Support Package 1.11 Installed
STMicroelectronics STM32F10x Standard Peripherals Library Updates 1.1 InstalledI'll have a look around the reset script
I can connect to the CPU OK when it's in the verify will not work: I see the CPU description in the status bar. But the download process fails at verify of Loader_rpc.elf.
When I'd changed the boot0/boot1 settings, I tried the attach-debugger and then Break, which confirms the CPU is running the bootloader.
I just did the flash release again to try 'attach debugger' and it seems to do something, though I'm not sure what as the program appears it may be at HardFault, though it also appears like it may not be stopped. I'm a it puzzled by this and need to explore further.
-
Michael, can you provide the previous rev. of STM32_target.js so that we can compare the behavior or provide instructions on how to modify STM32_target.js to the previous method?
The debugger used to be able to break into the STM32 boot even when I used STARTUP_FROM_RESET but with STM32 CPU Support Package 2.10, it doesn't seem to be able to.
-
Michael, the STM32_Target-4662.js works on my target and I see it assert and deassert NSRST (just like it used to).
In reading through the ARM debug docs, doing the SYSRESETREQ should be fine.
I also verified that doing VECTRESET (instead of SYSRESETREQ) also works. Here is the reset function. My testing is limited to one board but I verified that this stopped the CPU from flash as well as RAM.
function Reset()
{
TargetInterface.pokeWord(0xE000EDF0, 0xA05F0003); // halt the CPU by setting C_HALT and C_DEBUGEN in DHCSR
TargetInterface.waitForDebugState(200);
var DBGMCU_IDCODE = TargetInterface.peekWord(0xE0042000);
TargetInterface.pokeWord(0xE000EDFC, 0x1); // set VC_CORERESET in DEMCR to halt the CPU on reset
switch (DBGMCU_IDCODE & 0xffff0fff)
{
case 0x410: // STM32F10xx8/STM32F10xxB Revision A devices
TargetInterface.pokeWord(0xE000ED0C, 0x05FA0001); // set VECTRESET in AIRCR
break;
default:
TargetInterface.pokeWord(0xE000ED0C, 0x05FA0001); // set VECTRESET in AIRCR to generate a reset
break;
}
TargetInterface.waitForDebugState(1000);
switch (DBGMCU_IDCODE & 0xfff)
{
case 0x411: // STM32F2xx
case 0x416: // STM32L
TargetInterface.pokeWord(0xE0042004, 1<<2|1<<1|1<<0); // enable low-power mode debugging
TargetInterface.pokeWord(0xE0042008, 1<<12|1<<11); // turn off WWDG and IWDG in debug mode
break;
default:
TargetInterface.pokeWord(0xE0042004, 1<<8|1<<9|1<<2|1<<1|1<<0); // turn off WWDG and IWDG in debug mode and enable low-power mode debugging
}
} -
Hi ,
I have same problem ,boot0 and boot1 pins connected to ground.
i switch boot0 from low to high logic it does something but still the debugger can not make single step etc.
The linker calc CRC and the application too,it seems that something wrong with the flash.
in other one board at list it work well.
in RAM DEBUG it work well without jtag i use SWD.
i try to copy the reset function and it fail at compiling.
PLS advise.
IF you have SKYPE PLS send me your address to talk.
Thank you.
Ilan MAZUZ
Please sign in to leave a comment.
Comments
10 comments