ARM Cortex M4, STM32F303VCT6, Interrupts not working

OK. I've got decades of experience in the embedded space and I should be able to do this without whining for help here -- but I'm at the "bash your head against the wall until some bricks give way" stage of this problem and I'm starting to go in circles. I'm hoping that someone happens to know an answer, or will give me some suggestion that helps me find my way.

I've got a project that uses the STM32F303VCT6, and for some unknown reason, I'm not getting interrupts to work right. I suspect that there's some sort of a race condition at play, because it's worked for me exactly once, and then not again. There's a chance that there's some magic "screw the processor bit" that I'm not setting, too, but this is the fourth ARM Cortex core I've worked with, and it's the first one I've had this trouble with.

What is doubly confusing is that I'm using code that has worked elsewhere, but it's not working on this processor. So there is, apparently, some magic finger ring decoder combination that I've accidentally dialed on this (or failed to).

The setup is an STM32F303VCT6 (100-pin package with a Cortex M4, no FPU). I'm debugging with OpenOCD (although I don't think that matters), and compiling with gnu-arm (although again, I don't think that matters).

I've tried a number of different setups, only one of which has worked, and when I went back to that same setup it didn't work. So there's some straaaaange things going on here.

In the simplest implementation, I'm just trying to get the SysTick timer working. I do this by setting the countdown target, then setting the bottom three bits of the SYST_CSR register to '1'. From most to least significant bits this tells the thing to use its internal clock, interrupt on clock reloads, and to go.

This is _all I am doing_, which is enough to get the ball rolling on the two Cortex M3 and one Cortex M0 processors I've used.

Once I do this I can see the following:

I can look at the clock registers and I can verify that the clock is running and setting the "done" flag.

In the Interrupt Control and Status Register (ICSR) I can see that the PENDSTSET bit is set to 1, that the VECTPENDING field is 0x00f, indicating that a SysTick interrupt is pending, and I can see that the VECTACTIVE field is 0, indicating that the thing is in normal code.

It will stay like that _forever_, without ever actually executing the SysTick ISR.

I'm getting similar results when I put in code that uses TIM15, except, of course, the setup is different and the value of the ICSR register is different.

I'm mostly hoping that someone has run into something similar to this and knows of some "screw the processor" bit that I'm missing, or some timing constraint that I'm not meeting. But if you have other suggestions of where to look I'm open to them. Hopefully this isn't some fresh-out-of- school mistake, but God only knows, I've been flogging this issue for days and haven't made much forward progress.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott
Loading thread data ...

What about the interrupt vector?

Reply to
Lanarcam

It's pointing to the correct code: I checked. Even if I've miscounted and it's pointing to the wrong code I've got the thing set up so that all of the unused interrupts point to an unused interrupt ISR. If I had the vector table messed up the interrupt would still get serviced.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

Well, either I have entered a strange land where every time a system has powered up it works differently (I believe it's called an "engineering lab"), or it's a @#$% compiler problem.

The magic finger ring decoder combination that I missed was how to properly query for the status of the primask bit using OpenOCD -- apparently it only works correctly when the processor is halted.

I have some code that's interrupt-protected, and my optimizing compiler appears to be looking at my interrupt flag restore code, seeing the "asm" statement, and saying "Well, this is bullshit, I won't put it in".

So I will be asking _in a separate thread_ about that. Please consider this thread dead.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

That's correct from the compiler's viewpoint. Please tell him that the statement is needed, even if it seems to do nothing useful, by using the volatile qualifier on the asm statement.

The proper spell is 'asm volatile' or '__asm__ volatile'.

When compiling code I'm not quite sure of, I always use the assembly listing switches '-Wa,-ahlms=myfile.lst'.

--

-TV
Reply to
Tauno Voipio

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.