Default Handler disrupting FreeRTOS program

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
I have a program built using DAVE apps which decodes RFID tags using an HTRC110 NXP chip.
In this program I have no APPs managing the ADC blocks, however after some time the program is disrupted by an unmanaged interrupt which executes continuously the default handler, as shown in the attached image.

Am I missing something? I guess that all unwanted IRQ nodes should be masked at startup, if is not the case how I can do this?

The platform is the XMC4500 Relax Kit.4804.attach
0 Likes
18 Replies
User7921
Level 3
Level 3
I have the same issue, but with my brand new XMC4800 Relax Boards.

Immediately after the start the program stops at the ADC interrupts.
No main is reached.
I guess it has nothing to do with ADC directly, since I created (for testing) an ISR for the ADC interrupt where the code stops and
now it stops at a different one...

In the past, this normally happened when my code did use a NULL pointer or a jump to an invalid address.
But I have NO line of user code...

I even tried a project without any app. Just a clean DAVE project (DAVE 4.1.4 & GCC).
Same result.
I tried it with different boards, no difference.

Now I have to use my 4500 devices for testing the new project. But it's not possible to migrate to 4700/4800 from 4500.
And they have the UART parity bug...

Michael
0 Likes
Not applicable
Update: if an user defined handler is assigned to VADC0_G3_3 the programs hangs in the default handler as VADC0_G3_2 in the same fashion,
similarly to what happens to Trony
0 Likes
Not applicable
update: this is the situation of the NVIC_ICER registers stopping the program when the ADC default handler is running: only bit 7 of NVIC_ICER0 is enabled!

1700.attach
0 Likes
Not applicable
Checking in...

Has anybody experienced similar problems?

adriano
0 Likes
Not applicable
yes, I did. You must go deeper yourself to find out the problem. It does not have anything to do with Freertos, at least in my cases.
0 Likes
Not applicable
Update: changing priorities to the ISR which serves the ERU event and the RTOS changes the behaviour.
Here is a table which shows that changing the priority level things change.
In the code there are NO calls to RTOS API, so configMAX_API_CALL_INTERRUPT_PRIORITY should be irrelevant.1737.attach
0 Likes
Not applicable
I had a similar problem, and was able to resolve it by editing the "linker_script.ld"
In my case there was something missing in the memory declaration:

MEMORY
{
FLASH_1_cached(RX) : ORIGIN = 0x08000000, LENGTH = 0x200000
FLASH_1_uncached(RX) : ORIGIN = 0x0C000000, LENGTH = 0x200000
PSRAM_1(!RX) : ORIGIN = 0x1FFE8000, LENGTH = 0x18000
DSRAM_1_system(!RX) : ORIGIN = 0x20000000, LENGTH = 0x20000
DSRAM_2_comm(!RX) : ORIGIN = 0x20020000, LENGTH = 0x20000
SRAM_combined(!RX) : ORIGIN = 0x1FFE8000, LENGTH = 0x58000
}

Now it is working fine.

Cheers
Tobi
0 Likes
User10538
Level 3
Level 3
I have the same problem, I guess, when trying to give a semaphore from an interrupt.

If I then call portYIELD_FROM_ISR( xHigherPriorityTaskWoken ); after the xSemaphoreGiveFromISR( xSemaphore, &xHigherPriorityTaskWoken )
the same problem occurs, this has however nothing to do with ADC default handlers, even though it points there initialy

you need to trap the Hardfault_Handler (place code in main.c)

void HardFault_Handler(void)
{
int systemControlBlock = SCB->HFSR; //should be 0x40000000 = FORCED hard fault, check CFSR
int configurableFaultStatusReg = SCB->CFSR; // xmc ref manual 2-75 (p.131)
__ASM volatile("BKPT #01"); // enter breakpoint

while(1);
}


there you can check the registers, and it is actualy an INVPC-Event which causes that Problem "Invalid PC load Usage Fault, caused by an invalid EXC_RETURN value"

I have no idea how to solve this however (XMC4500 HexagonKit AB-stepping). If I do not call portYIELD_FROM_ISR( xHigherPriorityTaskWoken ); there is no problem, but it then only switches to the newly unblocked task with the next Systick, which is of course unacceptable in a realtime system.
0 Likes
Not applicable
thanks kinkilla!
I will check the linker script asap

Adriano
0 Likes
Not applicable
Update:

After upgrading to DAVE 4.2.4 and rebuilding the apps and the application the bug is gone: the application works as intended.

My advice to anyone using DAVE is to upgrade ASAP

best regards,
Adriano,
0 Likes
User12779
Level 1
Level 1
Old thread but i have the similar problem using XMC4300. The programm stucks at the Default_Handler. In my case at the VADC0_G1_3_IRQHandler.
I don't use any ADC but as some of you wrote the problem can be somewhere else. Could anyone provide me some hints how to solve this?

Thanks
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

Could you add to your project the CPU_CTRL_XMC4 APP and enable hardfault debugging support in the "Exception Settings"?
If the program generates a fault, the debugger will break the execution and we can investigate the possible root cause after looking to the _CFSR variable.

Regards,
Jesus
0 Likes
User12779
Level 1
Level 1
Thank you Jesus.
It is an INVPC-Event which causes that Problem "Invalid PC load Usage Fault. Seems to happen sometimes when i use sprintf() function. I will check that in detail now.
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

If the destination string of sprintf is a local variable, you maybe running out of stack.

Regards,
Jesus
0 Likes
User18369
Level 2
Level 2
jferreira wrote:
Hi,

Could you add to your project the CPU_CTRL_XMC4 APP and enable hardfault debugging support in the "Exception Settings"?
If the program generates a fault, the debugger will break the execution and we can investigate the possible root cause after looking to the _CFSR variable.

Regards,
Jesus


Where can I find the "Exception Settings" to enable Hardfault ?
I have the same Probmlem with the VADC0_G1_3_IRQHandler without using FreeRTOS....
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
In the CPU_CTRL_XMC4 APP UI settings:

4828.attach

Regards,
Jesus
0 Likes
User19823
Level 1
Level 1
Hello,

I am having the same issues with the INVPC. I have only installed the ETH_LWIP APP with FREERTOS. With no Task generated except the ones in DAVE_init for TCP/IP. I get the Default Handler exception as soon as i plug in an ethernet cable. without the plugged in cable the exception doesnt occur. Anyone an idea what could be the reason for that?
0 Likes
lock attach
Attachments are accessible only for community members.
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

I cannot reproduce your problem.
See attached my example.

Regards,
Jesus
0 Likes