Interrupts don't trigger on new board with same code

[kuhnzaga]

Posted on August 08, 2011 at 17:33

Our STM32 chip isn't taking interrupts after a normal power reset, or a pin reset... but it will when it's in debug mode, or when (accidentally) Vdd was shorted after startup.

We recently respun the board with our ARM chip to insert output buffers and reduce EMC susceptibility. All of the power and control pins are the same as before. We did have a 4k pull-down on the BOOT pin, but we removed that to short right to ground.

We're running the same code as before, but now our interrupts aren't being triggered... I would imagine it's a hardware problem, but I can't figure out what's different.

Anyone having any ideas? I'm not terribly code-savvy, but I'll try to answer any questions about our program

#stm32-interrupts

[Tesla DeLorean]

Posted on August 08, 2011 at 18:44

Well step one would be to use a serial port to output diagnostic information, so you aren't dependent on what the JTAG debugger is doing to the system to get it in a semi functional mode. Don't assume that it is non-intrusive.

Understand, clearly, what the system is doing at start up. The clocks being enabled, the peripherals being brought up, and the order that is occurring in. Behaviour that differs between a hard and soft reset typically occur based on expectations on the initial conditions. Add instrumentation to examine peripheral and pin states, and then compare and contrast those between boots that work vs those that don't. As you check off things that are the same, and address those which are different, you may need to expand the scope of the instrumentation until you have a clear understanding of what's going on, and get a system which is stable/predictable.

[kuhnzaga]

Posted on August 08, 2011 at 21:36

we have a serial port sending debug information in all cases. I can get confirmation that the IRQ handler function is entered in JTAG, and in those special cases, but not after a pin reset.

There are also LEDs on the board which we are using to tell us whether we get the interrupts we are looking for

This is a curious problem because it seems that if I hold down the reset pin until about 150ms after power comes up, the interrupts work again. Any less than that and they don't work. 

I'm trying to find a software cure, but it's tough to understand why the software would work any differently due to this

[Tesla DeLorean]

Posted on August 09, 2011 at 01:36

Yeah, like you're not waiting for a clock to stabilize or a PLL to lock. If you have 5 or 12V supplies, you should wait for them to threshold, not just the 3V ones. Verify you don't have supply sequencing issues/dependencies.

Dump the peripheral registers, identify the differences, and what your external buffering has done. Bisect the problem, and identify the cause. Fudging the software works until you have component variations or you put devices in the field and people do stupid things with them.

[kuhnzaga]

Posted on August 24, 2011 at 17:51

I'm sorry to say I'm too much of a noob to really know how to do what you're suggesting. Are we talking about reading registers for the interrupt I'm waiting for?

I'm using the IAR environment for ARM, trying to figure out which commands I can insert to print relevant register settings. Do we think that the interrupts aren't being enabled?

[Tesla DeLorean]

Posted on August 24, 2011 at 18:08

No, I'm saying you need to understand the difference in the system's condition between cases where it works, and those in which it does not.

The symptom is the problem with the interrupts, the cause is something else, probably earlier in your start up and initialization of the system, or your expectations about clocks, supplies, etc.

[kuhnzaga]

Posted on August 24, 2011 at 18:37

Okay, I understand now. So I should stop searching for answers in the interrupts themselves. 

What are some registers you think I should be looking at?And thank you for all the help you've given so far, I know how much of a pain it usually is helping someone with such little prior knowledge. If there's documentation somewhere I should read up on, I'd love to hear where it is.

[kuhnzaga]

Posted on August 24, 2011 at 22:38

update: I've actually gotten the system to fail in debug mode, by doing a pin reset. This allowed me to view the registers during initialization of a failed run and a successful run. 

So far I am unable to see any difference in register values after pin reset (failure) and a watchdog reset (success) everywhere except in the RCC_CSR pin, which is obvious.Any suggestions for where else to look would be appreciated

[Tesla DeLorean]

Posted on August 24, 2011 at 23:53

The 150ms delay changing the situation suggests some external issue, perhaps the speed the supply rises, the external oscillators starting, or something resetting, or not.

If you have an external 8 MHz oscillator (HSE), an experiment might be to see if using HSI changes the issue. The registers live at 0x40000000, you could fish around there, or perhaps look at the RCC registers first. The manual has a register map, but you don't need to access them by name, more a matter of dumping a memory region. Look at what you do between the reset, and setting up the interrupt, and observing the problem. This might limit the number of peripherals and core functionality that might be involved.

[kuhnzaga]

Posted on August 29, 2011 at 20:57

I figured it out.

Evidently, when the interrupts are enabled by using the NVIC Init function, parts of the NVIC structure weren't included, and I guess taken as assumed values from startup. I defined the rest of the structures during initialization, and now nothing is left to assumption. Works perfectly.Thanks for your help