The VTOR remapping crashes the scheduler start

Gooe morning… Using the kinetis K64 I need to move the vector table at start up The code
if (__VECTOR_RAM != __VECTOR_TABLE)
{   
    /* Copy the vector table from ROM to RAM */
    SCB->VTOR = (uint32_t)__VECTOR_RAM;
            for (int idx = FSL_FEATURE_INTERRUPT_IRQ_MIN; idx < (int32_t)tlen && ( idx <= (int32_t)FSL_FEATURE_INTERRUPT_IRQ_MAX ); idx++)
    {
       // __VECTOR_RAM[idx + 16] =  (uint32_t)FlashInterruptVector[idx + 16];
       INT_SYS_InstallHandler( (IRQn_Type)idx, FlashInterruptVector[ idx + 16 ] );
    }

    /* Point the VTOR to the position of vector table */
    SCB->VTOR = (uint32_t)__VECTOR_RAM;
}
else
{
    /* Point the VTOR to the position of vector table */
    SCB->VTOR = (uint32_t)__VECTOR_TABLE;
}
if I execute it the scheduler start is tracing the hardfault exception then reset. It I don’t execute the previous code the kernel starts to execute correctly. But I need this code.. Suggestion needed Thank You Pietro

The VTOR remapping crashes the scheduler start

I attach a test project with KDS… I need to know what is happening. Thank You

The VTOR remapping crashes the scheduler start

Do you have the FreeRTOS interrupt handlers installed in the vector table you are switching to? Is this a FreeRTOS issue? Or a chip bring up issue?
if I execute it the scheduler start is tracing the hardfault exception then reset.
Sorry – I don’t understand that sentence.

The VTOR remapping crashes the scheduler start

Thank You for assistance. I need to add the FreeRTOS to restructure an existing project. The vector table is dynamic, I need to install vectors run time. For this reason I move the VTOR pointer. In the sample application I copy the flash vector table area to the new ram area, then I assign the pointer to that ram area. It should work properly since the full vector table is the same. I checked with the debugger the result of the copy. It appears in order. But the start of the scheduler produces the crash. If the VTOR is unchanged the scheduler starts normally. The full example is coming from a wizard offerred for the KDS. I just added the copy of the vector table and VTOR assignment. The configuration is the default offered, Thank You…

The VTOR remapping crashes the scheduler start

How are other KDS examples doing this? Why INTSYSInstallHandler and not just memcpy from flash to ram? Is “__VECTOR_RAM” aligned? Is the vector installed using a direct jump instruction that is too far away after the vector table is moved?

The VTOR remapping crashes the scheduler start

Thank You.. In the attached picture, the situation is presented. The execution reaches the prvPortStartFirstTask and crashes executing the svc 0. The memory dump shows the vector table at address 0x1fff0000, the very beinning of the RAM area. at the offset 11 the address is 0x00008829, meaning the beginning is 0x00008828. The disassembly window on the right side is showing the SVC_Handler at the right address. It is never reached. The Hard Fault handler is regularly reached… I don t see a problem of jumps.. The examples work until the vector table is in flash, when remapped the crash is incoming… It is a desperation… Thank You….

The VTOR remapping crashes the scheduler start

Can you past the code that defined defines the vector table so we can see if it is using direct or indirect jumps. If it is using direct jumps then that is probably your issue. [This is not actually a FreeRTOS question]

The VTOR remapping crashes the scheduler start

Good morning If I am abusing the terms of assistance I will give up. The pointers to the service functions are written in the startup file startupMK64F12.s. The vector table is placed at the VECTORRAM address defined in the linker file MK64FN1M0xxx12flashflashloader.ld. All of them are copied from the flash default address (0) to the VECTOR_RAM (0x1fff0000) then the VTOR is reassigned. I am not aware of the near of far pointer for the CORTEX M. The remapping of the vector table has always worked. Thank You…. Pietro

The VTOR remapping crashes the scheduler start

Thanks for the linker script – but I want to see the actual source code that populates the vector table. This is most likely assembly code that has a sequence of jumps to functions, one for each vector.

The VTOR remapping crashes the scheduler start

Hi Pietro, first I thought that had the interrupts wrong (e.g. setting the SVCall interrupt priority in a wrong way, that’s a common cause of hard faults on M4 (see https://mcuoneclipse.com/2016/08/14/arm-cortex-m-interrupts-and-freertos-part-1/). Then I thought that you have running into the problem because you don’t have the vector table in RAM aligned at 0x400 boundary because you did not had the needed alignment in the linker file, so I recommend that you add this: .interrupts : { . = ALIGN(0x400); VECTOR_RAM = .; By chance (?), your vector table is at 0x1fff0000 so that did not violate the problem. The real problem in your init_vtor() function is that do not initialize the two first entries (initial PC and SP) of your vector table in RAM (they are initialized to zero) If you don’t have them set, you don’t have a legal vector table. I have fixed that as below (using the values from the flash vector table: /* Copy the vector table from ROM to RAM */ // SCB->VTOR = (uint32_t)__VECTOR_RAM; __VECTOR_RAM[0] = p_def[0]; /* initial SP */ __VECTOR_RAM[1] = p_def[1]; /* initial PC */ that way your code runs. Bottom line is you need to configure the full vector table, not only part of it. And the ARM vector table includes the reset vector plus the initial stack pointer. I hope this helps? Erich

The VTOR remapping crashes the scheduler start

Hi Erich,, It works. I am very happy now. Thank You all for the assistance. Effectively It is not clear to me why the first two vectors are needed run time. In my picture the processor reads at reset and never more. I think it is better to post a question on the Kinetis forum support, My best thanks for You all.. Pietro