STM32G4 stuck on interrupt call

[Favand]

Hello everyone,

I’m currently working with an STSPIN32G4 MCU on a custom board.

Two version of this board exist: version A and version B.

When I upload the firmware to the MCU on board A everything works correctly. The exact same firmware on version B doesn’t work.

What happens:

1. Board B is powered on and the MCU is still fabric new (no firmware uploaded)
2. The custom fw is uploaded using the “Debug” feature of STM32CUBEIDE via JTAG
3. The code is executed succesfully by the MCU
4. Board B is powered off
5. After repowering on board B the issue starts to present: the firmware gets stuck as soon as any interrupt is called

Here’s an image of where the program points at when I press stop on the debugger after an interrupt call

What has already been tried:

1. Performing a full chip erase on the MCU and redownloading the firmware, but it still gets stuck on interrupt call
2. Removing the interrupt that was causing the firmware to get stuck (UART1 interrupt), but it still gets stuck as soon as TIM2 interrupt gets called
3. Removing all the interrupts and the firmware runs fine
4. Trying programming another board B, but the same issue is present
5. Comparing the OB of board B and board A and they are all the same. Both MCUs have boot mode set as software only, ignoring BOOT0’s pin value 

   

    

6. Verifying the stability of the power supply on board B
7. Veryfing the correct frequency of the external crystal resonator

[Ozone]

I think there is too little context to identify the issue immediately, but the crucial interrupt handler code is missing.

Have you checked you handled all interrupt causes, including (UART) error interrupts. TxE and RxNE are cleared with accessing TDR, but other flags (like error interrupt flags) must be reset explicitely. Otherwise the core will immediately reenter the handler.

Second, make sure no other interrupt takes precedence and causes “overflows” in the UART handler.

Your image suggests the TxE interrupt is responsible for this effect.
I hope you are aware that you need to disable the TxE interrupt when writing the last byte of a “string” to TDR.
I use to do that in the TxE section of the handler itself, directly before writing this last byte.

[db16122]

It seems version A and version B is same with same hardware as well as MCU. So how does the version B come from, Any reason to use version B instead of version A? Look confused about the custom board design idea...

[Andrew Neil]

Two version of this board exist: version A and version B.

So what are the differences between the two versions?

Are they just different instances of the same design, or different iterations of the design?

Add instrumentation to your code to see what's happening in each case - and where they differ

 

As ​@Ozone said, more details required:

 

[waclawek.jan]

Without trying to understand the description you’ve provided, the 0x1fffXXXX address means, that you most probably have VTOR=0 and the boot memory mapped for whatever reason (boot pin floating?) at address 0.

JW