STM32H753 BDMA SPI6 loop infinite

[HieuHa123]

Hi ST,

Currently, I'm testing the BDMA on SPI6 with the STM32H753. The SPI transmission works as expected when using the base flash address at 0x08000000. I need to place the application code at address 0x08100200. However, when I change the vector table offset and linker flash address to 0x08100200, the system enters an infinite loop whenever I transmit the buffer using BDMA SPI6

Please follow the test cases below for more details:

Procedure:

1. Create the STM32H753VITx project.

2. Change the vector offset and linker flash address to 0x08100200:

   - Vector table offset and linker file settings:

- linker flash address:

3. Specify the memory region SRAM_4 for the transmission buffer in the linker file.

.dma_buffer : /* Space before ':' is critical */
{
  *(.dma_buffer)
} >RAM_D3

4. In the main.c 

uint8_t buff[256] __attribute__((section(".dma_buffer")));

int main(void)

{

....

  HAL_SPI_Transmit_DMA(&hspi6, buff, sizeof(buff));

  uint32_t timeout = 200000;

  while (HAL_SPI_GetState(&hspi6) != HAL_SPI_STATE_READY)

  {

    if (timeout-- == 0)

      break;

  } 

while (1) {}

}

Results:

This issue only occurs when I change the address to 0x08100200, 0x08101200, or 0x08102200. I am also successful with the addresses 0x08100000, 0x08102000, and 0x08103000.

Is there any reason that could cause this failure?

[tjaekel]

I think, you should consider this:

• on power up (or HW reset) - the MCU starts ALWAYS at 0x08000000 for the vector table
• you can jump from Reset_Handler (entry address stored at 0x08000004) to your code
• your code can change the VTOR address and you can have (most of) your code at a different address
• but you would still need a jump in Reset_Handler to your real Reset_Handler (doing also this VTOR change) when all is linked to a different entry address

I think, the VTOR register is always reset with a power cycle (and maybe also with a HW reset). Not sure it VTOR register setting will "survive" a SW reset (forcing a reset via SW command).

Just "moving" the code to a different entry address (and also the start of the vector table) cannot work without to have a bit of code for the "original" Reset_Handler entry: when is the VTOR register changed? (just with the user code done). The VTOR register might be reset as well so that all starts again from 0x08000000.

Keep still a (simple) vector table at 0x08000000. Have a simple Reset_Handler there as entry address. Do minimal stuff, at least to move the vector table via VTOR register to a different entry address.

Bear in mind: the SP register is loaded from address location 0x08000000 (the SP top register address set). Even you move the vector table via VTOR register - the SP register not reloaded again (you might have a different SP top address in VECTOR_TABLE + 0 stored).

I would assume: when you build an image with a different entry address - and the VTOR register is not yet moved as well (it cannot without any code) - you get a "strange" code execution after power-up and maybe luckily the code hits your real code.

Just think about how the MCU would boot and when the VTOR register can be effective. Just changing the base address of your "image" (code) cannot work - without still having a "bootstrap" Reset_Handler on original 0x08000000 address (the first vector table must be still there on 0x08000000, later you can assign a new one).

[SofLit]

Hello,

I think Window Watchdog interrupt is firing.

Please add WWDG_IRQHandler() in stm32h7xx_it.c and check if you reach the while loop in the WWDG IRQ:

void WWDG_IRQHandler(void)
{
   while (1)
   {
   }
}

In that case did you enable the Window Watchdog in your code?

[waclawek.jan · Accepted solution]

 VTOR for this device must be aligned to 1024 bytes.

JW

[HieuHa123]

Thank you for getting back to me. I have changed the vector table offset to be a multiple of 1024, and it looks good to me.