Not applicable
Dec 11, 2015
12:36 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 11, 2015
12:36 AM
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.
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.
18 Replies
Dec 15, 2015
10:25 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 15, 2015
10:25 PM
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
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
Not applicable
Dec 18, 2015
03:54 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 18, 2015
03:54 AM
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
similarly to what happens to Trony
Not applicable
Dec 21, 2015
01:47 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dec 21, 2015
01:47 AM
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!
Not applicable
Jan 07, 2016
07:35 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 07, 2016
07:35 AM
Checking in...
Has anybody experienced similar problems?
adriano
Has anybody experienced similar problems?
adriano
Not applicable
Jan 07, 2016
08:35 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 07, 2016
08:35 AM
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.
Not applicable
Jan 11, 2016
07:18 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 11, 2016
07:18 AM
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.
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.
Not applicable
Jan 20, 2016
08:03 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 20, 2016
08:03 AM
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
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
Feb 03, 2016
01:51 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 03, 2016
01:51 AM
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)
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.
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.
Not applicable
Mar 03, 2016
06:39 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 03, 2016
06:39 AM
thanks kinkilla!
I will check the linker script asap
Adriano
I will check the linker script asap
Adriano
Not applicable
Mar 04, 2016
05:11 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 04, 2016
05:11 AM
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,
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,
Feb 10, 2017
05:48 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 10, 2017
05:48 AM
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
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
Feb 12, 2017
01:57 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 12, 2017
01:57 PM
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
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
Feb 17, 2017
04:21 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 17, 2017
04:21 AM
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.
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.
Feb 17, 2017
06:16 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 17, 2017
06:16 AM
Hi,
If the destination string of sprintf is a local variable, you maybe running out of stack.
Regards,
Jesus
If the destination string of sprintf is a local variable, you maybe running out of stack.
Regards,
Jesus
Mar 03, 2020
01:32 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 03, 2020
01:32 AM
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....
Mar 04, 2020
05:12 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 04, 2020
05:12 AM
In the CPU_CTRL_XMC4 APP UI settings:
Regards,
Jesus
Regards,
Jesus
Nov 13, 2020
07:11 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 13, 2020
07:11 AM
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?
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?
Attachments are accessible only for community members.
Nov 28, 2020
02:08 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 28, 2020
02:08 AM