Problems with SPI Tx DMA transfer interrupt when code is located in other place than 0x08000000

[Uhv]

Hello.

I work with STM32L433CC and have the own bootloader that is placed at 0x08000000. It starts and jumps to 0x08002000. There is the main application.

It seems that the application works proper. UART Tx with DMA works fine, UART Tx with DMA too and SPI Rx with DMA works proper. But one interrupt makes MCU frozen: SPI Tx with DMA. It's very strange: why do all interrupts work fine but one does not?

When I put the code in 0x08000000 it works fine. All interrupts work proper.

I use SW4STM32.

In STM32L433CCTx_FLASH.ld I have changed to:

/* Specify the memory areas */
 MEMORY
 {
 RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 64K
 FLASH (rx) : ORIGIN = 0x8002000, LENGTH = 248K
 } 

In system_stm32l4xx.c I have changed to:

#define VECT_TAB_OFFSET 0x2000 /*!< Vector Table base offset field.
 This value must be a multiple of 0x200. */

In Run Configuration Menu at Startup Page I have changed the executable offset to 2000.

It seems that I have done everything correctly. But the shifted code doesn't work properly. Why? Where must I search a problem?

[waclawek.jan]

> bootloader [...] jumps to 0x08002000

And does it change SCB_VTOR accordingly?

JW

[Uhv]

No. It is changed in the main application by the function SystemInit():

SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */

Is that not the same thing?

[Jack Peacock_2]

Did you check the second vector table in your application to see it has the correct entries for the SPI port and DMA? Check the table entries with the debugger to make sure the addresses are correct.

You didn't describe the error. Are you sure it isn't something related to the interrupt handlers? Try putting breakpoints at the start of both the DMA and SPI IRQ service routines.

Jack Peacock

[Uhv]

Thanks, Jack, for your answer.

The problem was fixed.

Really it was in IRQ handlers. There wasn't the global SPI interrupt handler. When I have set the check mark "SPI1 Global Interrupt " on NVIC setting page in CubeMX the problem went away.

Why had not the global SPI interrupt arisen earlier I don't know...

The code offset was not a reason of the bug.

Maybe it will help somebody to catch the hard fault:

https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html