CORTEX_M4F_Infineon_XMC4000_GCC_Dave jumps from prvProcessTimerOrBlockTask Default_Handler

destiniy wrote on Thursday, September 15, 2016:

Hi,

I tried the CORTEX_M4F_Infineon_XMC4000_GCC_Dave example on a hexagon kit with xmc4500.

I use the newest version of dave 4.3.2. I updated the startup_xmc4500.s and startup_xmc4500.c and the linker file to the newest version.

Than I had to enable the compile option -mfloat-abi=softfp to compile the example.

When I tried to start the example it always crashes an goes from the prvProcessTimerOrBlockTask(…) fnuction to the defaultHandler

Wehre I have to search for the problem?

regards

rtel wrote on Thursday, September 15, 2016:

Changing the start up code may have caused an issue - potentially the
FreeRTOS interrupt handlers may not be installed. So the first thing to
do is determine which handler you are going to, as the default handler
will be install on most possible interrupt sources. If it is a hard
fault then we need to investigate further - but if it is a SysTick or
PendSV handler then it can probably be fixed by installing the
appropriate handlers in the vector table.

You can find information on determining which interrupt is executing on
the following page:
http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html

destiniy wrote on Thursday, September 15, 2016:

OK

my call Stack is here:

VADC0_G3_3_IRQHandler() at startup_XMC4500.s:350 0x80002b0
() at 0xfffffffd
prvPortStartFirstTask() at port.c:294 0x8000b08
xPortStartScheduler() at port.c:386 0x8000bf6
0x0

so I see the wrong handler is called. I thought the systick handler should be called.

destiniy wrote on Thursday, September 15, 2016:

OK the PendSV is not handled

What should I do?

rtel wrote on Thursday, September 15, 2016:

Look in the vector table. What is the PendSV called? If it is the
‘standard’ name of PendSV_Handler then you can add the following to
FreeRTOSConfig.h:

#define xPortPendSVHandler PendSV_Handler

otherwise update the vector table so xPortPendSVHandler is installed as
the PendSV handler.

As I recall some of the XMC parts have a silicon bug that needs
workarounds in the form of interrupt entry veneers - I don’t know if
that is still the case but can make the vector table definition more
complex than would otherwise be expected.

destiniy wrote on Thursday, September 15, 2016:

/* Definitions that map the FreeRTOS port interrupt handlers to their CMSIS
standard names. */
#if WORKAROUND_PMU_CM001 == 1
	#define xPortPendSVHandler PendSV_Handler_Veneer
#else
	#define xPortPendSVHandler PendSV_Handler
#endif

if I disable this flag it is running

so I have to look in the errata

destiniy wrote on Thursday, September 15, 2016:

Branch from non-cacheable to cacheable address space instruction
may corrupt the program execution

Workaround:
Allocate the complete code either in the cacheable or non-cacheable Flash
address space, do not use mixed code allocation. This workaround covers all
accesses out of the normal program flow.

I hope this is done by the new linker file

 } > FLASH_1_cached AT > FLASH_1_uncached

destiniy wrote on Thursday, September 15, 2016:

infineon has made a define for this

#if defined(ENABLE_PMU_CM_001_WORKAROUND)

its used in the linker file

I while change the define in the config.h file

destiniy wrote on Friday, September 16, 2016:

thanks for your quick help

in the AC revision of the xmc4500 chip the silicon bug is solved