2013-03-07 08:02 AM
I will need to use spi with a memory chip. But I currently can't get my spi to input data.
I am able to get it to output. I have a logic analyzer hooked up and it shows data is being outputed. When I do a loop back test it shows the data being delivered to the input pin PB14 but the micro does not seem to realize this. I am thinking that I do not have the pin set up for input, but I have tried different configurations but nothing seems to work This code sets up the spi, sends out data and is suppose to read it in code: void SPIInit (void) { * regRCC_APB2ENR = 0x9; //turn on gpiob and afio * regRCC_APB1ENR = 0x4000; // turn on spi 2 * regGPIOB_CRH = 0xB4B34B44; //this is where i might be having issues * regSPI_CR1 = 0x334; //* regSPI_CR2 = 0x04; * regSPI_CR2 = 0x00; * regSPI_CR1 |= 0x0040; } void SendOne() { char data; *regGPIOB_BSRR = 0x00001000;//CS high (set) PB12 while ((* regSPI_SR & 0x02 )!= 0x02){;} // when transmit buffer is empty send data *regSPI_DR = 0x9; // send enable to memory chip EWEN //*regSPI_DR = 'a'; // send enable to memory chip EWEN //edited it below as it was 0x2 and it was suppose to be 0x1 while ((* regSPI_SR & 0x000001 )!= 0x01){;} // when receive buffer not empty read data, program getting stuck here data = * regSPI_DR; //reading clears flags //*regGPIOB_BSRR = 0x00001000; //reset chip select low } spi2013-03-07 08:40 AM
> while ((* regSPI_SR & 0x000002 )!= 0x02){;} // when recieve buffer not empty read data, program getting stuck here
No wonder: this is not proper mask to get the ''receive buffer not empty'' flag; it's bit 0 of SPI_SR register. It's perhaps not a good idea to use ''magic values''. The STM32F0xx_StdPeriph_Lib_V1.0.0\Libraries\CMSIS\Device\ST\STM32F0xx\Include\stm32f0xx.h header is there for a reason. JW [EDIT] I take back the ''no wonder''. While the incorrect bit is read and checked indeed, the program should go on with incorrect data read from SPI_DR, as TXE should be set by hardware at the beginning of transmission. I don't understand why it is stuck.2013-03-07 10:25 AM
Thank you for noticing that.
I did have 0x01 previously but changed it while testing and watching the register values. I will edit it to the appropriate value