stm32 release mode not reading spi device correctly, but debug mode works perfectly

[npreiser]

I am using a STM32L031F6P6 device, with a microchip port expander:  MCP23S17,  off the SPI 

bus.    I am using the device in interrupt mode, so when a gpio changes state, it sets its int line, which is tied 

back to my stm part.   In my int handler, all I do is set a flag, which is then picked up in the main loop.  

If the flag is set,  the main loop will then perform a read of the gpio device to get the port value..etc.  

All of this worker 100% perfectly when I compile my app for DEBUG.  However, when I compile it under 

release it is not working, the values read from the port expander are bad.  

Here is what I can confirm: 

all of the variables used in the INT hander/main loop are Volatile.

Both serial(rs232 ) and SPI are working correctly under both release and debug.  

I have other spi gpio devices on the same spi bus that are "outputs" that are working fine.  

I have tested the same code under both STCube IDE  environment and the VScode (cmake) env...same exact result. 

Has anyone ran  into this before??,  It appears like there is something in the ST spi driver code that maybe timing related,,,?..  thanks .  

[Andrew Neil]

For a start, look at what's different between your Debug & Release configs.

Most likely, the compiler optimisation differs.

When compiler optimisation breaks your code, it's generally a sign of coding flaws.

---

@npreiser wrote:

all of the variables used in the INT hander/main loop are Volatile.

---

That is, of course, necessary - but it's not sufficient.

eg, It won't protect against race conditions; it doesn't guarantee atomic access.

---

@npreiser wrote:

Both serial(rs232 ) and SPI are working correctly under both release and debug.  

---

How have you verified that?

---

@npreiser wrote:

It appears like there is something in the ST spi driver code that maybe timing related,,,?..  thanks .  

---

More likely something in your code ...

[npreiser]

Thanks @Andrew Neil 

When I said spi driver, I meant the driver code for the mcp part which uses the hal underneath. most of that code I grabbed of the internet and has been working for years in other projects. 

I confirmed rs232 is working fine via comms with a host computer,  I am able from a host pc to send down commands vis rs232 to stm,  have them interpreted, and my program will then apply those commands to some other gpio on board that is also spi(output).   This is all under release.   

The problem is isolated  to just reading of the gpio port expanders after the int.  It has to be some kind of race condition in the mcp driver code ... :)     

[Andrew Neil]

But how have you proved that the SPI is working?

Have you used an oscilloscope and/or logic analyser to see what's actually happening on the wires ?

---

@npreiser wrote:

 when I compile it under release it is not working, the values read from the port expander are bad.  

---

So are they bad on the wire, or is your code is not managing to correctly interpret them?

[npreiser]

that was my next move,  bust out my logic analyzer...  and check on the read side...  

I'll post results when I get them ,  thanks , 

[npreiser]

Thanks for your help I got it working: 

There were 2 issues I found after attaching logic analyzer.

1.  I was running my spi clock to fast for  the part.

2.  Variable returned by my function was getting lost on the stack, 

[Andrew Neil]

Excellent.

If that resolved the issue, please mark he solution:

https://community.st.com/t5/community-guidelines/help-others-to-solve-their-issues/ta-p/575256