SPI communication with Accelerometer

Hello Stylianos,

I have looked at the information you have provided and I don't see anything out of the ordinary. However, this doesn't preclude there being an issue with the format if it doesn't match what the slave device expects. A brief look at the document to which you provided a link indicated that the data is provided as 13-bit data and if you have set up the SPI transmission as 8-bit, it may not be shifting all of the data out to the master during a transmission.

Also, since you have set the block size up as 1 block of data (i.e., 1x 8-bit data value) the clock would not continue to operate if there was no additional data to be shifted in or out.

I have also copied a colleague who is an expert with SPI so they can also have a look and provide feedback.

Stylianos,

Also, if you could provide a little bit of additional information regarding how the data received does not meet your expectations and what kind of anomaly you are seeing on the receive data line, it might be helpful in figuring out what is going on.

Thank you all for your replies,

Resetting the Clock Phase value gave me the expected Device Id. So, I guess the problem with the SPI configuration is solved and thank you for that. Now, my next question has to do with the image that you posted. I am a bit confused about how to read and write the registers (Forgive me but I am a newbie). In my understanding in order to write a value in a register, I have to provide the address first with 2 bits as prefix, 1 for writing and 1 for the multibyte-bit. So, 1 byte in total.

Question 1: For example, I want to write in the register in address 0x31 the value 0x0B. My buffer should be like this? :

uint16 TX_Data_Master[2] = { 0x4B, 0x31 };

 For reading, if I want to read the address 0x32 my buffer will be like this? :

uint16 TX_Data_Master[1] = { 0xF1 };

Question 2: Can I use the same buffer to send bytes that I want to write and bytes that I want to read? For example:

uint16 TX_Data_Master[3] = { 0x4B, 0x31, 0xF2 };

Question 3: The charlen is reffering only to the sent data or to the received as well? If I want to send 1 byte and read 2 how is it possible? In the blocksize I will put 1 (1 x 8 bits) or 2 (2 x 8 bits)?

I know that these questions are not absolutely relative with the spi configuration, but I need some information to proceed. 

Thank you in advance.

Hi Stelios,

I cannot speak to the validity of the commands and addresses you want to transmit via SPI; however, I can give a short synopsis of how the function spiTransmitAndReceiveData() works.

Basically, the function does the following for each block of data to be sent.

1. Sets up data format
2. Copies Tx data into Tx register
3. initiates the Tx
4. Waits for Tx to end
5. puts the Rx'ed data in the Rx buffer
6. If another data block, increment block counter/index and go to 1

So, with this understood, you could set up your transmit buffer to hold more than one data block (bytes in your case) as you have shown in question 1. If you do this though, you will need to increase the array definition from 1 element to the appropriate number of elements you want to send in one "stream." As you have it defined in your initial post, TX_Data_Master is a 1 element array and you could not assign more than one element to it so uint16 TX_Data_Master[1] = { 0x4B, 0x31 }; would give an error. Note that you would also have to indicate the number of elements (blocks) to send in the values passed to the function

For question 2, I would suppose you could do this but it really depends on the slave and it's capabilities. The SPI master will have no issue with this.

Question 3: charlen applies to both send and receive. SPI is primarily a serial shift based mechanism. i.e., the master shifts bits out to the slave when it transmits and the slave shifts bits out to the master in as it received bits. Thus the pin names SIMO ( Slave In Master Out) for master Tx and SOMI (Slave Out Master In) for master Rx. So, if you have multiple bytes to receive, you would have to send multiple bytes even if one of them is a dummy byte (0xFF? or some other benign value).

Finally, I would also suggest you reach out to ADI for guidance on their accelerometer since they may have additional suggestions on how to deal with things like multiple data or streaming data over SPI, etc. They would have specific use cases from their customer base that might be beneficial in helping you figure out how to send the commands to their device since we now have your code working with the SPI on Hercules and we can successfully send and receive data from the ADI device.

Hello Chuck,

Thank you for your information. Regarding the functionality of SPI, it is a shift register. So, I suppose that when I send an address to my slave device, I do not get directly the expected result. I need to send a dummy byte after the address. For example, if I want to read the address 0x80, I need to do:

spiTransmit -- 0x80, 0xFF (dummy byte)
spiReceive -- 2 bytes.

Is it correct? It's not clear to me how the TransmitAndReceive works.

Thank you in advance.

Stelios,

This is it. For each bit that is shifted out there is one shifted in.
If your data length is 8bits (Char), for each byte out there is 1 byte in.
So yes to read address 0x80, you have to send 0x80, the incoming byte in this case is don't care, and then you have to send a dummy byte to get from your slave the first data. If you need more data and your slave supports this feature, than continue to send dummy byte and get from the slave another data.

Stelios,

I've create a project to demonstrate the usage of SPI to communicate with ADXL345.

Use it as an example or starting point.

The code will read the device ID and will print it on a serial terminal (Hyperterminal or any other of your choice)
The baudrate is setup to 115200, 8bits,1 stop, no parity.

Here are some screenshot:

1] Read Device ID.

2] Read the DATAX0,1 DATAY0,1 and DATAZ0,1

3] CCS and Terminal

To use the serial printf (redirection of printf to a serial port, you have to set in the property of your project the Pre-define NAME "UART_SUPPORT" as shown below.

There is no special connection to support the serial port. SCI2 is accessible via the USB connection to your host PC.
Check on your system which COM port is assigned to it.

Use the one named XDS110 Class Application/User UART.

The corresponding Halcogen project is also available in the root directory.

6644.RM46_ADXL345.zip

Please have a try and let me know.

Thank you for your nice example,

But still I cannot figure out what is my problem. I attach you the simplest project that I could do...Just for the device id. Please inform me if there is something wrong, or the device is dead.

6153.spi-adxl.zip

Stelios,

I checked your code and here is the problem.

dataconfig1_t.CS_HOLD = FALSE;

should be dataconfig1_t.CS_HOLD = TRUE;

The spiTransmitAndReceiveData is using this parameter to decide how to manage the CS line.
For the ADXL345, CS should be low to select SPI mode.
If dataconfig1_t.CS_HOLD = TRUE; CS will go low for the full transmission (multiple data) and will be back high at the end.
If dataconfig1_t.CS_HOLD = FALSE; CS will go low for the first data, back high, low again, next data, back high.....

Also, as per ADXL specification, the bit 7 (MSB) of address is the Read Write bit. It specifies if the transaction is a READ register or Write Register.

I will also change:

uint16_t TX_Data_Master[8] = { 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

Please have a try

Hello Jean-Marc,

I took a brand new device (ADXL345 again)  to try if the previous one was damaged, but unfortunately I still do not get the right values. (Except the device id). I think that I have exactly the same code with your example right now (without using SCI and RTI) and the results that I receive are like this:

I know that -27 means FFFFFFFFFFFFFFE5. What can be wrong? My logic analyzer shows that the transferd packet is correct. I attach the whole project again. Thank you for your time again. 

5224.Spi1Acc.zip

Stelios,

Your code looks correct now. I will try it on my setup and will let you know.

Are you using your own board for the ADXL345 or one of these mini board you can ordered online?
Many time they are configured by default for I2C. At least it was the case for mine.
Can you send me a picture and schematics of your setup.

Here is the device I'm using.

Jean-Marc,

I have the plain device, like this:

http://media.digikey.com/renders/Analog%20Devices%20Renders/14-LGA%20PKG.jpg

I currently use it on my breadboard with external power supply (Vdd: 1.8V, Vs: 2.5V) . I have the following setup (I have not connected the INT1 and INT2 pins):



I am looking forward to test your own device with my project.

Kind regards,
Stelios

Stelios,

Your code is working on my bench.

One comment on your hardware connection. Why did you connect vdd to 1.8v? and vs to 2.5v?

Our parts are 3.3v IOs. I will suggest to connect at least vdd to 3.3v to be compatible with our IOs requirements.

Please check and let me know.

Jean-Marc,

I changed Vdd and Vs with no luck. I also created a new project, using SPI2 port, but same results. My logic analyzer results are like this:

On the MISO line it always receive E5.

Have you used my HalCoGen configuration as well? Or just my code? Is it possible that I miss something in the HalCoGen settings for the SPI? Is the brand new device not working properly? My main problem is that I cannot understand where the problem derives from... 

Kind regards,
Stelios

Stelios,

Here is a capture of all signal using your latest project.

Starting from first CS low we have:

1] Send 0x80 (Read to register 0x00)   Received dummy (0x00 or whatever is in the ADXL345 buffer)
2] Send 0x08 (Dummy data to read back) Receive Device ID = 0xE5. (Expected data)

3] Send 0x31 (Write to register 0x31)   Received dummy (0xE5 or whatever is in the ADXL345 buffer)
4] Send 0x0B (Data to be written to address 0x31) Received dummy (0xE5 or whatever is in the ADXL345 buffer)

5] Send 0x2D (Write to register 0x2D)   Received dummy (0xE5 or whatever is in the ADXL345 buffer)
6] Send 0x08 (Data to be written to address 0x2D) Received dummy (0xE5 or whatever is in the ADXL345 buffer)

7] Send 0xF2 (Multi Read from register 0x32)   Received dummy (0xE5 or whatever is in the ADXL345 buffer)
8]   Send 0x08 (Dummy data) Received dummy (0x04 for DATAX0)
9]   Send 0x00 (Dummy data) Received dummy (0x00 for DATAX1)
10] Send 0x00 (Dummy data) Received dummy (0x01 for DATAY0)
11] Send 0x00 (Dummy data) Received dummy (0x00 for DATAY1)
12] Send 0x00 (Dummy data) Received dummy (0xF8 for DATAZ0)
13] Send 0x00 (Dummy data) Received dummy (0x00 for DATAZ1)

So everything is working fine for me.

Hello Jean-Marc,

In order to locate the problem, I am trying to implement an I2C communication with the same device. I am trying to adapt the HalCoGen example and my code is as follows:

/** @file sys_main.c 
*   @brief Application main file
*   @date 16.Feb.2015
*   @version 04.03.00
*
*   This file contains an empty main function,
*   which can be used for the application.
*/

/* 
* Copyright (C) 2009-2015 Texas Instruments Incorporated - www.ti.com 
* 
* 
*  Redistribution and use in source and binary forms, with or without 
*  modification, are permitted provided that the following conditions 
*  are met:
*
*    Redistributions of source code must retain the above copyright 
*    notice, this list of conditions and the following disclaimer.
*
*    Redistributions in binary form must reproduce the above copyright
*    notice, this list of conditions and the following disclaimer in the 
*    documentation and/or other materials provided with the   
*    distribution.
*
*    Neither the name of Texas Instruments Incorporated nor the names of
*    its contributors may be used to endorse or promote products derived
*    from this software without specific prior written permission.
*
*  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 
*  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
*  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
*  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
*  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
*  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 
*  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
*  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
*  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
*  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
*  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*/


/* USER CODE BEGIN (0) */
/* USER CODE END */

/* Include Files */

#include "sys_common.h"

/* USER CODE BEGIN (1) */
#include "i2c.h"

#define own_add 0x20
#define slv_add 0xA7
#define bsize    2




void i2cEnableLoopback(i2cBASE_t *i2c);
/* USER CODE END */

/** @fn void main(void)
*   @brief Application main function
*   @note This function is empty by default.
*
*   This function is called after startup.
*   The user can use this function to implement the application.
*/

/* USER CODE BEGIN (2) */
/* USER CODE END */

void main(void)
{
/* USER CODE BEGIN (3) */
	uint8  TX_PACK[bsize]={0xA7, 0x00};
	uint8  RX_PACK[bsize]={0};
	uint32 data;
    uint32 buf_size = bsize;
    uint8  *t_buff = &TX_PACK[0];
    uint8  *r_buff = &RX_PACK[0];

    /* i2c initialization         */
    i2cInit();

    /* set i2c own address        */
    i2cSetOwnAdd(i2cREG1,own_add);

    /* set Slave Address */
    i2cSetSlaveAdd(i2cREG1, 0xA7);

    /* Initiate Start condition for Transmission  */
    i2cSetStart(i2cREG1);

    /* send data packets          */
    while(buf_size--)
    {
       i2cSendByte(i2cREG1,*t_buff++);
       /* receive data packets    */
       *r_buff++ = i2cReceiveByte(i2cREG1);
    }

    /* Clear Stop Condition detect flag  */
    i2cClearSCD(i2cREG1);

    /* wait for ever  */
    while(1);

 /* USER CODE END */
}

/* USER CODE BEGIN (4) */
/* USER CODE END */

I am not sure where I should specify the address of the slave. Directly in the sent packet or in the function setSlaveAddress? Please give me some tips to proceed with this communication.

Kind regards,
Stelios

Stelios,

There is no reason to switch to I2C. The code you sent me yesterday IS WORKING on my setup.

Please can you check and tell me:

1] What board are you using with exact part number.
2] Using an oscilloscope (not a logic analyzer) send me a screenshot of SPICLK, SPISOMI SPISIMO and SPICS_0
     I want to see the voltage.

3] If possible, a picture of your setup.

4] The schematics of the connections between our Hercules micro controller and the ADXL345. (Your schematics, not the one from the ADXL datasheet.

Thank you.

Jean-Marc,

I purchaced this device:

http://www.ebay.de/itm/ADXL345-digitales-3-Achsen-Gyroskop-Beschleunigungs-Sensor-/171539079039?pt=LH_DefaultDomain_77&hash=item27f0869f7f

I use an external power supply and I give 3.3V to the 3V3 pin of the device. I connect SCL to SP1:CLK, SDA to SP1:SIMO, SDO to SP1:SOMI, CS to SP1:CS0  and GND of the device and the board to the same GND of my external power supply. 

My exact board number is: TMS570LS 3137CZWTQQI YFC-39C7V3W.

A screenshot of my oscilloscope:

My updated project:

6470.SPI.zip
I have checked the voltage level and it looks fine everywhere. The result that I am getting as Device Id is 0 (as you can also see on the scope screenshot). Please inform me if you need anything more. 

Kind regards,
Stelios

Stelios,

This is the exact same board I'm using.
As you may know, the ADXL345 has 2 communication mode. SPI or I2C. The selection is done via the nCS pin.
0 = SPI
1= I2C

On this board, the nCS pin is bring out to a header pin name CS.
In I2C mode, 2 ADXL345 can be connected to the same I2C bus, the selection is done by configuring 1 device with Add0 = 0 and the other with Add0 = 1.

ON THIS BOARD, ADD0 it tied to ground via R4.
ADD0 is also SDO in SPI mode. This is the reason why you are reading always 0 on your Master.

Please de-solder R4 and everything should work.

Jean-Marc,

I feel pretty lucky that you owe the same device. Without datasheet, I would never find out what the problem was. Thank you very much, its working like a charm now.

I am experimenting with spi using interrupt mode now. Regarding the examples that I found, I enabled in Halcogen the MibSpi1 Level 0 and Level 1.  Then, in my code instead of TransmitAndReceive I use SetAndGetData. I am attaching the simplest project that I expect the Device ID again (E5) and I am reading ff:

4382.SPI_Interrupt.zip

On the scope though, I get a weird result like:


Could you please explain the interrupt mode benefits for spi? The ISR code should be written into spiNotification function of notification.c file? Please give a short explanation of an spi interrupt trigger. 

Thank you in advance,
Stelios

Stelios,

I will check your code as soon as possible and will be back to you.

But shortly, the advantage of interrupt versus polling mode.
In interrupt, the CPU doesn't have to wait for your data to be received before doing something else.
If you look the code for TransmitAndReceive there is a while loop waiting for all data to be received. CPU does nothing else.
Using SetAndGetData, the interrupt handler will take care of sending and receiving the data. Because SPI transmission are slow, while the data are shifted in and out, the CPU can execute other tasks.
But if your code sequence needs the incoming data from your accelerometer and will not be able to process anything else than interrupt will not buy you anything.

Jean-Marc,

Thank you for the info. I initialized a flag and I set it in spiEndNotification function. Then, I check if it is set and I receive the data. But this interrupt is triggered only after the Send operation is completed. Is there a separate interrupt for receiving the data? Moreover, it is not so clear to me in HalCoGen what's the difference of MIBSPI1 Level 0 and MIBSPI1 Level1.

Thank you for your time,
Stelios

Jean-Marc,

I attach my updated project with handling the interrupts that are triggered in my SPI  communication. I am getting the right values from the accelerometer, but I would be grateful if you could verify that my interrupt handling is correct.

I checked that the SendAndGetData function is calling the same ISR (the spiEndNotification) twice: one when TX gets empty and one when RX gets full. So, in order to verify that I have transmitted and received the data, I increment a counter (done) and I check when it becomes equal to 2.

Do you think it is a right approach for handling the interrupts? Is there a way to distinguish the interrupt after transmitting from the interrupt after receiving?


Kind regards,
Stelios

6332.SPI_Interrupt.zip

Stelios,

I will check your code but first I need to remind you one main concept of SPI communication.
There is no such transmit or receive event. Once a data is send out, a data is received.
So the interrupt you get indicates that a data is ready in the receive buffer (and the data that was written in the transmit buffer is out.)

Jean-Marc,

I know about the shifting in SPI, but probably the following chunk of code confused me:

void mibspi1HighLevelInterrupt(void)
{

/* USER CODE BEGIN (39) */
/* USER CODE END */

    uint32 flags = (spiREG1->FLG & 0x0000FFFFU) & (~spiREG1->LVL & 0x035FU);
    uint32 vec = spiREG1->INTVECT0;

/* USER CODE BEGIN (40) */
/* USER CODE END */

    switch(vec)
    {

    case 0x24U: /* Receive Buffer Full Interrupt */
             {
                uint16 *destbuff;
                destbuff = g_spiPacket_t[0U].rxdata_ptr;

                *destbuff = (uint16)spiREG1->BUF;
                /*SAFETYMCUSW 567 S MR:17.1,17.4 <APPROVED> "Pointer increment needed" */
                g_spiPacket_t[0U].rxdata_ptr++;
                g_spiPacket_t[0U].rx_length--;

                if(g_spiPacket_t[0U].rx_length == 0U)
                {
                    spiREG1->INT0 = (spiREG1->INT0 & 0x0000FFFFU) & (~(uint32)0x0100U);
                    g_spiPacket_t[0U].rx_data_status = SPI_COMPLETED;
                    spiEndNotification(spiREG1);
                }
                break;
             }

    case 0x28U: /* Transmit Buffer Empty Interrupt */
             {
                 volatile uint32 SpiBuf;
                 uint32 Chip_Select_Hold = 0U;
                 uint32 WDelay = (g_spiPacket_t[0U].g_spiDataFormat.WDEL) ? 0x04000000U : 0U;
                 SPIDATAFMT_t DataFormat = g_spiPacket_t[0U].g_spiDataFormat.DFSEL;
                 uint8 ChipSelect = g_spiPacket_t[0U].g_spiDataFormat.CSNR;
                 uint16 Tx_Data = *g_spiPacket_t[0U].txdata_ptr;

                 g_spiPacket_t[0U].tx_length--;

                 if(g_spiPacket_t[0U].tx_length == 0U)
                 {
                    Chip_Select_Hold = 0U;
                 }
                 else
                 {
                    Chip_Select_Hold = (g_spiPacket_t[0U].g_spiDataFormat.CS_HOLD) ? 0x10000000U : 0U;
                 }

                 spiREG1->DAT1 = ((uint32)DataFormat << 24U) |
                                 ((uint32)ChipSelect << 16U) |
                                 (WDelay)           |
                                 (Chip_Select_Hold) |
                                 (uint32)Tx_Data;

                 /*SAFETYMCUSW 567 S MR:17.1,17.4 <APPROVED> "Pointer increment needed" */
                 g_spiPacket_t[0U].txdata_ptr++;
                 /* Dummy Receive read if no RX Interrupt enabled */
                 if(((spiREG1->INT0 & 0x0000FFFFU)& 0x0100U) == 0U)
                 {
                     if((spiREG1->FLG & 0x00000100U) == 0x00000100U)
                     {
                         SpiBuf = spiREG1->BUF;
                     }
                 }

                 if(g_spiPacket_t[0U].tx_length == 0U)
                 {
                    spiREG1->INT0 = (spiREG1->INT0 & 0x0000FFFFU) & (~(uint32)0x0200U); /* Disable Interrupt */
                    g_spiPacket_t[0U].tx_data_status = SPI_COMPLETED;
                    spiEndNotification(spiREG1);
                }
                break;
             }

    default: /* Clear Flags and return  */
             spiREG1->FLG = flags;
             spiNotification(spiREG1, flags & 0xFFU);
             break;
    }

I see that it checks the value of INTVECT0, and raises interrupt for : 
1.  Receive Buffer Full Interrupt 

2. Transmit Buffer Empty Interrupt

and I checked the datasheet for this register (INTVECT0 bit 1-5):

12h SPI mode: The pending interrupt is a "Receive Buffer Full" interrupt.
Mib mode: Reserved. This bit combination should not occur.

14h SPI mode: The pending interrupt is a "Transmit Buffer Empty" interrupt.
Mib mode: Reserved. This bit combination should not occur.

Regards,
Stelios

Jean-Marc,

Do we have any updates? In the meanwhile I tried the I2C communication and I have some issues there as well. Please take a look to my new post: e2e.ti.com/.../409447 as you owe the same device and you could test if my code behaves the same for you.

Kind regards,
Stelios