External IRQ always triggered by Initialization in SAME70-XPLD + ASF4

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

Running example code used from the ASF4 example implemented for the same SAME70 Xplained board.
The code uses PA11 pin as input for External IRQ which is triggered by a rising edge of the pulse from the on-board BUTTON.
External IRQ driver and related  GPIO pin initializations have been generated by Atmel START.
All the related functionality is working except one problem:  Always during the initialization the IRQ is triggered and Callback is called although the Button was not pressed and the level on the pin is steady "high". Afterwards everything works as it should.

I traced the initialization process. The moment after POR when Callback has been registered by a call

ext_irq_register(PIO_PA11_IDX, button_on_PA11_pressed);

The related IRQ #10 (IRQ number is correct for a given pin) gets generated , the IRQ turns PENDING and then ACTIVE, calling the registered Callback.

I tried to set the pin level high before Callback registration :
gpio_set_pin_level(BUTTON, true);  // still does not work.
Then I tried to intercept any possible IRQ before registering a Callback and enabling the IRQ. I used the code:
 

	if(NVIC_GetPendingIRQ(PIO_PA11_IDX))
	{
		NVIC_DisableIRQ(PIO_PA11_IDX);
		NVIC_ClearPendingIRQ(PIO_PA11_IDX);
		NVIC_EnableIRQ(PIO_PA11_IDX);
	}
	ext_irq_register(PIO_PA11_IDX, button_on_PA11_pressed);

Didn't work either. There are no PENDING IRQs !  The IRQ gets generated during the setup of the PIOA registers and related NVIC registers, - regardless the state of the pin.
Is there a known a bug in the library (or in the chip ) related to this?

Does anybody know such problem? Any suggestions?

 

This topic has a solution.
Last Edited: Mon. Aug 5, 2019 - 03:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The code uses PA11 pin as input for External IRQ which is triggered by a rising edge of the pulse from the on-board BUTTON.

I would expect falling edge, this is a button connected to GND with pull up right?

/Lars

 

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

Right - button connects to ground when pressed and internal pull-up is configured. Triggering by rising or falling edge does not matter - after pressing the button returns back anyway - whatever goes down, will rise up again :) the only difference is the IRQ triggered when pressed in one case, when released in another case.

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

Yes but you can't implement an action depending on the time the button is pressed if it triggers on release. And I suspect a rising edge is more likely to occur during the startup (depending on the pullup activation compared to when the ext irq is activated).

/Lars

 

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

Pull-up is activated during GPIO pad initialization well before NVIC is configured to use it for IRQ generation. I did both cases (rising and falling edge) - didn't matter.

Anyway, thank you for looking into this problem. Although issue is not important in this particular example but it is critical for a large project startup process. I filed a request for a tech support.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Problem is solved with advice from Atmel tech support.

In the main() after the basic initialization which only prepares the GPIO pins before any interrupt related functions are called, then the following

		ext_irq_enable(PIO_PA11_IDX);
		ext_irq_disable(PIO_PA11_IDX);
// register a Callback for the button interrupt, at the end Interrupt will be enabled
		ext_irq_register(PIO_PA11_IDX, button_on_PA11_pressed);

And no ISR is called until actual button press occur.

Looks like the required sequence ext_irq_enable -> ext_irq_disable is a work around the known problem rather then an expected procedure but nonetheless it works.

Thanks to Gunu Baik from tech support.