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.
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.
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.
/* 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
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.