Keil Logo

IRQ Not Firing

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Details Message
Read-Only
Author
Ben S.
Posted
3-Oct-2011 15:03 GMT
Toolset
ARM
New! IRQ Not Firing

Hello,

I am writing an I2C master transmitter object. The problem I am having is that the IRQ Handler for I2C1 is not firing. According to the manual, it should fire after the start condition is sent and the status register is 0x08. When I step through the code with the debugger, the status code is 0x08. I am using an MCB1700 development board. Why is it not firing? Did I not configure something properly? For tests, All I am doing is toggling an LED on when the interrupt fires. Once I solve this problem, I will write the rest of the code.

#include <stdio.h>
#include <LPC17XX.h>
#include "GPIO1Output.h"

GPIO1Output out(P1_28);

__irq void I2C1_IRQHandler(void)
{
        if (LPC_I2C1->I2STAT == 0x08)
        {
             out.Set();
        }
}

int main(void)
{
        // Initialize I2C.
        LPC_PINCON->PINSEL0 = 0x0F;
        LPC_PINCON->PINMODE_OD0 = 0x03;

        NVIC_EnableIRQ(I2C1_IRQn);
        LPC_I2C1->I2CONSET = 0x40;

        LPC_I2C1->I2CONSET = 0x20;
        int status = LPC_I2C1->I2STAT;
}
Read-Only
Author
Andrew Neil
Posted
3-Oct-2011 15:21 GMT
Toolset
ARM
New! RE: IRQ Not Firing

It always helps if you explicitly state what processor you're using. Don't just leave us to infer it from other details.

The MCB1700 comes in two versions - with different processors!
Which one, exactly, do you have?

http://www.keil.com/mcb1700/

"I am writing an I2C master transmitter object"

Before you do that, have you looked at supplied examples - from Keil and NXP ?

__irq void I2C1_IRQHandler(void)

One of the "key features" claimed by ARM for the new Cortex-M3 was that it didn't require special interrupt handlers - so why are you adding the __irq here...?

Read-Only
Author
Ben S.
Posted
3-Oct-2011 15:24 GMT
Toolset
ARM
New! RE: IRQ Not Firing

I am using the LPC1768. Yes, I have looked at the examples, and according to them and what I did, in my mind, the interrupt should fire.

Read-Only
Author
John Hart
Posted
3-Oct-2011 16:29 GMT
Toolset
ARM
New! RE: IRQ Not Firing

Mr Andrew Neil. I am just curious what is your day job? I find it hard to believe that you have time to actually do any work, given the number of posts you have made to various forums (Keil and ST to name just two). You seem to have an answer/opinion about everything. I can only hope that you're self employed so you're not doing all this on your employer's time :)

Read-Only
Author
Tamir Michael
Posted
3-Oct-2011 16:33 GMT
Toolset
ARM
New! RE: IRQ Not Firing

I am just curious what is your day job?

He's a carpenter, of course!
I think Andy is indeed self-employed - he once posted a link to his company's website (or was it the good old captain?).

Read-Only
Author
Tamir Michael
Posted
3-Oct-2011 16:33 GMT
Toolset
ARM
New! RE: IRQ Not Firing

I forgot to post a :-)

Read-Only
Author
Ben S.
Posted
3-Oct-2011 16:34 GMT
Toolset
ARM
New! RE: IRQ Not Firing

Come on, does anyone have a solution to this issue I am having?

Read-Only
Author
Tamir Michael
Posted
3-Oct-2011 16:37 GMT
Toolset
ARM
New! RE: IRQ Not Firing

In main, I'm missing a

for (;;)
{
}

don't have time look in more detail right now...

Read-Only
Author
Ben S.
Posted
3-Oct-2011 16:54 GMT
Toolset
ARM
New! RE: IRQ Not Firing

The infinite loop does not make a difference.

Read-Only
Author
Ashley Madison
Posted
3-Oct-2011 17:05 GMT
Toolset
ARM
New! RE: IRQ Not Firing

"I can only hope that you're self employed so you're not doing all this on your employer's time :)"

now you have scared him off.

Read-Only
Author
Ben S.
Posted
3-Oct-2011 18:29 GMT
Toolset
ARM
New! RE: IRQ Not Firing

When I run this code with the debugger, the program quits running after it hits the line where the command LPC_I2C1->I2CONSET = 0x20; (see code) is. The debugger t1 time just keeps increasing and nothing happens. The same thing happens even when I am not debugging. Does this give anyone a clue?


#include <stdio.h>
#include <LPC17XX.h>
#include "GPIO1Output.h"

GPIO1Output out(P1_28);

void I2C1_IRQHandler(void);

int main(void)
{
        // Initialize I2C.

        LPC_PINCON->PINSEL0 = 0x0F;
        LPC_PINCON->PINMODE_OD0 = 0x03;
        NVIC_EnableIRQ(I2C1_IRQn);

        LPC_I2C1->I2CONSET = 0x40;
        LPC_I2C1->I2CONSET = 0x20; // Program does not get beyond this line.

        while(1);
}

void I2C1_IRQHandler(void)
{
        if (LPC_I2C1->I2STAT == 0x08)
        {
                LPC_I2C1->I2CONCLR = 0x20;
                out.Set();
        }
}

Read-Only
Author
Per Westermark
Posted
3-Oct-2011 18:43 GMT
Toolset
ARM
New! RE: IRQ Not Firing

Did you set any breakpoint in your ISR?

Are you making sure that whatever reason you get into the ISR are resulting in the interrupt source being cleared?

Read-Only
Author
Ben S.
Posted
3-Oct-2011 18:45 GMT
Toolset
ARM
New! RE: IRQ Not Firing

I did put breakpoints in the ISR. They are never reached.

Read-Only
Author
Tamir Michael
Posted
3-Oct-2011 18:49 GMT
Toolset
ARM
New! RE: IRQ Not Firing

Did you power the i2c peripheral?

Read-Only
Author
Ben S.
Posted
3-Oct-2011 18:59 GMT
Toolset
ARM
New! RE: IRQ Not Firing

In the configuration wizard for the system_LPC17xx.c there is a check by the I2C1 in the Power Control for Perepherials Register (PCONP), so yes, power is enabled here. Is there something else? I disabled power to all perepherials I am not using.

Read-Only
Author
Per Westermark
Posted
3-Oct-2011 19:02 GMT
Toolset
ARM
New! RE: IRQ Not Firing

Where in the ISR did you set your breakpoint?

If an interrupt doesn't happen, then the single-stepping would normally continue as normal. If the processor does not continue to single-step, then you have to consider problems with stack space for the interrupt, or that you do reach the interrupt but get jumped to another place than you thought. Or that you reach the ISR again and again and again because you don't clear the interrupt.

Read-Only
Author
le Ben S.
Posted
3-Oct-2011 19:09 GMT
Toolset
ARM
New! RE: IRQ Not Firing

Single stepping is working fine. That means the interrupt is not firing. There must be something I am not setting up right. I also tried one of the other I2C channels. No Cigar.

Read-Only
Author
Tamir Michael
Posted
3-Oct-2011 19:15 GMT
Toolset
ARM
New! RE: IRQ Not Firing

You probably did, but did indeed follow the "basic configuration" procedure described in the NXP user manual? NXP offer a sample code bundle at the LPC1768 page that build with uv4.

Read-Only
Author
Tamir Michael
Posted
3-Oct-2011 19:17 GMT
Toolset
ARM
New! RE: IRQ Not Firing

Maybe you are using a non-standard startup file that calls the i2c interrupt function differently? Do other interrupts work?

Read-Only
Author
le Ben S.
Posted
3-Oct-2011 19:24 GMT
Toolset
ARM
New! RE: IRQ Not Firing

Funny that you ask, do other interrupts work. The answer is no. Other ones do not work either. At the link is a picture of my startup files. Are they not standard?

http://imageshack.us/photo/my-images/594/unledqqb.png/

Read-Only
Author
Tamir Michael
Posted
3-Oct-2011 19:46 GMT
Toolset
ARM
New! RE: IRQ Not Firing

Take the startup files of a working Keil example for the MCB1700. Overwrite yours. What happens?

Read-Only
Author
le Ben S.
Posted
3-Oct-2011 20:18 GMT
Toolset
ARM
New! RE: IRQ Not Firing

The interrupts work when I overwrite one of Keil's examples. When I started the project, a wizard ran in Keil that placed the startup_LPC17xx.h file. I manually placed the startup_LPC17xx.c from the startup directory otherwise I would not be able to call anything. Is there anything I should have done differently here?

Read-Only
Author
le Ben S.
Posted
3-Oct-2011 20:21 GMT
Toolset
ARM
New! RE: IRQ Not Firing

I met to say the wizard placed the startup_LPC17xx.s file, not the the startup_LPC17xx.h file.

Read-Only
Author
Tamir Michael
Posted
3-Oct-2011 20:28 GMT
Toolset
ARM
New! RE: IRQ Not Firing

Don't waste your time. Run a diff between the projects and correct in your own sources.

Read-Only
Author
le Ben S.
Posted
3-Oct-2011 20:51 GMT
Toolset
ARM
New! RE: IRQ Not Firing

The projects contain older versions of the files. Merging them with mine will cause other problems. Is there a document that says how to properly create a project so that everything will function properly?

Read-Only
Author
Ben Satkiewicz
Posted
3-Oct-2011 22:35 GMT
Toolset
ARM
New! RE: IRQ Not Firing

Here is the project. I do not wish to rely on other projects just to allow interrupts to work. That startup file does contain definitions for all the IRQ service routines but they somehow are not linking. My entire project is available for download here:

http://www.filedropper.com/firmware

So how can you properly configure this simple project?

Read-Only
Author
Ben Satkiewicz
Posted
4-Oct-2011 01:47 GMT
Toolset
ARM
New! RE: IRQ Not Firing

OK, here is the lowndown:

The most recent version of the files do not work! The core_cm3.c file version 1.20, the LPC17xx.c 1.10, the system_LPC17xx.c 1.01, and the startup_LPC17xx.s 1.0 are the combination of the files that work. There is either something very wrong with the new files or I am missing something.

Should I use the old files or do any of you know how to make the new ones work?

Read-Only
Author
Andrew Neil
Posted
4-Oct-2011 09:03 GMT
Toolset
None
New! RE: Should I use the old files ?

You could compare them against the "new" files - and spot the differences.

http://winmerge.org/

You could step through with the "old" files to see what happens when it is working, then do the same with the "new" files - and see where it stops...

Read-Only
Author
Ben Satkiewicz
Posted
4-Oct-2011 11:04 GMT
Toolset
None
New! RE: Should I use the old files ?

There are differences, more in some of the files than the others. I could not find based upon these differences what was causing the malfunction.

Also, stepping through the files does not work as the debugger just stops and does not specify where it stopped at. What now?

Read-Only
Author
Tamir Michael
Posted
4-Oct-2011 11:13 GMT
Toolset
None
New! RE: Should I use the old files ?

Any chance you'll be posting your diff report here, caring to do so using the proper format specifiers?

Read-Only
Author
Ben Satkiewicz
Posted
4-Oct-2011 11:17 GMT
Toolset
None
New! RE: Should I use the old files ?

What do you mean by diff report?

Read-Only
Author
Tamir Michael
Posted
4-Oct-2011 11:18 GMT
Toolset
None
New! RE: Should I use the old files ?

Any diff tool out there ,including Winmerge, can save the result to a file.

Read-Only
Author
Andrew Neil
Posted
4-Oct-2011 11:21 GMT
Toolset
None
New! RE: What do you mean by diff report?

"Diff" here is short for "Difference" - ie, the report of the differences between the files.

Read-Only
Author
Ben Satkiewicz
Posted
4-Oct-2011 11:51 GMT
Toolset
None
New! RE: What do you mean by diff report?

Here is the report for each file:

http://www.filedropper.com/differencereport

Read-Only
Author
le Ben S.
Posted
4-Oct-2011 14:12 GMT
Toolset
None
New! RE: What do you mean by diff report?

When I debug with the latest files, the debugger hangs and the t1: field keeps increasing. When I click the stop button, the yellow arrow appears pn the line with a B assembly statement (see screenshot). Does this say anything?

http://imageshack.us/photo/my-images/585/unledufa.png/

Read-Only
Author
Per Westermark
Posted
4-Oct-2011 14:22 GMT
Toolset
None
New! RE: What do you mean by diff report?

Infinite loop branching to itself.

Your interrupt handling must map in an access to your ISR from the relevant interrupt vector. Does your startup file do that?

Read-Only
Author
le Ben S.
Posted
4-Oct-2011 14:25 GMT
Toolset
None
New! RE: What do you mean by diff report?

How can I tell? I would think that the startup file would take care of that.

Read-Only
Author
Per Westermark
Posted
4-Oct-2011 15:01 GMT
Toolset
None
New! RE: What do you mean by diff report?

There is a reason why an embedded developer should have at least some knowledge about assembler for the target architecture. The way to tell is to locate the interrupt vectors in the startup file, and then follow the path until you either get to your ISR, or somewhere you do not want to reach - like your infinite branch.

The datasheet for your processor - actually "User Manual" is the name NXP users - does a good job of telling you where the interrupt vectors are.

Another thing you really have to know about is the difference between single-stepping C source code and single-stepping processor instructions. It is possible to single-step in the startup file too. It's your single-stepping source lines (which indirectly means that the compiler sets a breakpoint on the next source line) that have had you not notice the infinite loop until now. When suspecting interrupt problems, it's often needed to perform instruction-level single-stepping.

Read-Only
Author
le Ben S.
Posted
4-Oct-2011 15:05 GMT
Toolset
None
New! RE: What do you mean by diff report?

I use the startup file provided with Keil. Do they want me to set up the routines manually?

Read-Only
Author
Ben S.
Posted
4-Oct-2011 15:46 GMT
Toolset
ARM
New! Interrupt Blues

I just don't understand. In the example projects the interrupts work, and the startup and configuration files are no different (I looked at examples using the most recent files too). Im stuck and I seriously doubt I am doing anything wrong as I cannot figure out from the examples.

Thanks,
Ben

Read-Only
Author
Per Westermark
Posted
4-Oct-2011 15:52 GMT
Toolset
ARM
New! RE: Interrupt Blues

Note that the NVIC function does not name the ISR. The mapping to ISR is just by having the correct name of the ISR in relation to the startup file. And any ISR not supplied by you have a default ISR supplied during linking.

So what did you find out when you single-stepped through the startup file? When your ISR was not called - what other function was called? Was it just a question of Keil having changed the default name for the ISR function?

Read-Only
Author
Ben S.
Posted
4-Oct-2011 16:13 GMT
Toolset
ARM
New! RE: Interrupt Blues

Stepping through the startup file only just initializes the reset handler and the stack heap. Then it jumps into the infinate loop that is supposed to be the interrupt (the B instruction).

Read-Only
Author
Ben S.
Posted
4-Oct-2011 16:20 GMT
Toolset
ARM
New! RE: Interrupt Blues

It appears as if the default ISR was called.

Read-Only
Author
Ben S.
Posted
4-Oct-2011 16:39 GMT
Toolset
ARM
New! RE: Interrupt Blues

OK I figured it out. I am using C++ and this forum posting delivered the answer I was looking for. It talks about how the overloading of C++ functions could cause weak references to the intrrupt handlers.

http://electronics.stackexchange.com/questions/7660/bug-in-keil-arm-compiler-with-interrupt-handlers-and-c

All I have to do is put a wrapper around the interrupt functions and that fixes it.

extern "C"
{ ... Interrupt Functions.
}

Is there a better way of doing this or do you always need the wrapper when using C++?

Read-Only
Author
Per Westermark
Posted
4-Oct-2011 16:49 GMT
Toolset
ARM
New! RE: Interrupt Blues

No, C++ does not cause weak references to interrupt handlers.

But C++ uses name mangling, which means the external name the linker sees contains extra characters encoding the returned data type, and the parameter list.

So a C++ file with a function void hello(void) will not let the linker see a function "hello". You don't need to use the braces to wrap. Standard C++ documentation tells you that you can specifiy directly for the function that it should use the C calling convention and have C bindings.

Read-Only
Author
John Linq
Posted
5-Oct-2011 02:44 GMT
Toolset
ARM
New! RE: Interrupt Blues

If I Recall/Remember Correctly,
For Cortex-M3, or I should say NXP LPC17xx,
There are two kind of Keil examples,
1. Older, not CMSIS style; it has two important source files; startup_LPC17xx.s, system_LPC17xx.c
2. Newer, CMSIS style; it has three important source files; startup_LPC17xx.s, system_LPC17xx.c, core_cm3.c
Newer Keil MDK provides the CMSIS style source, startup_LPC17xx.s, system_LPC17xx.c, core_cm3.c.
If you mix-up the [not CMSIS style source] with [CMSIS style source], you will have some problems to fix.

Read-Only
Author
John Linq
Posted
5-Oct-2011 03:25 GMT
Toolset
ARM
New! RE: Interrupt Blues

In your Difference Report->system_LPC17xx_c.htm

Left:

#define PLL0CFG_Val           0x0000000B


Right:

#define PLL0CFG_Val           0x00050063
Read-Only
Author
John Linq
Posted
5-Oct-2011 03:29 GMT
Toolset
ARM
New! RE: Interrupt Blues

As per your Difference Report, I believe that
If you mix-up different versions of the [CMSIS style source], you will have some problems to fix.

Read-Only
Author
Andrew Neil
Posted
5-Oct-2011 07:55 GMT
Toolset
ARM
New! RE: There are two kind of Keil examples

There are also examples from NXP

I don't know, but I would not expect arbitrary files taken from NXP examples to "just work" with Keil examples - or vice-versa.

Next Thread | Thread List | Previous Thread Start a Thread | Settings

  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.