Interrupt on udoo

Well.. as I said, it doesn't compile, so I haven't been able to test it yet

 

You said it compiles with every mode except CHANGE so what if you use one of the others. There is not so much difference between Change and Rising or Falling so we are all curious if these work after compiling. Then we can look into the issue why CHANGE is not working.

 

@Agustin Lagos and @waltervl , i made some test with interrupts and have the same result, if i use CHANGE in the mode, i have a compiler error :

CHANGE' was not declared in this scope

Otherwise, if i use RISING or FALLING it seems to work on all the digitals pins (tested with 2/7/8 and 10) .... but just for many seconds after that the interruption not working more ... the rest of the program work fine but not interruption ! under a sample of my code :

Code:

#define CODEUR_VOL_A  8

volatile uint32_t i_codeurPos=0;

void setup() {
pinMode(LED, OUTPUT);
pinMode(CODEUR_VOL_A, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(CODEUR_VOL_A), compteurCodeur, FALLING);
}

void loop() {
//some work with serial, adc ...
}

void compteurCodeur()
{
  i_codeurPos++;
}

@Andrea Rovai or @Francesco it would be great if you can check this issues with interrupt because for example without that we can't read motor encoder ...

 

Hi everyone,
I have got the same problem as @modjo described before (seems to lost the attached interrupt) the only solution I have found for now is to call attachInterrupt inside the loop function...

 

I see the documentation on the Neo is updated now (Arduino differences) but no clue yet how to solve the interrupt instability.

 

After some tests, putting the attachInterrupt inside the loop function seems to damage the UDOO...
My 2 UDOO Neo got problems with attachInterrupts now...
I was listening on digitalPin 6 & 7, both does not respond anymore to interrupts on this pins, and my second UDOO got problems only with pin 6...
All other stuff seems to work (digitialRead & digitalWrite)

 

That is strange. Are you sure nothing else changed in your configuration? Have you done a apt-get upgrade in between? What if you use a fresh installed OS?

 

Nope, nothing have changed between the working state and now... Now apt-get upgrade, or any update... I will try to install a fresh OS on my UDOO and let you know if it works

 

Recently I struggle against the same problem with interrupts. I tried to gather some informations about them.

Hardware:
Cortex M4 core has its own interrupt controller (named: NVIC). As it is ARM product, it is described in the documentation on the arm website: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/BHCFCFDB.html
I give the link to the description in the Cortex M3 branch because it is more detailed than in the M4. I made some tests on it and the addresses of registers from M3 are right for M4.
In our case NVIC handles 128 interrupts. They are specific for imx6sx and they are described in paragraph 3.3 "CM4 interrupts" on page 201 of the reference manual.
The tricky part is that any GPIO pin from the portX triggers the same interrupt signal. In order to understand which pin generated the interrupt service routine must recognize it. Let us see to which ports are connected Arduino pins

We notice that almost all pins come from port 4 and 5. Which corresponds to IRQ number from 72 to 75.


Software:
Arduino IDE libraries for interrupts are stored in: C:\Users\Username\AppData\Roaming\Arduino15\packages\UDOO\hardware\solox\1.6.6-00004-'version_number'\variants\udooneo
Important files for us are:
WInterrupts.h
WInterrupts.c

They use lower level functions from Freescale MQX like lwgpio_int_init(), _int_install_isr(), _bsp_int_init(). Unfortunately it is not easy to debug this part of the code. I registered on Freescale website and downloaded the MQX 4.2 in order to analyse their source code.

After I failed in the Freescale code analysis I made few attempts of debugging the existing code how it is.
With the following piece of code we can read register values:

Code:

#define NVIC_VTOR 0xE000ED08     //vector table offset register
#define NVIC_ICSR 0xE000ED04     //Interrupt Control State Register (Confirmed address!!!)
#define NVIC_ABR_0_31 0xE000E300      //Active Bit Register (till -0xE00031C) checks if the interrupt is rised and computing
#define NVIC_ABR_32_63 0xE000E304
#define NVIC_ABR_64_95 0xE000E308
#define NVIC_ABR_96_127 0xE000E30C

inline uint32_t NVIC_get_vector_table(){
  return *((uint32_t *)(NVIC_VTOR));
}

inline uint32_t NVIC_get_icsr(){
  return *((uint32_t *)(NVIC_ICSR));
}

inline uint32_t NVIC_get_ABR(){
  return *((uint32_t *)(NVIC_ABR_64_95));
}

Using the above functions I confirmed that I can interact with the interrupt controller.

At the end I want to ask some questions:
1. Does someone know a solution?
2. (to UDOO official developers) Can you confirm that the object file in UDOOneo board support package is compiled from unmodified sources of MQX 4.2 available from Freescale website? If not where we can find the source code.

I'm looking forward for any suggestions which can help solving this issue.

 

Dear @matib12, I can confirm that the object file in UDOO NEO board support package is compiled from modified sources of MQX 4.1. Unfortunately we cannot release the sources because they are based on something that is property of MQX. We can only release the binaries, which are in the board manager.

 

@Andrea Rovai And now, is it on your list for the next release? The community cannot help because the Arduino package is build on secret modified sources of an older version of MQX. Should we make an issue on Github?

 

I see a conflict between creating a project for community and choosing for its realisation a closed source solution.

 

Hi guys,

Here is an example of what I was testing on my UDOO. (Showing here a UDOO Quad/Dual, since Neo is not available)

And the associated Arduino code :

Code:

const int green = 3;
const int yellow = 4;
const int red = 5;
const int blue = 8;

const int startSignal = 6;
const int stopSignal = 7;

const int reset = 9;

void setup() {
  pinMode(green, OUTPUT);
  pinMode(yellow, OUTPUT);
  pinMode(red, OUTPUT);
  pinMode(blue, OUTPUT);

  digitalWrite(green, LOW);
  digitalWrite(yellow, LOW);
  digitalWrite(red, LOW);
  digitalWrite(blue, LOW);

  pinMode(startSignal, INPUT);
  digitalWrite(startSignal, HIGH);

  pinMode(stopSignal, INPUT);
  digitalWrite(stopSignal, HIGH);

  attachInterrupt(digitalPinToInterrupt(startSignal), startInterrupt, RISING);
  attachInterrupt(digitalPinToInterrupt(stopSignal), stopInterrupt, RISING);
}

void startInterrupt(){
  digitalWrite(green, HIGH);
}

void stopInterrupt(){
  digitalWrite(red, HIGH);
}

void loop() {
  if(digitalRead(reset) == HIGH){
    digitalWrite(green, LOW);
    digitalWrite(yellow, LOW);
    digitalWrite(red, LOW);
    digitalWrite(blue, LOW);
  }
  if(digitalRead(startSignal) == HIGH){
    digitalWrite(yellow, HIGH);
  }
  if(digitalRead(stopSignal) == HIGH){
    digitalWrite(blue, HIGH);
  }
}

It should light green led on startSignal pin (6) interrupt detected, and red led on stopSignal pin (7) interrupt detected, not working at all on my first UDOO neo, working for startSignal pin on my second UDOO neo.

I have put a second test to see state of these pins, it should light yellow led if startSignal pin (6) is HIGH, and blue led if stopSignal pin (7) is HIGH, on my first UDOO card, these two leds are always lighted, and on my second blue led is always lighted (stopSignal pin is always HIGH).

I am not an electronic expert so it is possible that I made a mistake on my electronic assembly, so if you see a mistake, please let me know where I am wrong.
In case of my assembly is good, there should be a problem with interrupts on UDOO neo, isn't it ?

 

@waltervl: releasing MQX can't be on our list, because it doesn't depend on us. It depends on the fact that MQX is proprietary, and this won't change with the next release.
@matib12: the point is not that we want to be closed source. We want to be completely open source, but we are a small team and we don't have the resources to develop everything on our own.

 

@Andrea Rovai , do you plan to work on this problem (interrupt on NEO) ?

 

Hi there, we're working on this problem. We've just changed the related page in the guide. Have a look (if you're jumping on the link immediately after this post you'll probably see no change since it needs 2 min to update the documentation from github): http://www.udoo.org/docs-neo/Arduino_M4_Processor/Arduino_differences.html
It may not solve your problem or it may do. In other words we need your feedback

 

The feedback is already in this topic. The problem that is mentioned in the documentation is being dealt with, users don't use CHANGE or other invalid functions. But now we run into reliability issues with the interrupts. See the comments in this thread.

 

I didn't ask you to release MQX but to change to Udoo Arduino board package in a next release or whatever to solve the reliability issue on interrupts (and also solve the other incompatibilty issues )

 

There is no update from MQX 4.1 to 4.2 for UDOOneo processor. Look: https://community.nxp.com/thread/355438.
The MQX 4.1 for SoloX is in the "Preview" tab: https://nxp.flexnetoperations.com/control/frse/download?element=6133771

A link to some similar issues:
https://community.nxp.com/thread/319294 - interrupt vector table gets lost

 

Looks fine to me but when you push the reset button will all the leds go out? What if you delete the 2 attachinterrupt, will the yellow and blue led act as expected?