Dummy Handler problem

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi.

I need to use external interupt on PB14 on SAM4E16EA.

 

I defined handler for it in main.c

 

void PIOB_Handler(void)
{
    uint32_t status_01 = REG_PIOB_ISR;
   /*

    work to do :)

   */
    return;
}

 

and acommented (deleted) its weak definition in startup_sam4e.c

//void PIOB_Handler   ( void ) __attribute__ ((weak, alias("Dummy_Handler")));
 

I did port setings and enabled interupt:

 

NVIC_EnableIRQ(PIOB_IRQn);

PIOB->PIO_IER = 0x4000;

 

But it always ends in Dummy Handler and it never did my handler.

Why?

Thanks

Atmel-ICE
Atmel Studio 7.0

Last Edited: Thu. Jun 16, 2016 - 12:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

s.t.e.n.y wrote:
... commented (deleted) its weak definition in startup_sam4e.c

//void PIOB_Handler   ( void ) __attribute__ ((weak, alias("Dummy_Handler")));

No! Don't do that!

 

The whole point of the 'weak' definition is that it provides a "placeholder" until your own function is found; so there is no need to delete it - and deleting it may actually mess things up ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All you need to do is:
void PIOB_Handler ( void )
{
Your stuff here
}

The vector definition is 'weak' and defaults to 'Dummy_Handler' if no one else uses it. When you define your handler, this overrides this.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know what a weak def should do .. but.. when I left it there and than I launch it .. it ends in dummy handler .. when I delete it it has no warning at all but same problem ... always dummy handler ... thats what I want to solve why it go always to stupid dummy handler even when I had my own handler defined :/

Atmel-ICE
Atmel Studio 7.0

Last Edited: Fri. Jun 17, 2016 - 07:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note that many things go to the dummy handler ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Look at the stack frame to see how you got there.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yes, but
I use only this one Interrupt.
When I disable Interupt mask on pin I want, it never go to that dummy handler.

But it NEVER went to my own handler... :/

So its sure, by my deducation, something really wrong becouse its not logical anymore ..

I am very tired about this ........
 

Atmel-ICE
Atmel Studio 7.0

Last Edited: Sat. Jun 18, 2016 - 07:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does the hard fault handler also go to the dummy handler? If it does, then you might have a hard fault - maybe you didn't enable the peripheral and/or clock. Examine the stack frame and find the address ofvthe code that caused the problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hard fault handler ? that is not used, or I dont use that .... I dont use ASF becouse I need really time precision parts of code.
I use ATSAM4E16E on custom board and all is operated by register changing system... not stupid preddefined funcitons.

Periph clock is enabled ....

Mask is enabled ..and my code ends in dummy only when it should go to my PIOB_Handler.

 

When its enabled but rising edge of signal dont came, it dont go to any handler

My question is simple: Why, when it should make PIOB_Handler it makes Dummy_Handler ?

 

Atmel-ICE
Atmel Studio 7.0

Last Edited: Sat. Jun 18, 2016 - 08:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You have no choice with hard fault. If you access a peripheral the that isn't enabled or clocked or you have a bus alignment fault then you get a hard fault. Nothing to do with ASF. As i said, analyse the stack frame to find what address was interrupted. How to do this? Read the ARM doc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
How to do this? Read the ARM doc.

or google, "debugging a Hard Fault"

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Is something of this what we need to know? or where I can find "stack frame" ?

Atmel-ICE
Atmel Studio 7.0

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are in luck, open the Call Stack window and see if studio was able to capture the fault frame.

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

at the same moment :)

Atmel-ICE
Atmel Studio 7.0

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, NVIC_EnableIRQ at line 1498 (just double click that) vectored through the vector into the dummy handler (note, might we worth looking at that in the disassembly, not always obvious what instruction caused the exception)... 

 

Unfortunately, due to the weak usage, the line number in <signal handler> is the line number of the Dummy_Handler (unless another function overrides the weak link), so it's not that easy to find out exactly the vector number unless you just make another dummy handler and goes through all the function names until your custom handler hits...

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That NVIC is swithing that interupt on ... I mean port B interupt .... its done by once ... and I have defined my own PIOB_Handler in main.c

I am really hopeless from that ..

Periph Clock is enabled,

port is setup as input without pullup/down,

interupt mask is set

NVIC interupt is enabled,

when I connect cable, it corectly recognize this moment and instead of going to my handler .. it ends in dummy.

When turn off mask or NVIC, its never go to dummy :/

My english isnt best too....

Atmel-ICE
Atmel Studio 7.0

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try to implement the rest of the handlers, and see which one is being hit. Should help narrow down the issue.

 

Most interesting is probably the system handlers, such as HardFault, NMI etc.

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried it to define them in main.c but it looks like its ignoring all my handlers defined there.

It only ends in dummy. :D nothing else.

Isnt there any global enable interrupt or somthing what for I could forget ?

Atmel-ICE
Atmel Studio 7.0

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello All,

 

any one find the solution to stop entering into the dummy handler.

 

I am also facing Same problem in my SAMD20E15 board,
when I was trying to debug it is entering into Dummy handler() function,
Here I am using Segger debugger J-link(SWD) to upload code and debugging, I am able to flash the code but no expected output, 
so I tryied to debug it is entering into Dummy handler() function? I did't get any idea how to stop that interrupt, and in this board I am using 32 Mhz crystal .

I am not using 32Khz Crystal because I don't need RTC for my application.

My Sample Program:

 

#include <asf.h>
void SysTick_Handler(void)
{
 
 port_pin_toggle_output_level(PIN_PA19)
}
/** Configure LED0, turn it off*/
static void config_led(void)
{
 struct port_config pin_conf;
 port_get_config_defaults(&pin_conf);
 pin_conf.direction  = PORT_PIN_DIR_OUTPUT;
 port_pin_set_config(PIN_PA19, &pin_conf);
 port_pin_set_output_level(PIN_PA19,LED_0_INACTIVE);
}
int main(void)
{
 system_init();
 /*Configure system tick to generate periodic interrupts */
 SysTick_Config(system_gclk_gen_get_hz(GCLK_GENERATOR_0));
 config_led();
 while (true) {
 }
}

 

I am not able to blink the LED of PIN_PA19.

 

 

 

i checked in call stack window, it is showing signal handler called Line 220.

 

 

Please can any one help me..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You configure the LED pin after you setup the Systick handler, so there is a good chance that the Systick Handler gets called before the pin is configured.

 

Try to place the config_led() call before SysTick_Config.

 

What line is line 220 ??

Last Edited: Mon. Feb 27, 2017 - 08:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Solution described below is valid for M0, perhaps it is applicable for SAM4 too.

If interrupt handler has no code, resp. handler has no interrupt flag reset (set to 0, some people says it is not necessary, flag is cleared automatically, but in fact, it is not or it depends on MCU type), after MCU restart one interrupt is triggered, but flag remains set, than new interrupt will arise immediately, than again and again... and it will invoke endless loop and dummy_handler . Also, if interrupt handler (void EIC_Handler… )is missing (commented) such behaviour may be observed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you don't know what caused the the interrupt, make a short interrupt handler for each peripheral, and just clear any set flags in INTFLAG for the particular peripheral. Put a breakpoint in the handler. Typical code is:

void TCC1_Handler(void)
{ uint32_t intflag = TCC1>INTFLAG.reg & TCC1->INTENSET.reg;

   if (intflag)

    TCC1->INTFLAG.reg = intflag;

}

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hello mlundin,

 i tried to place the config_led() call before SysTick_Config. but still it is going dummy handler function only. i tried other examples blinking led(poll back based) there also i am facing same problem.

 

it is in line 246.

my dummy handler function is,

 

 

/**
 * \brief Default interrupt handler for unused IRQs.
 */
void Dummy_Handler(void)
{
        while (1) {
            
        }
}

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

compiler is going to dummy handler while iam debugging why

 

 

m

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The compiler runs on your computer not the sam cpu. As to why it goes to the dummy handler - you'll have to gives us a bit more information if you want a useful answer as we're not mind readers. Besides, you've got a debugger - what is that telling you?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not familiar with the SAM4, but just had a similar problem with the SAMD21. If you "break all" in the IDE, then look at the interrupt pending register (NVIC->NVICISPR for SAMD21) you'll see which peripheral caused the interrupt. Look at the INTFLAG of that peripheral to see which particular interrupt it was. 

Jerry

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

 

I'm using ATSAM4LC2A in custom board. I've crystal of 32KHz on board.

I need to have CPU freq of 48MHz. For that I have set things as below:

 

#define CONFIG_SYSCLK_SOURCE        SYSCLK_SRC_DFLL                    // Clock source as DFLL output

#define CONFIG_DFLL0_SOURCE         GENCLK_SRC_OSC32K                // 32KHz Osc as input to DFLL

 

#define CONFIG_DFLL0_FREQ           48000000UL                                 // Required output of DFLL is 40MHz

 

#define CONFIG_DFLL0_MUL            (CONFIG_DFLL0_FREQ / BOARD_OSC32_HZ)
#define CONFIG_DFLL0_DIV            1

 

But this isn't working and going into Dummy Handler for different reasons - like GPIO pin setting, USB clock enabling

 

When I decrease DFLL0_FREQ to 40000000UL  (40MHz), it is working fine.

 

NOTE: I'm using USB stack for USB in device mode.

 

P D Chauhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you configured the flash wait states?

David

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks David!

 

Yes... It was not set to HSEN. I've defined CONFIG_FLASH_READ_MODE_HIGH_SPEED_ENABLE in sysclk.h and now it is set to PS is set to HSEN and Flash wait state is set to 1.

But still... it goes into Dummy Handler. Now, it is when configuring cpu_irq_restore during bpm configuration.

P D Chauhan