Program stuck in Dummy_Handler

Log in or register to post comments
Go To Last Post
7 posts / 0 new
Author
Message
DrDatasalad
DrDatasalad's picture
Level: Wannabe
Joined: Mon. Jun 8, 2009
Posts: 95 View posts
Location: Planet of the Apes
#1
Posted by DrDatasalad: Wed. Apr 27, 2022 - 01:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I know there are a lot of posts for this issue, but none does help.
I have SAME53J18 on custom board and configured peripherals with Atmel Start, using Visual Studio 7.0.??
At some point of the program, it gets stuck in Dummy_Handler.
I have looked in Debugger->Call Stack, but there is only the code line where I get the last breakpoint hit.
The following lines could'n produce a exeption:

- Last Line that is OK: wait_pwm_cs();

 

#define ANALOG_OUT_CS_PWM                TCC0

 

void wait_pwm_cs(void)
{
    testpin_set();

    ANALOG_OUT_CS_PWM->INTFLAG.bit.MC1= 1;
    while(!ANALOG_OUT_CS_PWM->INTFLAG.bit.MC1)    ;
}
With testpin-set and -clear, I've probed that program waits the whole time for the intflag.
And it takes 14µs from testpin_set() to entry to Dummy_Handler.
So the problem must be code in another interrupt routine. How to locate this?
 

- Is there a possibility in the debugger to see the stack and stack pointer?
- In NVIC->IABR1 the 16th Bit is set. Which Interrupt is that? Is there any valuable documentation of the NVIC?

 

Please help.

 

 

This topic has a solution.

Surprise: As soon as one's doing it correctly - it works!

Tags:

Atmel SMART ARM-based MCUs and MPUs, Atmel Cortex-M MCUs, solved
Last Edited: Mon. May 9, 2022 - 02:01 PM
Top
jtw_11
jtw_11's picture
Level: Hangaround
Joined: Thu. Nov 7, 2013
Posts: 198 View posts
Posted by jtw_11: Sun. May 8, 2022 - 06:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DrDatasalad wrote:
- In NVIC->IABR1 the 16th Bit is set. Which Interrupt is that? Is there any valuable documentation of the NVIC?

 

Yes, in the datasheet rev G, check table 10.2.2 Interrupt Line Mapping - this gives you the interrupt ID for each peripheral.

 

Bit 16 is an interrupt from the external interrupt controller for EXTINT 4. Your code example doesn't show exactly what you're doing - are you driving a PWM signal out onto a pin that is configured to interrupt on state change?

 

Is testpin_set() setting the pin mapped to EXTIN 4?

Last Edited: Sun. May 8, 2022 - 06:25 PM
Top
DrDatasalad
DrDatasalad's picture
Level: Wannabe
Joined: Mon. Jun 8, 2009
Posts: 95 View posts
Location: Planet of the Apes
Posted by DrDatasalad: Mon. May 9, 2022 - 05:47 AM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you, for your hints.

 

jtw_11 wrote:

Is testpin_set() setting the pin mapped to EXTIN 4?

No, or not intended. I'll have to check this.
But I am quite sure, that I don't have EXTIN4-Interrupt.
I do have EXTINT6, but not for interrupt (is definitely not enabled)

Meanwhile I have found the bug smiley
I call a function with a function pointer, and it was unintentionally Null.
So the error message / interrupt should be "access vioalation" or "protected address" or alike.

It was really time-consuming to locate the error to one line.
I have cruicial tasks in interrupt routines running. So I can't do line-by-line debugging.
And with optimization turned on, it is sometimes not possible to set breakpoints freely.

 

So the question remains, how to identify an active interrupt source - especially when it is from processor system, like divide by zero, access violation, but also for timers?
 

Surprise: As soon as one's doing it correctly - it works!

Top
hs2
hs2's picture
Level: Rookie
Joined: Mon. Dec 10, 2018
Posts: 23 View posts
This reply has been marked as the solution. 
Posted by hs2: Mon. May 9, 2022 - 10:42 AM (Reply to #3)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is pretty good: https://interrupt.memfault.com/b...

Top
DrDatasalad
DrDatasalad's picture
Level: Wannabe
Joined: Mon. Jun 8, 2009
Posts: 95 View posts
Location: Planet of the Apes
Posted by DrDatasalad: Mon. May 9, 2022 - 02:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you very much hs2 for your link!
This is, what I was looking for.

So for me, this topic is solved.
I will look for the mentioned registers to know them and where to find.
 

Surprise: As soon as one's doing it correctly - it works!

Top
jtw_11
jtw_11's picture
Level: Hangaround
Joined: Thu. Nov 7, 2013
Posts: 198 View posts
Posted by jtw_11: Mon. May 9, 2022 - 05:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aha, glad you found the issue - however, function pointer calls should always be checked for NULL prior to dereferencing where you are unable to guarantee they are not NULL through other means. Standards such as MISRA require this, e.g.

 

if (fun_ptr != NULL){
    fun_ptr();
}

I suspect the reason you were seeing EXTINT[4] as the interrupt source, was due to writing to the EIC registers inadvertently via your NULL pointer. Such bugs are as you say, challenging to find! Using such guards would have prevented your issue by the sounds of things; equally these checks can be extended with an else case to call upon some application defined fault handling system also.

 

In addition, check the device datasheet for the "Peripheral Access Controller", this prevents you with a means of locking peripheral registers such that an 'inappropriate' access to them will indeed provide means of detecting these errors (whatever the root cause for the illegal access).

Last Edited: Mon. May 9, 2022 - 05:33 PM
Top
DrDatasalad
DrDatasalad's picture
Level: Wannabe
Joined: Mon. Jun 8, 2009
Posts: 95 View posts
Location: Planet of the Apes
Posted by DrDatasalad: Tue. May 10, 2022 - 05:18 AM (Reply to #6)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jtw_11 wrote:

Using such guards would have prevented your issue by the sounds of things

You are absolutely right. Afterwards one knows better.
 

Surprise: As soon as one's doing it correctly - it works!

Top