ISR with debugger doesn't work when N_RST not wired (SWD) on STM32F0

[ks156]

Hello,

I'm facing a problem that I can't explain. In most of my devices, the SWD connector is completely wired (ca. VCC/GND/SWDIO/SWCLK/NRST), and I never had any problem to debug those devices with SystemWorkbench and a STLINK-2 debugger.

One of my device doesn't have the NRST wired. So only SWDIO and SWCLK are connected to the MCU (STM32F051). When I use the debugger with it, the interrupts are not fired. The SysTick counter is not incremented at all, and so it is almost impossible to debug as I use HAL_Delay() (which relies on the SysTick) in my code. I've checked almost all the registers, and I didn't see anything special that could explain why the interrupts are not fired.

I wired the NRST line (it was not easy on a QFN chip with very short accessibles tracks), and the interrupts are fired in that case.

When NRST is not connected, I have to add "monitor halt;" during the initialization, otherwise it is not possible to flash the device. Software reset doesn't work neither, so I have to set the "Connect under reset" option. I don't know if "monitor halt" is the correct command in that case, but at least, I can flash and debug my code (without interrupts...).

If I remove the debugger and reset the MCU (by power cycling the power supply), interrupts works fine (I made a small code with HAL_Delay() to blink a LED).

I really don't understand why NRST change the interrupts behavior. I tried also on a Discovery board (STM32F0DISCO), and removed SB19 (NRST signal between CN3 and STM32F051R8), and I had the same problem.

My questions are :

1. Does someone can explain me this behavior difference ?

2. Does someone can tell me if it is possible to have the interruptions working without NRST line ?

Thank you in advance,

Paul

[Tesla DeLorean]

I don't understand it either.

Do you pull BOOT0 Low?

If the empty device boots into ROM, you'll need to recycle the power to recover the zero mapping unless you pro-actively address the problem.

Check which memory is mapped at ZERO, there isn't a SCB->VTOR register.

Add code in Reset_Handler to assure that FLASH is mapped into the zero address space.

[ks156]

Yes, BOOT0 is tied low with a pulldown resistor. Anyway, I also tried to pull BOOT0 up and change the option bytes, and the boot seems to do what's expected regarding the BOOT0 and option byte states. I don't think the problem is related to BOOT0.

I don't really understand what to do in the reset handler (I must admit that I never put my nose in the startup scripts, as they usually works out-of-the-box for me, and also because I don't like ASM). Could you give me more inputs on this point ?

[Tesla DeLorean]

Reset_Handler:
 ldr r0, =_estack
 mov sp, r0 /* set stack pointer */
 
/* Check if boot space corresponds to system memory */
 
 LDR R0,=0x00000004
 LDR R1, [R0]
 LSRS R1, R1, #24
 LDR R2,=0x1F
 CMP R1, R2
 BNE ApplicationStart
 
/* SYSCFG clock enable STM32F0 */
 LDR R0,=0x40021018 /* RCC_APB2ENR */
 LDR R1,=0x00000001 /* SYSCFGCOMPEN */
 STR R1, [R0]
 
/*Set CFGR1 register with flash memory remap at address 0*/
 LDR R0,=0x40010000 /* SYSCFG_CFGR1 */
 LDR R1,=0x00000000
 STR R1, [R0]
 
ApplicationStart:
...

[waclawek.jan]

Why couldn't the write to SYSCFG_CFGR1 be performed unconditionally?

JW

[waclawek.jan]

IMO this is toolchain-dependent (what's your toolchain?) and within toolchain, dependent on exact settings of which reset has to be used.

Maybe BOOT0 pin/ boot-related options settings are relevant, too. What is mapped to memory area at 0x00000000 when the problem occurs (SYSCFG_CFGR1.MEM_MODE)?

JW

[ks156]

Hello waclawek.jan,

I checked almost all the registers and compared when it works and when it doesn't work, and I didn't see any difference.

SYSCFG_CFGR1.MEM_MODE is 0 in both cases.

I notice that, when the debugger attach, when I don't have the reset pin attached, the PC value is on the application (so, it seems that there's no reset when the debugger attach). A stepi command will jump directly to the Reset_Handler.

I'm not sure that my 'monitor halt' command during the initialization is correct, but without this command, I always have the following errors :

Info : device id = 0x20006440
Info : flash size = 16kbytes
Error: Target not halted
Error: failed erasing sectors 0 to 9
Error: flash_erase returned -304

Is there another way to do it ?

[waclawek.jan]

As I've said, this might be a toolchain-dependent issue. Explore what options offered your toolchain for "debugging start" or "connect", e.g. "hot connect", connect with soft/system reset, hard reset, etc.

JW