LCP1769 - double the interrupts in release

lpcware · ‎06-15-2016

Content originally posted in LPCWare by beharrell on Mon Apr 25 12:32:17 MST 2011
Hi all,
I'm kind of lost on this one and hope you can help. I wrote a simple app for the LCP1769 to count interrupts received during a time period.
I do this by using the match registers for timers 2 & 3 to toggle pins 0.6 and 0.10 every 0.5 and 0.25 seconds respectively.
I hook these pins to external interrupt 0(the slow toggling pin) & 1 (the fast toggling pin), where each handler is fired on the falling edge. The interrupt handler for 1 increments a counter, the handler to 0 calcs the difference in the counter since it was last called. I print the resultant difference in a loop in main (semi hosting).

When I'm debugging I see a value of 2 (as I would expect), when I run in release I see a value of 4.
I've modifed the handler for ext int 1 with a busy wait for ~3mSec when in release before re-enabling the interrupt to try to rule out noise in the curcuit - this made no difference.

Can anyone suggest what the problem may be?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by beharrell on Sun May 01 16:47:11 MST 2011

Quote: larryvc
Might be noise in your circuit. Have you scoped it? Do you have soldered leads or just jumper wires? Grounds OK?

The errors I'm seeing are counts off by multiples of two and constant - This is a home project and I have no scope - tweeking board layout does not change things.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Sun May 01 16:00:39 MST 2011

Quote: beharrell

Now, when I'm working on the project and I see an unexpected number of interrupts, I'm left wondering if its simply because interrupt handling for the platform is not working the way it should.

Might be noise in your circuit. Have you scoped it? Do you have soldered leads or just jumper wires? Grounds OK?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by beharrell on Sun May 01 13:03:34 MST 2011

Quote: beharrell
I admit I have a low confidence (it's my first experience) in this platform (LCP1769 + LPCXpresso).

I have low confidence in the platform - I'm reading pixels off a camera and sending the frame out via ethernet (UDP).

I have it running in debug at a frame per second - but wanting better than this, I increased by clock rate and used release version. Thats when I started seeing double interrupts - so I reduced the problem to what I posted.

Now, when I'm working on the project and I see an unexpected number of interrupts, I'm left wondering if its simply because interrupt handling for the platform is not working the way it should.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Sun May 01 12:20:57 MST 2011

Quote: beharrell
I admit I have a low confidence (it's my first experience) in this platform (LCP1769 + LPCXpresso).

Low confidence in your current level of knowledge or low confidence in LPC1769 and LPCXpresso?:confused:

Larry

lpcware · ‎06-15-2016

Content originally posted in LPCWare by beharrell on Sun May 01 11:17:21 MST 2011
Thanks to Zero's suggestion I'm having a shot at my original project which uses an external interrupt source with a high clocking rate. However, still not understanding why the problem exists or why the solution works - I admit I have a low confidence (it's my first experience) in this platform (LCP1769 + LPCXpresso).

I appreciate the help Larry and Zero have given me - purhaps CodeRedSupport or NXP_USA can also comment on the double interrupt issue?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by beharrell on Sun May 01 11:12:14 MST 2011
Thanks to Zero's suggestion I've moved back to my original project which uses an external interrupt source with a high clocking rate. However, still not understanding why the problem exists or why the solution works - I admit I have a low confidence in this platform (LCP1769 + LPCXpresso) - it's my first experience with it.

I appreciate the help Larry and Zero have given me - purhaps CodeRedSupport or NXP_USA can also comment on the double interrupt issue?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Thu Apr 28 22:57:16 MST 2011
Your welcome. I thought you might want to do something about that. I know it didn't have anything to do with the interrupt problem but had to say something.

I was sitting here trying to figure out if you had seen my post or not as it was on a forum default page boundary. I saw your reply to Zero and figured you might have missed it. I was about to post a referral to that post and noticed you looking at the thread again. Cosmic consciousness?:rolleyes:

I would like to know the [COLOR=red]why[/COLOR] about the interrupts as well.

Regards,
Larry

lpcware · ‎06-15-2016

Content originally posted in LPCWare by beharrell on Thu Apr 28 22:35:21 MST 2011

Quote: larryvc
You might want to pick a different GPIO other than p2.10. That pin is used to put the LPC1769 into ISP mode. It is very useful if you mess up your chip settings and can't connect to the debugger.

See this:

http://support.code-red-tech.com/CodeRedWiki/DebugAccessChip

Ahh, that may be why I've been having some other issues - 6.2.6 (p22) of the "Getting started with NXP LPCXpresso" gives instructions to gound pin 0.1 (makes no mention of 2.10 for 1769) - thanks for that.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by beharrell on Thu Apr 28 22:17:37 MST 2011

Quote: Zero
Try to clear your interrupts earlier:

void EINT1_IRQHandler (void)
{
[COLOR=red] LPC_SC->EXTINT = EINT1_CLR;[/COLOR]
 frameCount++;
 prevPixelsPerFrame = pixelsPerFrame;
 pixelsPerFrame = pixelCount - oldPixelCount;
 oldPixelCount =  pixelCount;
}
 
void EINT0_IRQHandler (void)
{
[COLOR=red] LPC_SC->EXTINT = EINT0_CLR;[/COLOR]
 pixelCount++;
}

Hi Zero, thanks for the suggestion - clearing the interrupt as soon as I enter the interrupt handler does seem to "solve" the "double interrupt problem" in release mode.

But [COLOR=red][U]why[/U][/COLOR] does the early clearing of the interrupt stop the apparent doubling of interrupts when in release mode? - to the best of my understanding this makes no sense!

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Thu Apr 28 12:28:02 MST 2011
You might want to pick a different GPIO other than p2.10. That pin is used to put the LPC1769 into ISP mode. It is very useful if you mess up your chip settings and can't connect to the debugger.

See this:

http://support.code-red-tech.com/CodeRedWiki/DebugAccessChip

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Thu Apr 28 09:30:46 MST 2011
Try to clear your interrupts earlier:

void EINT1_IRQHandler (void)
{
[COLOR=Red] LPC_SC->EXTINT = EINT1_CLR;[/COLOR]
 frameCount++;
 prevPixelsPerFrame = pixelsPerFrame;
 pixelsPerFrame = pixelCount - oldPixelCount;
 oldPixelCount =  pixelCount;
}

void EINT0_IRQHandler (void)
{
[COLOR=Red] LPC_SC->EXTINT = EINT0_CLR;[/COLOR]
 pixelCount++;
}

lpcware · ‎06-15-2016

Content originally posted in LPCWare by beharrell on Thu Apr 28 03:13:30 MST 2011

Quote: CodeRedSupport

And you aren't using "Quickstart -> Debug" why?
.

Thanks for all the advise - appreciate it.

I did'nt use "Quickstart->Debug" because I wanted to run the application (rather than debug it) - looked though all the menu options and figured " Run as .... C/C++ mcu application" was the best way to do that?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by beharrell on Thu Apr 28 03:03:07 MST 2011

Quote: larryvc
Also what version of LPCXpresso are you using? Older versions did not provide debug info for release builds and that may be the problem above.

And on what OS?

I'm using LPCXpresso V3.6.2 Build 279 on Windows 7

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Thu Apr 28 02:55:22 MST 2011

Quote: beharrell

external interrupts do not seem to get handled during printf (Redlib semihost) - I've put in a busy wait in the main loop to hide this problem

Doing a semihosted printf within the main loop of a program which is basically interrupt driven is not a good idea, and will certainly mess with your interrupt behaviour. Suggest you take a look at the following FAQ...

http://support.code-red-tech.com/CodeRedWiki/UsingPrintf

Quote:

With Release set as the active build configuration,

Clean project followed by Run as .... C/C++ mcu application actually runs the debug version of the application NOT release.

And you aren't using "Quickstart -> Debug" why? This would at least then allow you to do some debugging! I suspect that the reason that you see "Run as" running the debug version is because that is the version you chose to execute the first time you used the "Run as" option.

With regards to debug information, you might find it useful to enable this for the Release build using:

Project -> Properties -> C/C++ build -> Settings -> MCU C Compiler -> Debugging -> Debug level

and set this drop down to "Maximum".

Finally for future reference I would suggest exporting projects for attaching to the forum as per:

http://support.code-red-tech.com/CodeRedWiki/ImportExport

Regards,
CodeRedSupport.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Thu Apr 28 02:09:19 MST 2011
Also what version of LPCXpresso are you using? Older versions did not provide debug info for release builds and that may be the problem above.

And on what OS?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Thu Apr 28 01:47:26 MST 2011
There are several issues with your project settings. The most glaring one is that when you run the debugger on the debug version the debugger displays and follows the source code of main(). When running the debugger on the release version there is no source code for the debugger to follow.

I did get 4 interrupts in release and 2 in debug if I let the debugger free run.

It's really late here now and I think that CodeRedSupport or someone else with more experience than I have, with setting up the project settings, will have to help you from here. They can also give you some pointers on exporting projects as well so you can conserve space.

This is a strange problem, one that I would like to see the fix for.

Regards,
Larry

lpcware · ‎06-15-2016

Content originally posted in LPCWare by beharrell on Thu Apr 28 00:46:58 MST 2011
I've attached the a zip file containing the workspace for a project that duplicates the above problem + a "wiring diagram".

What I've found so far is
[LIST=1]
[*]external interrupts do not seem to get handled during printf (Redlib semihost) - I've put in a busy wait in the main loop to hide this problem
[*]With Release set as the active build configuration,[LIST=1]
[*]Clean project followed by Run as .... C/C++ mcu application actually runs the debug version of the application NOT release.
[/LIST]
[/LIST]I'm still no the wiser as to why I get 4 interrupts in release and 2 in debug! I'd appreciate any insight you can give me.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by beharrell on Tue Apr 26 12:44:02 MST 2011
I am in the process of removing unexecuted code (it is part of a bigger project) - will post the project as soon as done. What I've found so far is if I clean the project and do a build the problem appears to go away - however, if I do successive builds without an intermediate clean the double interrupt problem appears......

lpcware · ‎06-15-2016

Content originally posted in LPCWare by larryvc on Mon Apr 25 13:29:38 MST 2011

Quote: beharrell

Can anyone suggest what the problem may be?

We will probably need to see the code and circuit diagram to be able to make any suggestions.

Since it only seems to be test code you could export the project and attach it in a post for us to review.