FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [October 2016 Threads] The VTOR remapping crashes the scheduler startPosted by pietrodcs2 on October 12, 2016 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 startPosted by pietrodcs2 on October 12, 2016 I attach a test project with KDS... I need to know what is happening.
Thank You
The VTOR remapping crashes the scheduler startPosted by rtel on October 12, 2016 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 startPosted by pietrodcs2 on October 13, 2016 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 startPosted by edwards3 on October 13, 2016 How are other KDS examples doing this? Why INTSYSInstallHandler and not just memcpy from flash to ram? Is "_VECTORRAM" 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 startPosted by pietrodcs2 on October 13, 2016 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....
AttachmentsUntitled.png (185476 bytes)
The VTOR remapping crashes the scheduler startPosted by rtel on October 13, 2016 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 startPosted by pietrodcs2 on October 14, 2016 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 startPosted by rtel on October 14, 2016 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 startPosted by xz8987f on October 15, 2016 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 = (uint32t)__VECTORRAM;
_VECTORRAM[0] = p_def[0]; / initial SP /
_VECTORRAM[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 startPosted by pietrodcs2 on October 16, 2016 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
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|