search

STMicroelectronics / iis3dwb-pid

iis3dwb platform independent driver based on Standard C language and compliant with MISRA standard
BSD 3-Clause "New" or "Revised" License
12 stars 9 forks source link

SPI issue with STM32CubeH7 MCU Firmware Package v1.11.1 #18

Open escherstair opened 10 months ago

escherstair commented 10 months ago

I've just discovered that even if iis3dwb driver works well with STM32H7 if MCU Firmware Package is v1.10.0, after I upgraded the firmware packgae to v1.11.1 - and no other change to my source code - iis3dwb device started having some issues on the SPI communication. Basically, there are some conditons that stops then device from answering on the SPI. One of them is using another SPI peripheral on the MCU to write into an external EEPROM.

After my investigation, what happens is similar to the issue described STMicroelectronics/STM32CubeH7#249 but it's 10 months old and no patch has been provided.

I had to switch back to v1.10.0

avisconti commented 10 months ago

I've just discovered that even if iis3dwb driver works well with STM32H7 if MCU Firmware Package is v1.10.0, after I upgraded the firmware packgae to v1.11.1 - and no other change to my source code - iis3dwb device started having some issues on the SPI communication. Basically, there are some conditons that stops then device from answering on the SPI. One of them is using another SPI peripheral on the MCU to write into an external EEPROM.

After my investigation, what happens is similar to the issue described here but it's 10 months old and no patch has been provided.

I had to switch back to v1.10.0

Is it an ii3dwb issue or STM32CUBEH7?

escherstair commented 10 months ago

Is it an ii3dwb issue or STM32CUBEH7?

As far as I can see, this seems an STM32CUBEH7 issue (because it has changed, and iis3dwb driver has not changed), even if it's the iis3dwb that fails and doesn't work anymore. But maybe the iis3dwb is somwhow "weak" and when the FIFO is not read after is ready, the MEMS hangs. It's only my guess. I don't have any clear explanation for what happenes. If @avisconti can give additonal info, they're appreciated.

escherstair commented 8 months ago

After some investigation I have some news, and one question related to iis3dwb. I suspect that the new release of STM32CUBEH7 triggers some rare corner-case on my application.

I want to read samples continously without any "wake up" event, and so I configured iis3dwb in "continous mode: if the FIFO is full, the new sample overwrites the older one" (from the datasheet) - see page 31 of AN5444 application note. I use a watermark threshold for the FIFO, and I configured INT1 pin to give FIFO_FULL interrupt.

When I receive a FIFO_FULL interrupt I read all the samples. Is there any timeout in this read? What happens if (for any reason) I'm not able to read all the samples before the FIFO is overwritten? From what I see, it seems that no more FIFO_FULL interrupt is generated. Is there a way to detect this situation? Is there a way to recover from this?

avisconti commented 8 months ago

After some investigation I have some news, and one question related to iis3dwb. I suspect that the new release of STM32CUBEH7 triggers some rare corner-case on my application.

I want to read samples continously without any "wake up" event, and so I configured iis3dwb in "continous mode: if the FIFO is full, the new sample overwrites the older one" (from the datasheet) - see page 31 of AN5444 application note. I use a watermark threshold for the FIFO, and I configured INT1 pin to give FIFO_FULL interrupt.

When I receive a FIFO_FULL interrupt I read all the samples. Is there any timeout in this read? What happens if (for any reason) I'm not able to read all the samples before the FIFO is overwritten? From what I see, it seems that no more FIFO_FULL interrupt is generated. Is there a way to detect this situation? Is there a way to recover from this?

Yes, of course. If a new FIFO_FULL interrupt is generated during the previous handling you may lose it and block everything. To prevent this, I guess you better set a WTM and uses FIFO_WTM_IA interrupt.

escherstair commented 8 months ago

Sorry for my bad explanation when I wrote:

I use a watermark threshold for the FIFO, and I configured INT1 pin to give FIFO_FULL interrupt.

I mean that I set a watermark (WTM) and so I configured INT1 to give FIFO_WTM_IA interrupt (when I wrote FIFO_FULL I meant WTM_FULL, since I use WTM).

But if I'm too slow in reading samples, is there a risk of blocking everything in this case too? Is there a way to detect and/or recover from this?