# strange RFM95 SPI behaviour with STM32L4 [closed]

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.

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.

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_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.

## closed as too broad by Dave Tweed♦Dec 10 '18 at 2:19

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

• 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 3: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