Reply by Paul Claessen May 4, 20082008-05-04
I have to agree with Robert's comment!

ISR's should be kept as short as possible. Doing all those function calls there, even printf's!, is a huge no no.
Indeed: check your IRQ stack size!

Better yet, in your ISR, JUST set a flag, indicating that an interrupt occured. That's all.
Then do all the work in you while(1) loop, where you check for this flag to be set.
If your interrupt rate is high, you make use a counter instead of a flag (to detect missed interrupts).
Don't forget to disable interrupts when decrementing that counter (or resetting the flag).
(and don't forget to enable them again after that ;-)

~ Paul Claessen

An Engineer's Guide to the LPC2100 Series

Reply by Robert Adsett May 3, 20082008-05-03
> voltx=(float)read_adc(3); //gia toc theo truc x
> volty=(float)read_adc(2); //gia toc theo truc y

I don't know if this is your problem but it is at best a questionable thing
to do. Floating point often needs special care to be re-entrant (if it can
be made so at all).

>
> dat_count++;
> count++;
> if(count==somau)
> {count=0;}
>
> if (dat_count==somau)
> {
> dat_count=0;
> printf("\ngia toc theo truc x press read
> pin\n");

And this moves from the questionable to the foolish. At best you risk
using up all of your ISR time on character output. You haven't said what
your IRQ stack is but the odds are very high you've gone past the end by a
substantial amount. Not to mention all the re-entrancy issues it raises.

Robert
http://www.aeolusdevelopment.com/
Reply by hbaocr May 3, 20082008-05-03
here the entire of code

Reply by Paul Claessen May 3, 20082008-05-03
> Interrupt code must be in ARM code - sounds like you are trying to compile your IRQ code in Thumb mode.

Neither ARM nor THUMB allows instructions on an odd byte boundary.
Nor will any compiler generate misaligned code.
I bet this is a stack corruption problem.

~ Paul Claessen
Reply by Paul Claessen May 3, 20082008-05-03
"my uc LPC2214 it only output through UART port 2 times and stand by,don't do anything untilI reset uC LPC2214."

Oh yes, it is doing something! I bet it's sitting in a tight loop in your prefetch abort routine ;-)

Anyway, the information you provided is not enough. Upload your entire source file(s).
I bet a nickle you're stomping on your stack, probably overwriting a return address.

Btw, how can you use buffer_tem_array1 as an argument in a FIR_LPF() call, when buffer_term_array1 is defined in FIR_LPF()?
That looks very fishy...
Also: "int buffer_temp_array1[11] = {0};" only initializes the first array entry to 0, probably not what you meant. (And since it appears to be a local (= stack) variable, the compiler or __main() isn't going to initialize it).
And while it probably doesn't matter, why not do the moves in your while(1) loop only when 'index' changes? Makes for cleaner code.

Upload that file!

~ Paul Claessen
Reply by hbaocr May 3, 20082008-05-03
> Interrupt code must be in ARM code - sounds like you are trying to compile your IRQ code in Thumb
> mode.

can you explain to me more details about Arm code on C instead of
thumb code on keil c ,how can i do it.please give me some example code
Reply by Mike Harrison May 3, 20082008-05-03
Interrupt code must be in ARM code - sounds like you are trying to compile your IRQ code in Thumb
mode.
Reply by hbaocr May 3, 20082008-05-03
thank for attension on my problem at LPC2000 yahoogroup!
i'm using LPC2214 to collect data form ADC chanel control and store it
in the ARRAY data by timer interrupt match each 1ms.That means I
samples sample per 1 milisecons.And after 50milisecond I genearate all
50 collected data in ARRAY to PC through UART port.but I have problem
that is "Non-aligned Access: Thumb Instruction at 00000674H, Memory
Access at 000009EBH"
when run in simulation by Keil C.
And when I load the HEX file of that code into my uc LPC2214 it only
output through UART port 2 times and stand by,don't do anything until
I reset uC LPC2214.
what can I do to solve that problem
here are code



Please show me how I can solve that problem !thank you verry much.