Skip to main content
Electrical Engineering

Return to Question

Tweeted twitter.com/#!/StackElectronix/status/103230677792735232
just updated the part and compiler details..
Source Link
Frank
Frank
  • 2.9k
  • 5
  • 32
  • 38

I have a simple program basically increment the counter every time I get an interrupt. The code is something like this:

void ISR(void) { static int counter=0; counter++; GPIO_SET(PIN1); // set the gpio pin DELAY(10); // some short delay so that we can see it in scope nicely GPIO_RESET(PIN1);//reset the pin clearFlag(); }

The event (actually it is a timer) that triggers this ISR also triggers some other stuff (DMA, basically every 8 event I should get a DMA interrupt, this is by design of the code)

In the DMA ISR code, I have another GPIO pin set/reset. Now:

  • When I look at the events (timer output on a pin and DMA toggle), on the scope I see 8 events correspond to each DMA cycle. So far so good.

  • When I look at the PIN1 at the scope, I only see 6 events two of them are lost and this is very consistent, always the same 2.

I don't have anything that takes very long time in the ISR and I am puzzled by the fact that ISR routine is not get called every time I get the event.

I am hoping this is a set up issue on my side, any ideas where to look. This is something so basic that it should just work. This is a new processor from ST, therefore there is a chance that it is a bug but I am kind of refusing to believe something this basic is not working.

The part is new STM32F2.. Compiler is Crossworks.. No optimizations, debug code.. run off the mill settings, nothing fancy.

I am really looking for a pointer to where to look.. Not hoping you guys would debug for me.. What would cause this? Under different circumstances I would assume timing of the ISR is the issue but I disable the ISR code with #if 0 to avoid these timing issues.. So, it is not timing.. What else it could be?

I have a simple program basically increment the counter every time I get an interrupt. The code is something like this:

void ISR(void) { static int counter=0; counter++; GPIO_SET(PIN1); // set the gpio pin DELAY(10); // some short delay so that we can see it in scope nicely GPIO_RESET(PIN1);//reset the pin clearFlag(); }

The event (actually it is a timer) that triggers this ISR also triggers some other stuff (DMA, basically every 8 event I should get a DMA interrupt, this is by design of the code)

In the DMA ISR code, I have another GPIO pin set/reset. Now:

  • When I look at the events (timer output on a pin and DMA toggle), on the scope I see 8 events correspond to each DMA cycle. So far so good.

  • When I look at the PIN1 at the scope, I only see 6 events two of them are lost and this is very consistent, always the same 2.

I don't have anything that takes very long time in the ISR and I am puzzled by the fact that ISR routine is not get called every time I get the event.

I am hoping this is a set up issue on my side, any ideas where to look. This is something so basic that it should just work. This is a new processor from ST, therefore there is a chance that it is a bug but I am kind of refusing to believe something this basic is not working.

I have a simple program basically increment the counter every time I get an interrupt. The code is something like this:

void ISR(void) { static int counter=0; counter++; GPIO_SET(PIN1); // set the gpio pin DELAY(10); // some short delay so that we can see it in scope nicely GPIO_RESET(PIN1);//reset the pin clearFlag(); }

The event (actually it is a timer) that triggers this ISR also triggers some other stuff (DMA, basically every 8 event I should get a DMA interrupt, this is by design of the code)

In the DMA ISR code, I have another GPIO pin set/reset. Now:

  • When I look at the events (timer output on a pin and DMA toggle), on the scope I see 8 events correspond to each DMA cycle. So far so good.

  • When I look at the PIN1 at the scope, I only see 6 events two of them are lost and this is very consistent, always the same 2.

I don't have anything that takes very long time in the ISR and I am puzzled by the fact that ISR routine is not get called every time I get the event.

I am hoping this is a set up issue on my side, any ideas where to look. This is something so basic that it should just work. This is a new processor from ST, therefore there is a chance that it is a bug but I am kind of refusing to believe something this basic is not working.

The part is new STM32F2.. Compiler is Crossworks.. No optimizations, debug code.. run off the mill settings, nothing fancy.

I am really looking for a pointer to where to look.. Not hoping you guys would debug for me.. What would cause this? Under different circumstances I would assume timing of the ISR is the issue but I disable the ISR code with #if 0 to avoid these timing issues.. So, it is not timing.. What else it could be?

Source Link
Frank
Frank
  • 2.9k
  • 5
  • 32
  • 38

ISR - Scope vs. Counter

I have a simple program basically increment the counter every time I get an interrupt. The code is something like this:

void ISR(void) { static int counter=0; counter++; GPIO_SET(PIN1); // set the gpio pin DELAY(10); // some short delay so that we can see it in scope nicely GPIO_RESET(PIN1);//reset the pin clearFlag(); }

The event (actually it is a timer) that triggers this ISR also triggers some other stuff (DMA, basically every 8 event I should get a DMA interrupt, this is by design of the code)

In the DMA ISR code, I have another GPIO pin set/reset. Now:

  • When I look at the events (timer output on a pin and DMA toggle), on the scope I see 8 events correspond to each DMA cycle. So far so good.

  • When I look at the PIN1 at the scope, I only see 6 events two of them are lost and this is very consistent, always the same 2.

I don't have anything that takes very long time in the ISR and I am puzzled by the fact that ISR routine is not get called every time I get the event.

I am hoping this is a set up issue on my side, any ideas where to look. This is something so basic that it should just work. This is a new processor from ST, therefore there is a chance that it is a bug but I am kind of refusing to believe something this basic is not working.