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
http://www.wescottdesign.com

Le 28/05/2015 19:15, Tim Wescott a écrit :
> 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.
>
What about the interrupt vector?

On Thu, 28 May 2015 19:21:35 +0200, Lanarcam wrote:

> Le 28/05/2015 19:15, Tim Wescott a écrit :
>> 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.
>>
> What about the interrupt vector?

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
http://www.wescottdesign.com

On Thu, 28 May 2015 12:15:43 -0500, Tim Wescott wrote:

> 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.

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
http://www.wescottdesign.com

On 28.5.15 21:18, Tim Wescott wrote:
>
> 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.


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