Hi,

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

I use the newest version of dave 4.3.2. I updated the startupxmc4500.s and startupxmc4500.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

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

OK

my call Stack is here:

VADC0G33IRQHandler() at startupXMC4500.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.

OK the PendSV is not handled

What should I do?

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:

~~~

~~~

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.

~~~ /* Definitions that map the FreeRTOS port interrupt handlers to their CMSIS standard names. */

#define xPortPendSVHandler PendSV_Handler_Veneer

#define xPortPendSVHandler PendSV_Handler

~~~

if I disable this flag it is running

so I have to look in the errata

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

~~~ } > FLASH1cached AT > FLASH1uncached ~~~

infineon has made a define for this

~~~

~~~

its used in the linker file

I while change the define in the config.h file

thanks for your quick help

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