CORTEX_M4F_Infineon_XMC4000_GCC_Dave jumps from prvProcessTimerOrBlockTask Default_Handler

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

CORTEX_M4F_Infineon_XMC4000_GCC_Dave jumps from prvProcessTimerOrBlockTask Default_Handler

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

CORTEX_M4F_Infineon_XMC4000_GCC_Dave jumps from prvProcessTimerOrBlockTask Default_Handler

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.

CORTEX_M4F_Infineon_XMC4000_GCC_Dave jumps from prvProcessTimerOrBlockTask Default_Handler

OK the PendSV is not handled What should I do?

CORTEX_M4F_Infineon_XMC4000_GCC_Dave jumps from prvProcessTimerOrBlockTask Default_Handler

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.

CORTEX_M4F_Infineon_XMC4000_GCC_Dave jumps from prvProcessTimerOrBlockTask Default_Handler

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

if WORKAROUNDPMUCM001 == 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

CORTEX_M4F_Infineon_XMC4000_GCC_Dave jumps from prvProcessTimerOrBlockTask Default_Handler

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 ~~~

CORTEX_M4F_Infineon_XMC4000_GCC_Dave jumps from prvProcessTimerOrBlockTask Default_Handler

infineon has made a define for this ~~~

if defined(ENABLEPMUCM001WORKAROUND)

~~~ its used in the linker file I while change the define in the config.h file

CORTEX_M4F_Infineon_XMC4000_GCC_Dave jumps from prvProcessTimerOrBlockTask Default_Handler

thanks for your quick help in the AC revision of the xmc4500 chip the silicon bug is solved