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]

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]

The debugger stops responding. It will not let me do a reset. I have to Terminate the debug session. And then restart to start over. When it stops I cannot look at any variables either. I can press the suspend button.and the resume button lights up, but the reset button does not work.

The clock on the debugger was on Auto which I am guessing was 24000, I tried 21000 no difference. I tried 8000 kHz but the console says SWD freq is 4000 kHz. Still does not work.

Tried 1000 said 959 kHz No difference.

Tried 140 said 125 kHz No difference.

I have the log but I do not know what I am looking for. It is attached. It ran to the first breakpoint, then it stopped before the second breakpoint. Finally I had to terminate the debug session because it would not do anything,

[Piranha]

Do a mass erase, reset option bytes, reset backup domain. Maybe some watchdogs running? Step into/through HAL_Init() and all the code - check everything it does.

P.S. A million problems later... Still don't believe that HAL/Cube code is a broken bloatware, written by incompetent fools and is the opposite of being productive? ;)

[KiptonM]

I am not a big fan of ST HAL or Microchip's version either. They are both bloated. They are not well documented, and yes they have known bugs that are not documented. I do not know how many times I have reported an error and have been told that is a known error. It may have taken me a couple of days to narrow it down to exactly the issue, only to find out that it is known but not shared outside ST Employees.

When it does work it helps make writing code faster if you do not care about speed or how much memory it uses. Coming from the 8-bit world, then the 16-bit world, I cringe when I see Interrupt Service Routines calling other functions. I have always tried to make every interrupt as fast and as short as possible because when a bunch of interrupts start going, the shorter and the faster they are the better. I never call another subroutine from from my ISR. Just too many issues with reentry and volatile values, etc. But with the HAL it is just the normal way of doing things. It really annoys me when the HAL calls a LL with almost the same name to do the same function, but just adds another call overhead.

I am sure that is what they are teaching in Computer Science these days, but I am old school where cycles was important because the processors ran at 1 MHz and took multiple clocks per assembly instruction. The 8051 took 12 clocks for most instructions, and a few instructions were 2x or 3x that, I started programming with Fortran in 1973, 49 years ago...

So the HAL is taking some getting used to for me. And it is very annoying when it does not work, or used to work, but now it does not.

[Piranha]

> When it does work it helps make writing code faster if you do not care about speed or how much memory it uses.

You are ignoring the most important one - reliability. Almost everything in HAL/Cube code is broken and will not be fixed in a foreseeable future, because the team is incompetent and ST's management doesn't care.

Have you fixed the broken HAL lock mechanism, which is present in almost all peripheral drivers? ;)

https://community.st.com/s/question/0D50X0000C5Tns8SQC/bug-stm32-hal-driver-lock-mechanism-is-not-interrupt-safe

Calling functions from an ISR is normal for these systems. The trick is to be careful which functions can be called and which cannot. Most of the LL "functions" are defined as static inline in header files and are inlined by compiler.

Clock cycles, memory and generally sane code are still important. The difference is, for example, why the MCU pulls off the wire speed of Ethernet easily for me, while the HAL/Cube clickers are spending years in a "something doesn't work" state and most of them never solve it anyway. And those, for whom it "works", get a slow and unreliable junk, which breaks randomly.

[waclawek.jan]

Where does stack pointer point?

JW

[KiptonM]

Good question. I have never had to check the stack pointer. I may take some time for me to figure out what it is doing versus what it should be doing.

[KiptonM]

The stack appears to be O.K. It starts at 0x20004800

Then we we get into main() it goes to 0x20004780

When it is in HAL_Init() it goes to 0x20004778

When it is in HAL_InitTick it goes to 0x20004770

because SysTick_Config() is inline, it stays at 0x20004770

When it went into HAL_NVIC_SetPriority it went to 0x20004760

Came back to HAL_InitTick and it is at 0x20004770

came back to HAL_Init() and is at 0x20004778

Then goes into HAL_MspInit(); and stack is at 0x20004770

Returns to HAL_Init() and it is at 0x20004778

returns to main() and the stack is at 0x20004780

And it stays there until it crashes. It does not look like anything is wrong with the stack.

I am beginning to lean towards the debugger. I do not see anything wrong with the code.

[waclawek.jan]

What does the debugger say, stopping at beginning of main(), in processor registers window, what is in SP (=R13)?

What is content of 0x0800'0000?

JW

[KiptonM]

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]

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]

> 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]

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

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\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

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

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 it did not change.

But the programmer says it did.

 

[KiptonM]

Here is the log file attached.