Errata Sheet for IIS3DWB

[JMH]

I am an experienced embedded software engineer that needs some support and maybe has to add a problem report to the IIS3DWB device. Before I repeat anything already known I got following questions:

1. Is there an errata sheet for the ISS3DWB device?
2. Are there more than one chip revisions? I got an STEVAL-MKI1208V1K Eval Kit with some notable problems and another one which seems to feature only a few of them.
3. If there are different chip revisions, how do I differentiate them?

Thank you for your efforts in advance!

[Eleon BORLINI]

Hi @JMH​ ,

no, there aren't different version of IIS3DWB on the market, neither there is an errata sheet.

Can you please report the issue you found (or link here other post with same issues?

Could you also share the marking of the two device you tested, so that we can check the LOT dates and their time sequence?

-Eleon

[JMH]

Dear Mr. Borlini,

I am sorry, but even with a strong light and a magnifying lens I cannot read the markings on the IIS3DWB of the STEVAL-MKI1208V1K Eval Kit. The last line may read as "045" or so. The package of the STEVAL-MKI1208V1K Eval Kit bears the following Trace Code "XD205608" and Bulk ID "Z2R056080037".

Since I had to return the second borrowed Eval Kit I cannot state its markings.

The problems I encounter are very simliar to the problems mentioned in

https://community.st.com/s/question/0D53W00000Xi6tMSAR/iis3dwb-interrupt-stops-triggering-while-sampling-for-long-periods

I try to implement a high-perfromance data sampling based on an STM32H7, an SPI interface with DMA at 10MHz, the IIS3DWB in continuous mode, and FIFO Watermark/Threshold interrupts. The threshold is set to half the FIFO size (256 samples) and is the sole source of interrupts via INT1.

In the interrupt service routine I read the two FIFO status registers in one SPI transfer and check its contents. When the FIFO_WTM_IA is set and at least 256 samples are present, the FIFO interrupt is disabled and I start the read-out SPI/DMA transfer which lasts about 1.4ms. I planned to read out exactly 256 samples, but I also used the sample number in FIFO status registers.When the DMA end interrupt occurs, the data evaluation start is flagged and the FIFO interrupt is re-enabled.

So far so good, but often I get another FIFO interrupt almost immediately after re-enabling the FIFO interrupts. In this case, the FIFO_WTM_IA is not set and the number of samples present in the FIFO is about 40 samples which almost exactly corresponds to the 1.4ms at 26667Hz sampling frequency. I consider this interrupt "spurious" and if it occurs, it occurs only once between two "real" FIFO interrupts. It seems there is some race condition inside the chip that first clears the interrupt upon the readout of the FIFO status and sets it again, mayby when a new sample is entered before the FIFO SPI DMA transfer is started.

I am fairly certain that the described problem is real. Based on hypotheses about race conditions I tried some workaraounds, such as reading only the FIFO_STATUS_2 register, assuming that the race condition occurs inbetween the read-out of the two status registers. However, my IIS3DWB at this point ceased to work for unknown reasons. Another attempt would have been to entirely omit the read-out of the status registers and start the FIFO transfer in "blind trust" that 256 samples are present when the interrupt occurs. A detection of spurious interrupts was planned to be done on precision time measurements (256 samples last about 9.5ms to collect).

I also got a sporadic chip resets as mentioned in the other community post, so about 40000 FIFO DMA transfers. This problem, however, may be related on the prototype nature of the test installation. However, the power inputs of the eval boards were decoupled by extra capacitors of several µF in size an the eval board itself. This seemed to improve the behaviour and the time span between to chip resets became larger.

Currently I try to obtain a replacement for the now defunct STEVAL-MKI208V1K. One of my orders was cancelled by a distributor and I had to reorder the eval board from a different distributor. When I get a replacement I will report its behaviour and successful workaround attempts - if needed - here.

One remark: When I trried to read the markings on the chip, it looked like that it was soldered onto the board with an unreasonable high temperature. This also could be the cause of some of the problems. If you know about soldering problems during the production of these eval boards, please let me know.

If needed I could supply you with some C code (bare metal), but the extraction of a meaningful code sample out of a larger project would cause an effort that I would like to avoid. I hope that you can work with the detailed description given above.

Thank you for your efforts!

[JMH]

Dear Mr. Borlini,

today I had the chance to inspect the IIS3DWB chip under a powerful microscope and got more information about the markings present. The first lines says someting like "° IW" and is followed by a rectangular mark that is similar to an QR code or 2D barcode. The last line below this mark reads "045" ("O45" ?) as described above. The surface of the chips looks rather rough which might be attributed to a high soldering temperature.

One addendum: I forgot to mention that very much is going on on the controlling STM32H7 microcontroller, such as 2-channel sampling and generation (I²S double channel DMA) of audio data, DSP filtering of this data stream, Ethernet and U(S)ART traffic and so on. Many of the interrupts used for these activities feature a higher interrupt priority than the IIS3DWB FIFO threshold interrupt. Thus, the mentioned race condition between the read-out of the status register and the reading of the FIFO may become more probable due to the delays induced by the handling of high-priority interrupts occuring between these actions.

Thus, a reproduction of the problem may also require some artificial load or delays.

[Eleon BORLINI]

Hi @JMH​ ,

Thank you for the detailed description of the issue, hope that you can fix it properly managing the interrupts in the STM32H7 MCU.

the 045 marking should be correct and refers to the Year "0" (i.e. 2020) and wk "45".

-Eleon

[JMH]

Dear Mr. Borlini,

I consider „properly managing the interrupts�? an unfortunate wording. The SPI interface and its associated interrupt pin is part of a sophisticated in-production sensing system and is present there for future extensions. All other 5 SPI, 3 UART, 2 I²C, the QSPI, the ADC1, and one SAI/I²S interfaces aside from the Ethernet MAC are busy sampling and distributing data. All standard 16 DMA, 2 BDMA and one MDMA channels are in use aside from the Ethernet MAC DMA. When system load tests are done the hell is loose inside the H743 and I am wondering when the arbiters of the different AXI, AHB, and APB busses will glitch and lockup the access to the SRAM. This has not happened, yet. Thumbs up!

My wish for Christmas is an H743 with 1GHz, 2MB SRAM, and some more SPI interfaces (on the upper ports) together with additional DMA channels. Santa Claus, do you read this? Throw in a moderate price and a short-term availablility. This would make an elderly software engineer happy who is busy in the embedded software area for more than 25 years.

I attached two different WiFi modules to this “extension�? SPI interface and its interrupt pin and got them working with communication protocols that were far more complicated than the IIS3DWB protocol.

I wrote this probably unnecessary introduction in order to get your attention for the following statement: your IIS3DWB got sincere problems with its interrupt handling and probably its interrupt pin and you should get the attention of the hardware designers to these problems.

I managed to get other STEVAL-MKI208V1K boards and continued my investigation with the workarounds that I described above. None worked. I still get “spurious�? interrupts when I read the FIFO status registers and subsequently the FIFO itself. Reading only FIFO_STATUS2 does not change the behavior. Furthermore, I got chip resets after a few hundred or thousand FIFO reads. I investigated these further and found a peak in the power consumption of the chip which seems to be related to the generation of interrupts. This peak probably reduces the in-chip voltage below a level where a reset is triggered.

I am configuring the INT1 pin to a positive logic and as push/pull output. It seems to me that due to some internal glitch both the push and the pull outputs get activated at the same time for a short while. Since a second IIS3DWB chip ceased to work during these tests I get the feeling that this glitch may be the cause of the two chip failures I encountered. Just to mention it: I made sure that the pin of the H743 to which the INT1 pin is connected is always an input (with weak pulldown) and confirmed this by measurements.

Since I lost two IIS3DWB eval boards and only one remained, I dropped the approach to use the interrupt pin and deactivated it via the INT1_CTRL configuration. Now I use a 5ms timer interrupt to

-      read out the FIFO status registers,

-      extract the status and the number of samples (in most cases around 134 for the 5ms interval),

-      start the FIFO SPI DMA transfer for the indicated number of samples,

-      evaluate the data when the DMA terminates.

This works smoothly and runs over hours without problems. I really can recommend this approach for continuous high-performance data collection with the IIS3DWB chip.

Currently, the raw data is transmitted via the Ethernet MAC and drowns a system engineer in information who has to determine what “bad vibrations�? are like for our sensors. He probably will get back to me that I down-sample the data to make it better manageable. Another Christmas wish: Since you got on-chip filters, please add a downsampling option, as well. A 6 or 3 kHz sample rate seems to be our requirement.

A final remark: I am not very familiar with the noise specification. When 75 μg/√Hz means about 12mg at 26667 Hz (output of the LPF1 digital filter) then I get the specified noise except for seldom spikes. Is there an application note regarding the noise and how to handle it best?

I am willing to conclude this issue here. Should you have dedicated questions or need for code samples I am willing to answer provided the effort for this is low on my side.