Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

The VTOR remapping crashes the scheduler start

Posted 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 start

Posted by pietrodcs2 on October 12, 2016

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

Attachments

test.7z (383750 bytes)

The VTOR remapping crashes the scheduler start

Posted 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 start

Posted 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 start

Posted 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 start

Posted 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....

Attachments

Untitled.png (185476 bytes)

The VTOR remapping crashes the scheduler start

Posted 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 start

Posted 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

Attachments


The VTOR remapping crashes the scheduler start

Posted 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 start

Posted 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 start

Posted 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


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists