I am trying to solve an interrupt issue, i have STM32G4 series controller and it has in built SysTick timer and has Cortex-M4 CPU. I generated a very basic code using Cube Mx, the systick interrupt does not happen. I have generated a very similar code for other boards with other controller part numbers and did not face the issue of Systick Interrupt, so i am assuming that the software is not a problem. My question is the Systick timer is internal to the CPU does external connections influence the interrupt, i mean some mismatch in the capacitors connected to the micro controller pins etc? I can flash the code with debugger and code runs normally but without interrupts. Does changing a micro will help me, i am struggling hard to resolve the issue.

 

I am trying to solve an interrupt issue, i have STM32G4 series controller and it has in built SysTick timer and has Cortex-M4 CPU. I generated a very basic code using Cube Mx, the systick interrupt does not happen. I have generated a very similar code for other boards with other controller part numbers and did not face the issue of Systick Interrupt, so i am assuming that the software is not a problem. My question is the Systick timer is internal to the CPU does external connections influence the interrupt, i mean some mismatch in the capacitors connected to the micro controller pins etc? I can flash the code with debugger and code runs normally but without interrupts. Does changing a micro will help me, i am struggling hard to resolve the issue.

Paste your code into Copilot, explain to it what MCU you are using, I bet you it will explain what you're seeing.

Are you using a board? like a Nucleo or something? I've worked a lot on these boards (not professionally but I am a seasoned programmer).

 

How do you know it is not working?

Any example in the Datasheet that you could copy verbatim?

Using a PIC, more than 2 decades ago, I implemented a system clock based on a Timer.

To make sure it was actually working, I designated an IO pin to be set/reset when entering/leaving the ISR.

A scope allows to see the resulting pulse and measure its width. Been using this unchanged since then.

 

I have verified it is not working by placing a break point inside the interrupt and the program does it not there. I was able to resolve the issue by option bytes to be programmed to boot from Flash memory. I really do not understand the concept of booting from flash, ram etc, i have studied several times but really do not understand. Can someone explain what exactly is booting why do we require it?

 

I have verified it is not working by placing a break point inside the interrupt and the program does it not there.

Depending on how they are implemented, on many development platforms breakpoints may not always work inside an ISR due to the relative priorities of the ISR v the mechanism used to implement the breakpoint.

 

I have verified it is not working by placing a break point inside the interrupt and the program does it not there. I was able to resolve the issue by option bytes to be programmed to boot from Flash memory. I really do not understand the concept of booting from flash, ram etc, i have studied several times but really do not understand. Can someone explain what exactly is booting why do we require it?

Before explaining any of your additional questions:

In my post #3, have you read (and understood) what I did to verify that the interrupt works (4th sentence)?

Be ready to peek the pin with a scope (hope you have one) and you will see if it works (or not) out of any doubt.

No matter if you know PICs. Reading here below should show what I mentioned now, twice.

;009 ISR HIGH.ASM

;High priority interrupts service routine

;Interrupts desabled. STATUS, W & BSR saved automatically in the fast stack.
;------------------------------------------------------------------------------

PIN_DEBUG_HI ;DEBUG - set to show activity <--------------------Vihaan@123 - here!!
;------------------------------------------------------------------------------

;actual interrupts service code starts here

UPDATE_TIME_BASES
BSF TBASE_FAST_ELAP ;show "fast time base period elapsed"
DECFSZ CNTR_TBASE_SLOW ;decrement the slow time base counter
BRA TBASES_UPDATE_DONE ;not =0 yet - period not elapsed - leave!

LOADREG CNTR_TBASE_SLOW,COUNT_TBASE_SLOW
;slow timebase period = (period of fast timebase * COUNT_TBASE_SLOW)

BSF TBASE_SLOW_ELAP ;=1 show "slow time base period elapsed"

TBASES_UPDATE_DONE
BCF PIR1,TMR2IF ;=0 clears TMR2 flag prior returning

;actual interrup service code ends here
;------------------------------------------------------------------------------

PIN_DEBUG_LO ;DEBUG - reset to show activity <--------------------Vihaan@123 - here!!
;------------------------------------------------------------------------------

;STATUS, W & BSR ARE retrieved from the fast stack.
RETFIE FAST ;Back to main line code - interrupts enabled.

 

Thank you for clarifying, now i understand what you are saying, i will toggle a port to confirm.

 

Yes i could see the toggling of the port inside the ISR, i could not copy the image from the scope.

 

Just increment a static counter integer inside your handler, let it run then in debug stop execution, that counter will tell if the handler is getting executed.