MCUXpresso breakpoint latency (LPC55xx)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MCUXpresso breakpoint latency (LPC55xx)

1,062 Views
ianbenton
Senior Contributor I

There's a lot going on here:

The A/D samples at 1600Hz (from the timer, from the 12MHz internal oscillator). The A/D interrupt routine processes the samples.

The routine called "Averages" runs on every mains zero crossing, and there is a breakpoint at the beginning of the routine.

It therefore follows that the A/D interrupt routine should have run 16 times since the Averages routine ran last time.

The A/D interrupt routine counter is in R2, and it is saved every time Averages is run. The results are shown in the memory pane at the right. In nearly every case the number is 16 (0x10), occasionally it is 15 and occasionally it is 17, which is to be expected.

However, the value in R2 when the breakpoint halts the processor is never 16, it is usually between 2 and 5. This suggests to be that the A/D interrupt routine has been called several times between the breakpoint being reached and the registers being displayed on the screen

Is this correct? How can I see the values of the registers at the exact instant that the program counter reaches the breakpoint?

Screenshot_2021-12-13_11-39-20.png

0 Kudos
5 Replies

1,005 Views
ianbenton
Senior Contributor I

The point is that the system behaves differently if the breakpoint is executed from how it behaves if the breakpoint is ignored.

It is very obvious that if the system does not halt at the breakpoint, the value of R2 is normally 16; but if the system halts at the breakpoint then the value of R2 can be as low as 4.

0 Kudos

995 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi,

I suggest you set a hardware break point and have a try.

xiangjun_rong_0-1641353931228.png

 

Then select the Hardware as fig.

xiangjun_rong_1-1641359557939.png

 

Hope it can help you

BR

XiangJun Rong

0 Kudos

1,055 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi, Ian,

Frankly speaking, I do not see your code, I suggest you post your C code and analog signal waveform so that we can know what your problem is.

Anyway, I suggest you enable FIFO watermark interrupt of ADC, in the ISR, you can read the sample to an array based on the FIFO counter in FCTRLa[FCOUNT]. Then check the array and determines if the samples are okay.

Hope it can help you

BR

XiangJun Rong

 

0 Kudos

1,036 Views
ianbenton
Senior Contributor I

The code is very clearly visible in the screenshot. There is no C code - it is written in assembler.

The analogue signal is from a zero-crossing detector, which gives a 500us negative-going pulse 100 times a second.

The reading of the samples works perfectly.

R2 contains the count of the number of samples since the previous zero crossing interrupt. It is saved in memory. The memory is shown at the right hand side of the screenshot.The sample count is nearly always 16, occasionally it is 15 and occasionally it is 17, but when the breakpoint interrupts at the same point at which R2 is stored in memory, the value in R2 is NOT 15, 16 or 17. WHY?

 

0 Kudos

1,011 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi,

You can insert the assembly code, you can compare the sampleCount variable with a immediate for example 14, if the sampleCount variable is greater than 14, execute nop. In the NOP instruction, set a break point, you can check the R2 register

BR

Xiangjun Rong

0 Kudos