Did ST break SysTick in the last update? It used to work. Now it crashes because I think the interrupt vector is not set. Is this one of those known errors? How do I fix it?

KiptonM · ‎2022-07-18

When the SysTick interrupt fires the debugger quits.

I cannot figure out where the NVIC_SetVector statement is for the SysTick. I think it is not set. But I can not find the vector table in the debugger to know for sure.

This used to work, But when I updated to the 1.10.1 IDE and 6.6.1-RC2 Build.20220706-1420. It crashes when the systick interrupt happens.

I am using the STM32G051K8T

KiptonM · ‎2022-07-19

I started looking at the debugger console closer.

 
STMicroelectronics ST-LINK GDB server. Version 7.0.0
Copyright (c) 2022, STMicroelectronics. All rights reserved.
 
Starting server with the following options:
        Persistent Mode            : Disabled
        LogFile Name               : C:\Users\Moravec-Kipton.DOMNDTX\STM32CubeIDE\workspace_1.9.0\EncoderBoardRevA\Debug\st-link_gdbserver_log.txt
        Logging Level              : 31
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Enabled
        SWD Debug                  : Enabled
        InitWhile                  : Enabled
 
COM frequency = 4000 kHz
Target connection mode: Under reset
Reading ROM table for AP 0 @0xf0000fd0
Hardware watchpoint supported by the target 
ST-LINK Firmware version : V2J40S7
Device ID: 0x456
PC: 0x1fff1654
ST-LINK device status: HALT_MODE
ST-LINK detects target voltage = 3.00 V
ST-LINK device status: HALT_MODE
ST-LINK device initialization OK
Stm32Device, pollAndNotify running...
SwvSrv state change: 0 -> 1
Waiting for connection on port 61235...
Waiting for debugger connection...
Waiting for connection on port 61234...
Accepted connection on port 61234...
Debugger connected
Waiting for debugger connection...
Waiting for connection on port 61234...
GDB session thread running
GdbSessionManager, session started: 1
Accepted connection on port 61234...
Debugger connected
Waiting for debugger connection...
Waiting for connection on port 61234...
GDB session thread running
GdbSessionManager, session started: 2
Stm32Device, closeDevice() entry
GDB session, device event: 5
GDB session, device event: 5
Stm32Device, pollAndNotify stopped
Stm32Device, closeDevice() exit
 ------ Switching to STM32CubeProgrammer ----- 
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.11.0                  
      -------------------------------------------------------------------
 
 
 
Log output file:   C:\Users\MORAVE~1.DOM\AppData\Local\Temp\STM32CubeProgrammer_a05748.log
ST-LINK SN  : 293202063415303030303032
ST-LINK FW  : V2J40S7
Board       : --
Voltage     : 3.05V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x456
Revision ID : Rev A
Device name : STM32G051/STM32G061
Flash size  : 64 KBytes
Device type : MCU
Device CPU  : Cortex-M0+
BL Version  : --
 
 
 
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a05748.srec
  File          : ST-LINK_GDB_server_a05748.srec
  Size          : 44.11 KB 
  Address       : 0x08000000 
 
 
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 22]
Download in Progress:
�������������������������������������������������� 0%
�������������� 28%�������������� 56%�������������� 85%�������� 100%
 
File download complete
Time elapsed during download operation: 00:00:01.259
 
 
 
Verifying ...
 
 
Read progress:
�������������������������������������������������� 50%
�������������������������������������������������� 100%
 
Download verified successfully 
 
 
 ------ Switching context ----- 
COM frequency = 4000 kHz
Target connection mode: Under reset
Reading ROM table for AP 0 @0xf0000fd0
Hardware watchpoint supported by the target 
ST-LINK Firmware version : V2J40S7
Device ID: 0x456
PC: 0x1fff1654
ST-LINK detects target voltage = 3.00 V
ST-LINK device status: HALT_MODE
GDB session, device event: 6
GDB session, device event: 6
Stm32Device, pollAndNotify running...
GDB session, device event: 3
GDB session, device event: 3
GDB session, device event: 1
GDB session, device event: 1
GDB session, device event: 0
GDB session, device event: 0
NVIC_DFSR_REG = 0x0000000B 
GDB session, device event: 3
GDB session, device event: 3
GDB session, device event: 1
GDB session, device event: 1
GDB session, device event: 0
GDB session, device event: 0
NVIC_DFSR_REG = 0x00000002 
GDB session, device event: 3
GDB session, device event: 3
GDB session, device event: 1
GDB session, device event: 1
GDB session, device event: 0
GDB session, device event: 0
NVIC_DFSR_REG = 0x00000001 
GDB session, device event: 3
GDB session, device event: 3
GDB session, device event: 1
GDB session, device event: 1
ST-LINK device status: RESET_MODE
ST-LINK device status: RUN_MODE

It looks like when it calls the interrupt it goes into RESET_MODE then switches to RUN_MODE and the Debugger is no longer responsive. I cannot step. I cannot reset. I cannot look at any variables. All I can do is Terminate.

I have to terminate to restart the debugger.

KiptonM · ‎2022-07-19

I do not see the line "stopping at beginning of main()" But that is what the debugger does. It stops at the beginning of main and waits for a command to resume or single step or whatever you want.

KnarfB · ‎2022-07-19

Your debugger log says:

------ Switching context -----

...

PC: 0x1fff1654

This is not a flash but a system memory address. Looks like the MCU does not boot from flash. Check boot mode/pin settings.

hth

KnarfB

waclawek.jan · ‎2022-07-19

> PC: 0x1fff1654

Nice catch.

Humm, maybe the Pattern 6 / Pattern 11 / PEMPTY (in 'G0 called EMPTY, to increase confusion) problem again? That may be exacerbated by the debugger change.

Quoting from linked post:

Tip: On devices with nSWBOOT0 or nBOOT_SEL option bit (STM32WB, STM32L4, STM32G0) it is possible to force boot from Main flash by using nBOOT0 option bit instead of BOOT0 pin.

This can be achieved by following Option byte configuration

nSWBOOT0 or nBOOT_SEL = 1 (BOOT0 signal is defined by nBOOT0 option bit)

nBOOT0 = 1

JW

KiptonM · ‎2022-07-19

It looks like

nBOOT_SEL was checked which meant BOOT0 signal is defined by the nBOOT0 option bit"

nBOOT1 was checked which meant Boot from Flash if nBOOT0 = 0, otherwise from system memory

nBOOT0 was checked nBOOT0 = 1

This caused it ti boot from system memory.,

I changed nBOOT0 to unchecked where nBOOT0 = 0

So that should have fixed it and cause it to boot from Flash. I am still having the same problem.

I wondered if it was an issue with the project getting upgraded from 1.9.0 to 1.10.1 so I made a brand new project and it has the same problem.

STMicroelectronics ST-LINK GDB server. Version 7.0.0

Starting server with the following options:

Persistent Mode : Disabled

LogFile Name : C:\Users\Moravec-Kipton.DOMNDTX\STM32CubeIDE\workspace_1.9.0\test1\Debug\st-link_gdbserver_log.txt

Logging Level : 31

Listen Port Number : 61234

Status Refresh Delay : 15s

Verbose Mode : Enabled

SWD Debug : Enabled

InitWhile : Enabled

COM frequency = 4000 kHz

Target connection mode: Under reset

Reading ROM table for AP 0 @0xf0000fd0

Hardware watchpoint supported by the target

ST-LINK Firmware version : V2J40S7

Device ID: 0x456

PC: 0x1fff1654

ST-LINK device status: HALT_MODE

ST-LINK detects target voltage = 3.00 V

ST-LINK device status: HALT_MODE

ST-LINK device initialization OK

Stm32Device, pollAndNotify running...

SwvSrv state change: 0 -> 1

Waiting for connection on port 61235...

Waiting for debugger connection...

Waiting for connection on port 61234...

Accepted connection on port 61234...

Debugger connected

Waiting for debugger connection...

Waiting for connection on port 61234...

GDB session thread running

GdbSessionManager, session started: 1

Accepted connection on port 61234...

Debugger connected

Waiting for debugger connection...

Waiting for connection on port 61234...

GDB session thread running

GdbSessionManager, session started: 2

Stm32Device, closeDevice() entry

GDB session, device event: 5

Stm32Device, pollAndNotify stopped

Stm32Device, closeDevice() exit

------ Switching to STM32CubeProgrammer -----

-------------------------------------------------------------------

STM32CubeProgrammer v2.11.0

-------------------------------------------------------------------

Log output file: C:\Users\MORAVE~1.DOM\AppData\Local\Temp\STM32CubeProgrammer_a01776.log

ST-LINK SN : 293202063415303030303032

ST-LINK FW : V2J40S7

Board : --

Voltage : 3.05V

SWD freq : 4000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Device ID : 0x456

Revision ID : Rev A

Device name : STM32G051/STM32G061

Flash size : 64 KBytes

Device type : MCU

Device CPU : Cortex-M0+

BL Version : --

Memory Programming ...

Opening and parsing file: ST-LINK_GDB_server_a01776.srec

File : ST-LINK_GDB_server_a01776.srec

Size : 4.38 KB

Address : 0x08000000

Erasing memory corresponding to segment 0:

Erasing internal memory sectors [0 2]

Download in Progress:

�� 0%

�� 100%

File download complete

Time elapsed during download operation: 00:00:00.234

Verifying ...

Read progress:

�� 50%

�� 100%

Download verified successfully

------ Switching context -----

COM frequency = 4000 kHz

Target connection mode: Under reset

Reading ROM table for AP 0 @0xf0000fd0

Hardware watchpoint supported by the target

ST-LINK Firmware version : V2J40S7

Device ID: 0x456

PC: 0x1fff1654

ST-LINK detects target voltage = 3.00 V

ST-LINK device status: HALT_MODE

GDB session, device event: 6

Stm32Device, pollAndNotify running...

GDB session, device event: 3

GDB session, device event: 1

GDB session, device event: 0

NVIC_DFSR_REG = 0x0000000B

GDB session, device event: 3

GDB session, device event: 1

GDB session, device event: 0

NVIC_DFSR_REG = 0x00000002

GDB session, device event: 3

GDB session, device event: 1

GDB session, device event: 0

NVIC_DFSR_REG = 0x00000001

GDB session, device event: 3

GDB session, device event: 1

ST-LINK device status: RESET_MODE

ST-LINK device status: RUN_MODE

It looks like it did not change.

But the programmer says it did.

KiptonM · ‎2022-07-19

Here is the log file attached.

KiptonM · ‎2022-07-19

Could it be it booted into the system because I am running the debugger?

Piranha · ‎2022-07-19

That CubeProgrammer description of nBOOT0 and nBOOT1 options is a nonsense. Again a blind trust without checking the real thing - reference manual...

Look at the RM0444 Rev 5, 2.5 Boot configuration, Table 8. Boot modes.

@Houda GHABRI

KiptonM · ‎2022-07-20

Thanks for the pointer. And yes I should be wary of ST software.

Looking at Table 8 the 4th line is a way to get to Main Flash Memory.

nBOOT_SEL bit needs to be 1

nBOOT0 bit needs to be 1

nBOOT1 bit does not matter

BOOT0 pin does not matter.

I thought that is what I started with before I started changing the fuses!

It must not have been, because the PC Changed and the test code works.

Download verified successfully

------ Switching context -----

COM frequency = 4000 kHz

Target connection mode: Under reset

Reading ROM table for AP 0 @0xf0000fd0

Hardware watchpoint supported by the target

ST-LINK Firmware version : V2J40S7

Device ID: 0x456

PC: 0x8000430

And it works on my code with all the setup files commented out

And it works on my full code.

Thanks everyone for the help. This one is solved.

KiptonM · ‎2022-07-20

I also have to thank KnarfB for the pointer to the fuses. I have no idea how they got changed. I had to load the programmer into my computer to change them. I looked at fuses a long time ago, but have not changed them in a long time.

Unfortunately I can only have 1 best answer. And that is the one that fixed the problem.