cancel
Showing results for 
Search instead for 
Did you mean: 

SOLVED: STM32H742: Whats wrong? ISR not triggered when using bootloader.

FSAT
Associate II

Hi,

I'm stuck at a problem when using a custom bootloader.

What works:

  • All ISRs get triggered when not using the bootloader
  • Almost (sic!) all ISRs get triggered when using bootloader together with my application

What doesn't work:

  • BMDA_Channel1_IRQHandler does not get triggered when using bootloader.

What I already analyzed (using JLink/GDB disassembly on the target):

  • BMDA_Channel1_IRQHandler lies at address 0x804feac, NVIC jump offset for this ISR is 0x248 according to datasheet
  • SCB->VTOR is 0x8040200
  • Address 0x8040448 contains 0x804fead (so everythings set up to jump to 0x804feac)
  • Address 0x804feac never gets triggered
  • Default_Handler lies at address 0x080745d4 (this is where my application gets stuck)
  • When stuck, APSR is 0, EPSR is 0 except Thumb bit, IPSR is 0x92 (that's BDMA_CH1...), SCB->ICSR->VECTACTIVE is 0x92, SCB->CFSR is 0, SCB->HFSR is 0

As far as I can see, the processor should jump to 0x804feac and execute my IRQHandler.

Any idea what's going wrong?

Thank you in advance!

1 ACCEPTED SOLUTION

Accepted Solutions

VTOR (and thus the vector table itself) must be aligned to the size of the vector table.

JW

View solution in original post

8 REPLIES 8

VTOR (and thus the vector table itself) must be aligned to the size of the vector table.

JW

If you __disable_irq() expect that to be what happens, the MCU doesn't magically re-enable them, you'd need code to explicitly do so..

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Watch also for RTOS user/system states (ie Thread vs Handler)

And transferring of control from an IRQHandler / Callback

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Thank, you, I double checked that. VTOR is 0x8040200 so the lower 8 bits are zero, thus the alignment should be right.

FSAT
Associate II

I'm sorry I realized that I didn't make too clear what exactly happens:

When the BMDA handler should trigger, the CPU instead jumps to the defaulthandler . This happens despite all registers and memory addresses I supposed to be involved seem to be all right.

Also, all other tested ISRs do work as expected.

To further clarify that, too: When not using a bootloader, of course I changed my linker files so that the application image does not start at 0x8040200 but instead starts at 0x8000000 and therefore of course in this case the VTOR is 0. When working in this mode, everything including BDMA handler works as expected.

Thank you, as far as I can see, IRQs are not disabled (also see my answer below) and the system state should be handler mode (IPSR is 0x92).

Is there anything else I should look at?

Pavel A.
Evangelist III

Please read again what Jan said above.

FSAT
Associate II

Thank you both very much, indeed I've overseen the link provided as I had read the ARM documentation on that topic.

It absolutely seems that was the problem. My VTOR is 0x8040200 (10th bit set) and the vector table position of BDMA_CH1 is 0x248 (10th bit set, too)

Now everything works :thumbs_up: