0

I am using CubeMX and HAL to program an STM32L4. I am trying to communicate with RFM96 module using SPI, but I am getting nonsensical results.

According to the RFM96 datasheet, in order to read a byte from an address, I have to send 1 byte, MSB set to 0 (indicating read mode), the other 7 bits indicate the address. In the screenshot below you will see I am attempting to read the value of register 0x03, which is supposed to return value 0x0B (default). The problem is that instead of receiving only 0x0B, I receive what looks like ALL the register values of RFM95. You will see that 0x0B is present too.

enter image description here

I have let the clock go on for 8 bytes more than I need to, just to demonstrate the issue. Furthermore, I only experience this result if the LSB of the first byte is 1. If I request the data at address 0x02, I would get zero response (picture below). I get the same response if I send 0x00.

enter image description here

This is the code I use to generate the above logic analyser samples.

uint8_t data[10];
data[0] = 0b00000011;//sent first
data[1] = 0b00000000;
data[2] = 0b00000000;
data[3] = 0b00000000;
data[4] = 0b00000000;
data[5] = 0b00000000;
data[6] = 0b00000000;
data[7] = 0b00000000;
data[8] = 0b00000000;
data[9] = 0b00000000;

HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_RESET);
HAL_SPI_Receive(&hspi1, (uint8_t *)data, 10, 100);
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_SET);

This is my SPI init function:

  hspi1.Instance = SPI1;
  hspi1.Init.Mode = SPI_MODE_MASTER;
  hspi1.Init.Direction = SPI_DIRECTION_2LINES;
  hspi1.Init.DataSize = SPI_DATASIZE_8BIT;
  hspi1.Init.CLKPolarity = SPI_POLARITY_LOW;
  hspi1.Init.CLKPhase = SPI_PHASE_1EDGE;
  hspi1.Init.NSS = SPI_NSS_SOFT;
  hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_256;
  hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB;
  hspi1.Init.TIMode = SPI_TIMODE_DISABLE;
  hspi1.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
  hspi1.Init.CRCPolynomial = 7;
  hspi1.Init.CRCLength = SPI_CRC_LENGTH_DATASIZE;
  hspi1.Init.NSSPMode = SPI_NSS_PULSE_ENABLE;

This code is rudimentary; I am using a logic analyser to debug. Can anyone spot what I am doing wrong? As far as I can tell, I am giving the RFM95 all the requirements it needs in terms of MOSI, SCK, and NSS.

jbird
  • 11
  • 3
  • For many chips, likely including this one, continuing to supply read clocks will read out registers subsequent to the one requested. – Chris Stratton Dec 10 '18 at 03:06
  • Thanks @ChrisStratton, I am aware of this. I let RFM clock out more bytes than I needed in order to show that the chip was indeed alive and giving believable data from its registers (Effectively this is the burst read procedure). These values can be compared to those in the datasheet for verification. – jbird Dec 13 '18 at 12:06

1 Answers1

1

I did not manually reset (pull pin 6 low) the RFM before performing the above operations. I simply relied on the device resetting after power was applied. Page 108 in the datasheet indicates that the chip requires a 10ms wait after a reset is issued on pin 6. I decided to implement a manual reset at startup, and wait 10ms. SPI communication worked as it should thereafter. Power is not always cycled while programming, so the manual reset is necessary.

jbird
  • 11
  • 3