IIS2dh multi-byte read doesn't work?

[Jeff Gros]

Posted on December 05, 2017 at 23:07

Hello ST Community,

I have an application using the IIS2DH MEMS accelerometer. I was running into some issues, so to troubleshoot, I bought the STEVAL-MKI168V1 daughter board and SEVAL-MKI109V2 mother board. Using these kits, and by using the STSW-MKI109W software package, I was able to troubleshoot the majority of my issues.

I have one issue that remains. The multibyte read does not work in 4 wire SPI mode. Here are some details.

1. I have the /MS bit in the command byte set to 1.

2. My command sequence appears to be no different than SPI_Read_MultiData in spi_mems.c of the sample code.

3. When reading out the registers (0x20 to 0x3F), I get correct data if I read each register using the single-byte read mode. If I use the multi-byte read mode, I will get data that doesn't make sense. For example, I might read INT1_SRC (0x31) and get a 1 in the most significant bit (supposed to be zero).

I noticed a few things while looking at the sample code and using the Unico application.

1. I ran the the Unico application with the IIS2DH and used a logic analyzer to spy the bus. It never seems to perform a multi-byte read, even when I click the 'Read All' button in the Registers tab. Instead, it reads each register using the single-byte mode.

2. I did a search in the firmware and found that 2 files files called 

SPI_Read_MultiData, but there are also 2 files where it is commented out in favor of the single-byte read. I'm having a hard time finding my way around to confirm whether the sample code for the IIS2DH would use multi-byte reads or not. As far as I can tell, it looks like I might be using lis2dh12.c, which has SPI_Read_MultiData commented out.

It is curious that multi-byte read is disabled in some files of the sample code. Is there an errata for the IIS2DH somewhere that I'm not aware of? Is multi-byte read a known problem for the IIS2DH?

Thanks

Jeff

[Miroslav BATEK]

Posted on December 08, 2017 at 17:11

Can you capture SPI signals during you multi-read procedure on a scope or logic analyzer?

[Jeff Gros]

Posted on December 08, 2017 at 22:17

Yes! I can absolutely capture a trace for you to examine!

I have attached a logic analyzer trace that shows reading registers 0x20 to 0x3F on the IIS2DH. I have done both multi byte and single byte reads of these registers all in the same logic analyzer trace so that you can compare the result of both methods.

The first set of reads is done using the multi byte read mode. I have left marker 1 (the blue one) at the spot where it reads register 0x We expect the MSBit to be low, but we read 0x The same is also true for register 0x

The second set of reads is done using the single bytes read mode. I read each register (between 0x20 and 0x3F) one transaction at a time. I have left marker 2 (the red one) at the spot where it reads register 0x We see that we get 0x00, which is the expected result.

The logic analyzer trace was generated using the Digiview 3400 logic analyzer. In order to view the trace, you will need to download the associated PC Software. You can download it here from the Tech-Tools website:

http://www.tech-tools.com/d_digiview.htm

Thanks for looking into this!

Please let me know if you need anything further.

________________ Attachments : IIS2DH_MultiByteRead_vs_SingleByteRead_Comparison.dvdat.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyGO&d=%2Fa%2F0X0000000b59%2FsgZKgKkItPHNsdbPIEywDXV1dIHN7tKkuzfKrv1_Vx8&asPdf=false

[Jeff Gros]

Posted on December 08, 2017 at 22:22

Somehow I didn't post quite the correct link for the software download. The above link gets you to the download page. This is the direct download for a Windows 7/8/10 (32/64 bit installation):

http://www.tech-tools.com/files/digiview-921.exe

[Miroslav BATEK · Accepted solution]

Posted on December 11, 2017 at 16:05

The problem with the multi-read is that the device rolls back to 0x28 when register 0x2D is reached, so you want be able to read all register from 0x20 to 0x3F using one multi-read operation. In your log you can see that the data (0x40, 0x0D, 0x90, 0x00, 0x80, 0x80) repeats whet you reach 0x2D register, which confirms the behavior mentioned above.

[Jeff Gros]

Posted on December 11, 2017 at 21:52

You figured it out! Thanks for your help!

I had not realized my data was repeating. The last time I looked at this, I don't believe I gathered the data all in one shot. Instead I was reading the data into a buffer and looking at the contents using the debugger. Since the Accel registers are what repeats, my interpretation at the time was that the data I was getting was garbled/random since the accelerometer would change by the next time I sampled the registers.

Now that you mention the data is repeating, I can confirm this. The datasheet also mentions that the address does rolls back to 0x28 when 0x2D in reached in the 'Retrieving data from FIFO' section on page 22.

I do find this a bit confusing though. Based on the way the datasheet reads, I wouldn't think this would apply to my situation since I am in bypass mode (not using FIFO, and FIFO_EN bit is zero in CTRL_REG5).

I did another experiment where I did two multi-byte reads: one from 0x20 - 0x2D, and another from 0x2E to 0x3F. This time I got the expected result.

Time to go back and update my code to use multi byte reads!

Thanks again!