SPI: can't get to work as expected

General
1

Hi all, first post to the forum :slight_smile:
I’m having trouble using the SPI to do a simple read from a device register.
After entering and configuring SPI mode, I give the following command (0x19=read cmd, 0x01 high addr byte, 0x53 low addr byte and read four values back):
SPI> { d:125 0x19 0x01 0x53 r r r r }
But what I’m getting back is not as expected:

CS Enabled
Delay: 125us
TX: 0x19 0x01 0x53 
RX: 0xC8 0xE8 0x08 0x28 
CS Disabled

Problems/questions:

  1. as per documentation, when using the ‘{’ command I’m expecting to see also correspondig read after every byte, i.e. I should get 7 bytes back (3wr + 4rd), not only 4
  2. the read values are always the same and incrementing
  3. note that for testing I wired the MISO to GND and was expecting to get 0x00 as read values but I still get the same incrementing values, so it seems that MISO is not used at all
    What I’m I doing wrong ? Tnx for any help.
    Current config:
Bus Pirate 5 REV10
Firmware main branch (2024-03-30T17:08:57Z)
RP2040 with 264KB RAM, 128Mbit FLASH
S/N: 245C38D3012961E4
https://BusPirate.com/
Storage:   0.10GB (FAT16 File System)

Configuration file: Loaded
Available modes: HiZ 1-WIRE UART HDPLXUART I2C SPI 2WIRE LED
Active mode: spi (baudrate, clock polarity, clock phase, cs)=(992kHz, 1, 1, 2)
Display format: Auto
Data format: 8 bits, MSB bitorder
Pull-up resistors: OFF
Power supply: ON (3.3V/3.29V)
Current limit: OK (3.1mA/100.0mA)
Frequency generators: OFF
2

Hi @Gabri74 , welcome to the forum.

The read with write is not currently implemented. If you need that feature I will make it a priority. In the past I never found a use case for it, and don’t have any devices to test with it. It was, however, something the old bus pirate was capable of doing.

The other issue is very strange. I will test now and push a fix if it is obvious.

3

Definitely a bug from reworking the base libraries last week. I’ll push a solution shortly.

4

image

A fix is pushed, it should be posted any second.

Thank you so much for the bug report. This was an easy fix fortunately.

5

Thank for your kind reply. I’m interfacing to an SX1280 (LORA transciever).
As per documentation, the GetStatus command shifts out the status in the same clock burst sending the command, and it’s a bit strange. Not in the next dummy read, but in the same byte as the command… I can only think that the GetStatus command is a dummy command, i.e. a code not used by any other ‘real’ command and that the status byte is already present in the register and simply shifted out when. Other command, e.g. register reading, need at least a dummy byte read after the command/address.
Regarding the issue with the false MISO readings, i can confirm that I’m always reading an incrementing register, despite confirming with the DSO decode that correct data is present in the line. Could it be that the MISO pin (IO4) on the display UI is wrong and I should use another pin ?

6

The wrong data should be fixed in the firmware I just pushed. I did a huge cleanup of the code last week and evidently read wasn’t returning any value at all.

I will add the read with write function now and maybe you can test it for me :slight_smile:

7

image

The latest firmware here has read/write in SPI mode.

8

Thanks a LOT! Just tested the latest firmware and everything is working as expected, even read when writing :slight_smile:
Double checked with several commands and DSO decode and it seems all ok.
Thanks again for taking the time to look into this.

3 Likes
9

Thanks for the update!