I am interfacing the BMA253 Accelerometer with STM32 Discovery Board using 4 wire SPI. I am using the CUBEMX HAL Library. As a first step, I am trying to read the CHIP ID from the sensor register 0x00. The chip which should be read is 0xFA. The following code is added in the while loop just for the purpose of verification. As SPI is a active low protocol, I have configured PIN_2 to be high by default.
uint8_t result = 0;
uint8_t address = 0x00;
while (1)
{
HAL_GPIO_WritePin(GPIOD, GPIO_PIN_2, GPIO_PIN_RESET);
HAL_SPI_Transmit(&hspi1, &address, 1, 100);
HAL_Delay (100);
HAL_SPI_Receive(&hspi1, &result, 1, 100);
HAL_Delay (100);
HAL_GPIO_WritePin(GPIOD, GPIO_PIN_2, GPIO_PIN_SET);
}
Since it is in the infinite while loop, for the first two loop cycles I am getting 0xFF in the result. Then in the next two loop cycles, I am getting the correct Chip Id which is 0xFA. Then I am getting 0xFF in the next two loop cycles and this pattern is alternating infinitely.
I am not able to understand why I am receiving 0xFF first and then 0xFA.
Could there be a problem with the delay mismatch? I feel that 100ms should be fine.
I also feel that the SPI Receive is being incorrectly implemented. I am worrying because since SPI Read is an important function in retrieving the acceleration data, this function is the key.
I request anyone to please suggest me on what to do to get it working perfectly. Any help would be highly appreciated.
Thanks in advance.
EDIT: WORKING NOW
1. Followed theSealion's suggestion to set the first bit high.
2. Additionally, I had to configure the CPOL and CPHA in the SPI Configuration to either Mode 0 or Mode 3 as per the sensor requirement.
Please try the follwoing to ready the Chip ID
#define READ_REGISTER 0x80
uint8_t result = 0;
uint8_t address = 0x00 + READ_REGISTER;
while (1)
{
HAL_GPIO_WritePin(GPIOD, GPIO_PIN_2, GPIO_PIN_RESET);
HAL_SPI_Transmit(&hspi1, &address, 1, 100);
HAL_SPI_Receive(&hspi1, &result, 1, 100);
HAL_GPIO_WritePin(GPIOD, GPIO_PIN_2, GPIO_PIN_SET);
HAL_Delay (500);
}
According to the datasheet, if you want to read a register, the MSB of the command must be 1. And you do not need any within the communication.
Related
I have a STM32F103RE MCU that is connected to a fxos8700cq sensor through I2C2 port.
I've set up the peripherals using stm32cubemx and I'm trying to simply test the communication with the sensor. But as I debug the code, it seems that data transfer is not happening correctly.
These are the i2c settings:
hi2c2.Instance = I2C2;
hi2c2.Init.ClockSpeed = 100000;
hi2c2.Init.DutyCycle = I2C_DUTYCYCLE_2;
hi2c2.Init.OwnAddress1 = 0;
hi2c2.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT;
hi2c2.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE;
hi2c2.Init.OwnAddress2 = 0;
hi2c2.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE;
hi2c2.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE;
and here is the main code:
uint8_t send_buffer[1];
uint8_t receive_buffer[1];
uint8_t FXOS_ADDR = (FXOS8700_DEVICE_ADDR_SA_11 << 1);
send_buffer[0] = FXOS8700_WHO_AM_I;
receive_buffer[0] = 0;
// chip select for fxos
HAL_GPIO_WritePin(GPIOC, GPIO_PIN_2, GPIO_PIN_SET);
HAL_Delay(500);
HAL_GPIO_WritePin(GPIOC, GPIO_PIN_2, GPIO_PIN_RESET);
HAL_Delay(500);
ret = HAL_I2C_Master_Transmit(&hi2c2, FXOS_ADDR, send_buffer, 1, 100);
//ret = HAL_I2C_Master_Transmit_IT(&hi2c2, FXOS_ADDR, send_buffer, 1);
HAL_Delay(2);
ret = HAL_I2C_Master_Receive(&hi2c2, FXOS_ADDR, receive_buffer, 1, 100);
//ret = HAL_I2C_Master_Receive_IT(&hi2c2, FXOS_ADDR, receive_buffer, 1);
if (receive_buffer[0] == FXOS8700_WHO_AM_I_PROD_VALUE)
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_8, GPIO_PIN_SET);
else
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_10, GPIO_PIN_SET);
but after I debug the code, and watch the i2c registers after executing the HAL_I2C_Master_Transmit(&hi2c2, FXOS_ADDR, send_buffer, 1, 100); function I get these values. That means the TXE bit in SR1 register is not set.
I also tried using the interrupt mode but that's not working either. the values of i2c registers after the ret = HAL_I2C_Master_Transmit_IT(&hi2c2, FXOS_ADDR, send_buffer, 1); line are like this.
In all cases the functions return HAL_OK and there is no error.
I've tested the sensor and the board communication using mbed and it works fine. So the hardware has no problem.
You should not need to toggle a chip select when using the device's I2C interface.
The device's chip select signal is only for the SPI interface.
You should have the SA0 and SA1 pins pulled high or low to use the I2C interface and select the device's I2C address. See table 11 and section 10.2.3 in the datasheet.
HAL_I2C_Master_Transmit() and HAL_I2C_Master_Receive() are not the best functions for reading a register value from the device. These functions transmit a start condition, the device address, the data, and finally a stop condition. But this is not what the FXOS8700CQ datasheet recommends in section 10.1.2, "Single-byte read". It says transmit start condition, device address with W bit, register address, repeat-start condition (notice no stop before repeat start), device address with R bit, then the data, and finally a stop condition.
The HAL_I2C_Mem_Read() function can be used to perform the single-byte read as described in the datasheet. (i.e., write register address, repeat-start, read data.) Try something like this.
uint8_t data_byte = 0;
HAL_StatusTypeDef hal_status = HAL_I2C_Mem_Read(&hi2c2, FXOS_ADDR, FXOS8700_WHO_AM_I, I2C_MEMADD_SIZE_8BIT, &data_byte, 1, 100);
If that doesn't help, then check the return value from the HAL library calls.
If that doesn't help, then examine the I2C clock and data signals with a logic analyzer or oscilloscope.
Please help! I am using FSMC to connect a STM32F407 MCU with AD7606 to sample voltage value. MCU would send sampled values to PC using USB HS port after 1024 conversions. But when I inspect the values from PC, I found that readings from channel 0 occasionally contains data from other channels. For example, if connect channel 0 to 5v, connect channel 8 to 3.3v, connect other channels to ground. Then the printed value from channel 0 would contain 5v, 0v, 3.3v. The basic setup is as follows:
A 200KHZ PWM single is generated by TIM10 to act as CONVST signal for AD7606.
7606 will then issue a BUSY signal which I used as an external interrupt source.
In the Interrupt handler, An DMA request would be issued to read 8 16bit data
from FSMC address space to memory space. TIM10 PWM would be stopped if 1024
conversions has been done.
In the DMA XFER_CPLT call back, if 1024 conversions has been done, the converted
data would be sent out by USB HS port, and TIM10 PWM would be enabled again.
Some code blocks:
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
if(GPIO_Pin == GPIO_PIN_7)
{
// DMA data from FSMC to memory
HAL_DMA_Start_IT(&hdma_memtomem_dma2_stream0, 0x6C000000, (uint32_t)(adc_data + adc_data_idx) , 8);
adc_data_idx += 8;
if (adc_data_idx >= ADC_DATA_SIZE)
HAL_TIM_PWM_Stop(&htim10, TIM_CHANNEL_1);
}
}
void dma_done(DMA_HandleTypeDef *_hdma)
{
int i;
int ret;
// adc_data[adc_data_idx] would always contain data from
// channel 1, led1 wouldn't light if every thing is fine.
if (adc_data[adc_data_idx] < 0x7f00 )
HAL_GPIO_WritePin(led1_GPIO_Port, led1_Pin, GPIO_PIN_SET);
if (adc_data_idx >= ADC_DATA_SIZE)
{
if(hUsbDeviceHS.dev_state == USBD_STATE_CONFIGURED)
{
// if I don't call CDC_Transmit_HS, everything is fine.
ret = CDC_Transmit_HS((uint8_t *)(adc_data), ADC_DATA_SIZE * 2 );
if (ret != USBD_OK)
{
HAL_GPIO_WritePin(led1_GPIO_Port, led2_Pin, GPIO_PIN_SET);
}
}
adc_data_idx = 0;
HAL_TIM_PWM_Start(&htim10, TIM_CHANNEL_1);
}
}
It seems that a single USB transaction would take longer than 5us(one conversion time), so I stopped PWM signal to stop conversion...
If I only send the second half of the data buffer, there is no data mixture. It's very strange.
According to your description, I think the processing is correct, and the problem is at the CDC_Transmit_HS(); I have met the problem on the CDC_Transmit_FS(), which can't transmit more than 64 bytes data for original code, and need to modify some code, otherwise the some error occurs. Did you check the number of received data is correct?
Reference:
I can't receive more than 64 bytes on custom USB CDC class based STM32 device
I'm not sure your ADC_DATA_SIZE size; if it's larger than 64 bytes, maybe you can modify to smaller than 64 bytes and try again and check whether or not the data is correct. I am not sure if it is affected by this problem, but I think you can give it a try.
On the other hand, it may also be necessary to GND the ADC IN pins not used by AD7606 to avoid interference between channels.
Or you can try other communication (I2C, SPI, UART...etc) to send the data.
If there is no problem with other communication methods, there is a high chance that it is a problem with CDC_Transmit_HS(). If there are problems with other transmission methods, you may have to check whether there is a conflict between the ADC conversion time or the transmission time.
I'm trying to set communication between esp32 (master) and stm32 (slave) over SPI. esp32 is running under micropython and sends four bytes, for example
spi.write_readinto(b'\x31\x32\x33\x34', buf)
stm32' code is here (instead of this i use SPI_InitDef.SPI_NSS = SPI_NSS_Soft;)
void SPI_Init(void) {
...
// initialize SPI slave
// for slave, no need to define SPI_BaudRatePrescaler
SPI_InitDef.SPI_Direction = SPI_Direction_2Lines_FullDuplex;
SPI_InitDef.SPI_Mode = SPI_Mode_Slave;
SPI_InitDef.SPI_DataSize = SPI_DataSize_8b; // 8-bit transactions
SPI_InitDef.SPI_FirstBit = SPI_FirstBit_MSB; // MSB first
SPI_InitDef.SPI_CPOL = SPI_CPOL_Low; // CPOL = 0, clock idle low
SPI_InitDef.SPI_CPHA = SPI_CPHA_2Edge; // CPHA = 1
SPI_InitDef.SPI_NSS = SPI_NSS_Hard; // use hardware SS
SPI_InitDef.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_64; // APB2 72/64 = 1.125 MHz
SPI_InitDef.SPI_CRCPolynomial = 7;
SPI_Init(SPI1, &SPI_InitDef);
SPI_Cmd(SPI1, ENABLE);
NVIC_EnableIRQ(SPI1_IRQn);
//Тут мы разрешаем прерывание по приему
SPI_I2S_ITConfig(SPI1, SPI_I2S_IT_RXNE, ENABLE);
}
void main() {
/* Setup SysTick Timer for 10ms interrupts */
if (SysTick_Config(SystemCoreClock / 100))
{
/* Capture error */
while (1);
}
/* Configure the SysTick handler priority */
NVIC_SetPriority(SysTick_IRQn, 0x0);
SPI_Init();
while(1) {
while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE));
for (u8 i=0; i<4; i++) {
printf("0x%02x ", SPI_I2S_ReceiveData(SPI1));
}
printf("\r\n");
}
}
But when I send four bytes 0x31 0x32 0x33 0x34 (analyzer confirms bytes were sent) and my stm gets only 0x31 0x32 0x31 0x32
UPD
I use std periph library and SPI_I2S_ReceiveData is a native method to read byte from SPI.
uint16_t SPI_I2S_ReceiveData ( SPI_TypeDef * SPIx )
Returns the most recent received data by the SPIx/I2Sx peripheral.
Parameters:
SPIx,: To select the SPIx/I2Sx peripheral, where x can be: 1, 2 or 3 in SPI mode or 2 or 3 in I2S mode or I2Sxext for I2S full duplex mode.
Return values:
The value of the received data.
uint16_t SPI_I2S_ReceiveData ( SPI_TypeDef * SPIx )
Returns the most recent received data by the SPIx/I2Sx peripheral.
Parameters:
SPIx,: To select the SPIx/I2Sx peripheral, where x can be: 1, 2 or 3 in SPI mode or 2 or 3 in I2S mode or I2Sxext for I2S full duplex mode.
Return values:
The value of the received data.
But maybe I exit out from IRQ before all data are read. I found to run the while loop until the transmission of the last byte is complete
I think the following code is not correct (but I don't know what the function SPI_I2S_ReceiveData is doing):
while(!SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE));
for (u8 i=0; i<4; i++) {
printf("0x%02x ", SPI_I2S_ReceiveData(SPI1));
}
You exit from the while as soon as one byte is ready to be read. I assume SPI_I2S_ReceiveData is only reading the SPI FIFO. in that case you try to read 4 bytes when possibly only one or two has been received.
You didn't precise the kind of STM32 you're using so I am describing the SPI of STM32H7 (as far as I know it should be pretty similar in other STM32).
To setup a reception in slave mode you should define in particular these 3 parameters:
the length of the socalled "frame" (number of bytes to be read/written at once). This is the field SPI_DataSize` in the HAL data structure, here 8 bits.
the number of transfer (TSIZE) which specifies when the End Of Transmission event is generated. It is expressed in number of "frames". This parameter must be set through register SPI.CR2 before each reception (provided you know the number of bytes to be received of course).
the "FIFO threshold". It specifies at which frequency an event RXP or TXP is generated. You can change this parameter to decrease the workload on the software but to receive only 4 bytes it has no impact.
In your case I think you should setup a transfer size of 4 (4 bytes) and wait for EOT flag to be set. When it is set you only have to read 4 bytes from SPI Receive Register (you can read all 4 bytes at once by the way).
I suggest you do not use the HAL but write your own SPI reception / transmission routines by reading / writing registers. It is not a very complex peripheral (so it will not cost you a lot of time) and you will understand precisely how it works (instead of digging into the HAL).
As i was beginning with SPI FLASH from winbond W25Q32FV with STM32F103RCT6 CORTEX M3. I am facing a real issue of understanding how things should work.
I am using CUBEMX. First i have selected RCC as crystal/ceramic resonator and configured my clock to 72MHz. Then i configured SPI1 as FULL DUPLEX MASTER. There i got only 3 Pin (PA5 - SCK, PA6- MISO, PA7 - MOSI) so i configured CS pin as GPIO OUTPUT on PA2.
Now to write to flash? What is the first thing I need to do? What are the steps i need to follow?
As long as i refereed to the datasheet first i need to Enable Write(0x06). Then i need to send Page Program(0x02) and then i need to send 24 bit address. Then i need to send at least 1 byte of data. All these procedure will happen when CS is low and then after sending all this CS will be high.
Then i am disabling Write enable, i.e write Disable(0x04).
After then i am trying to read data from that address, So, I send Read Data(0x03) and 24bit address. Then Recieve data in buffer.
Here is the sample code:
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_2,GPIO_PIN_RESET);
HAL_Delay(10);
SPI_TX_BUFF[0] = 0x06;
SPI_TX_BUFF[1] = 0x02;
SPI_TX_BUFF[2] = 0x00;
SPI_TX_BUFF[3] = 0x00;
SPI_TX_BUFF[4] = 0x01;
SPI_TX_BUFF[5] = 0x11;
HAL_SPI_Transmit(&hspi1, SPI_TX_BUFF, 6, 50);
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_2,GPIO_PIN_RESET);
HAL_Delay(100);
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_2,GPIO_PIN_RESET);
HAL_Delay(10);
SPI_TX_BUFF[0] = 0x04;
HAL_SPI_Transmit(&hspi1, SPI_TX_BUFF, 1, 50);
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_2,GPIO_PIN_RESET);
HAL_Delay(100);
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_2,GPIO_PIN_RESET);
HAL_Delay(10);
SPI_TX_BUFF[0] = 0x03;
SPI_TX_BUFF[1] = 0x00;
SPI_TX_BUFF[2] = 0x00;
SPI_TX_BUFF[3] = 0x01;
HAL_SPI_Transmit(&hspi1, SPI_TX_BUFF, 4, 50);
HAL_SPI_Receive(&hspi1, SPI_RX_BUFF, 1, 50);
HAL_GPIO_WritePin(GPIOA,GPIO_PIN_2,GPIO_PIN_RESET);
HAL_Delay(100);
This code is not working. More over after flashing the code i can't even enter the debug mode. It says NO TARGET CONNECTED. I know i am doing something massively wrong and need a little guidance. I just need to know what are the steps involved to successfully initiate, write and read from spi flash.
Like I am confused with few stuffs
Here i am directly sending the Write enable as my first command. Here should i need to send the id first? I mean how to initiate and let know the MCU that he is having a flash connected to the spi pins.
2.How to send 24 bit address? What is the starting address i begin with to write data in flash?
3.When is flash a simple blinky. The MCU works fine but when i flash this code why the alert NO TARGET CONNECTED. Then i have to press reset and erase everything.
Any help will be appreciated.
Thank you in advance.
i have a tiva c micro controller the tm4c123gxl and i have been trying for a while now to use the I2C module on the board with a digital accelrometer with no result , i have been trying to set the MDR register with a certain value to send but it stays as 0
here is the code i am using for intialization till reaching part where i set the MDR register im using step by step debugging i run the code initially to the assignment step of I2C3_MDR_R = 0x2D;
void PortDInit(void)
{
volatile unsigned long delay=0;
SYSCTL_RCGCI2C_R|=0x8; //1-set clock of I2C of module 3
delay = SYSCTL_RCGC2_R; //2-delay to allow clock to stabilize
SYSCTL_RCGC2_R |= 0x00000008; //3-port D clock
delay = SYSCTL_RCGC2_R; //4-delay to allow clock to stabilize
GPIO_PORTD_AFSEL_R |= 0x03; //5-alternate function set for I2C mode
GPIO_PORTD_DEN_R |=0x03; //6-enable digital functionality for PA6 and PA7
GPIO_PORTD_ODR_R|=0x02; //7-enable open drain mode for I2CSDA register of port A
GPIO_PORTD_PCTL_R = 0x00000033; //8-set PCTL to I2C mode
I2C3_MCR_R= 0x00000010; // 9-intialize the i2c master
I2C3_MTPR_R = 0x00000007; // 10-number of system clock cycles in 1 scl period
I2C3_MSA_R = 0x3A // set slave address and read write bit
I2C3_MDR_R = 0x2D; // data to be sent BREAK POINT HERE using single step here yields MDR with same value = 0
I2C3_MCS_R = 0x00000003; // follow transmit condition
while(I2C3_MCS_R &= 0x40 == 1); // wait bus is busy sending data
if(I2C3_MCS_R&=0x04 ==1)
{
//handle error in communication
}
else
{
//success in transmission
}
what i have done to reach this code
carefully understood the I2C protocol how it works etc.
check the data sheet and follow the initalization steps mentioned there step by step which got me to this code
i know i should use tivaware library which will be easier but using
the registers helps me understand more of how everything is working ,
im still a student
at first i didnt have the digital enable line as it wasnt mentioned
to be activated for the I2C but its only logical it should be there
as we are using digital values i tried with both yielded the same
output mdr=0
i am using keil 4 as my IDE and im viewing the values of registers of
I2C module 3 to know whether data is placed in MDR or not
hope any one helps
thanks.
This is a long shot, but here goes:
in your comments, step 6 says
//6-enable digital functionality for PA6 and PA7
but it appears you are working on GPIO_PORTD...
maybe its a comment typo (you meant PD6 and PD7)
but just double check you are looking at the right pins...
Good luck!