Setting VTOR in SystemInit may be undesirable

[Amomum]

In file CMSIS/CM3/DeviceSupport/MDR32F9Qx/startup/system_MDR32F9Qx.c at line 144:

/* Reset the RST clock configuration to the default reset state */
SCB->VTOR = 0x08000000;

Which can be seen as necessary as per datasheet:

Программное обеспечение в privileged режиме может перенести таблицу в другое место памяти через регистр VTOR. Таблица может располагаться в адресах от 0х00000080 до 0х3fffff80. Подробнее в описании регистра VTOR.

VTOR - значение после сброса 0x00000000

But I can see with my debugger that just after reset startup code from ROM (from address 0) executes and sets VTOR to 0x08000000. So modifying VTOR programmatically is unnecessary. But we should not rely on this behaviour since it's not even mentioned anywhere in datashet (as far as I know).

Setting VTOR programmatically to this value in SystemInit may be undesirable in two cases:

• When using Keil simulator, programmer have to set IROM1 region to 0, because simulator can not start from 0x08000000. If then VTOR is manually set to 0x08000000, no interrupts will work.
• When using custom bootloader which loads user code with some offset from the beginning of the flash memory. Before starting user firmware bootloader will modify VTOR accordingly. If user firmware then sets VTOR back, no interrupts will work correctly.

I propose to do something like this:

#ifndef MDR_DO_NOT_USE_DEFAULT_VTOR
  /* Reset the RST clock configuration to the default reset state */
  SCB->VTOR = 0x08000000;
#endif

so the end-user can disable this feature without modifying this code or manually resetting VTOR again in his main-code.

[in4lio]

Hello! -- I think that SystemInit() and some other procedures involved into MCU startup should be considered just as examples or templates that the developer will adapt to a particular project. This is a non-trivial task -- to write a startup code which will fit to every project.

[Amomum]

Hmm. I think that the best way to use a library is to include it 'as is', as submodule or a subtree or whatever. Then it can be updated with minimal effort.

I consider rewriting parts of the library after cloning absolutely unacceptable, using some files as templates is possible (although it will make updating them more difficult) but those files should be clearly marked as templates.

I suppose the best (or least worst) thing is to provide something close to absolutely necessary minimum SystemInit. And I think current version is pretty close to that. Maybe modifying VTOR can be removed altogether?

[in4lio]

I absolutely agree that the current structure of the library is far from ideal. As I see it, one of the goals of this particular library is to keep the full compatibility with the original. However, nothing hinders someone from refactoring of the library and creating another better organized one))

As for VTOR, let's wait for an answer of @eldarkg

[eldarkg]

@Amomum I think you should rename definition to MDR_NO_RST_VTOR. Can you open a pull request? P.S. I'll merge it because this VTOR reset breaks the Keil simulator work (as say @Amomum).