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

[KnarfB]

You say the debugger crashes. Do you get any useful message from it?

In the Debug Config Debugger tab you can set the ST-LINK freq. Try setting to a low value to compensate for possibly weak ST-LINK connection. There is also a Misc/Log to file checkbox which you might check.

hth

KnarfB

[KiptonM]

So I still do not know why when it calls this interrupt the debugger crashes. I was guessing the vector was wrong, but it appears correct.

I have a breakpoint for the first instruction in the ISR. It never breaks. The debugger just stops about 1 ms after we initialize the SysTick. That is what made me think it was a vector error. But everything looks good.

So I am back to not having a clue as to why it is no longer working. It has been working for more than 6 months, After I upgraded to the new version of IDE and MX it stopped working.

[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.

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

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.