Register Address confusion

[claudiaAl]

Hello! I am going through trying to disable the SPI bus and am diving into the SPI control and enable registers. I am using the SPIClass.end() function as my reference for what I need to do to accomplish this. I am trying to understand what bits are being changed and have confused myself... can anyone clarify this for me? Thanks in advance!

scss_registers.h
#define PERIPH_CLK_GATE_CTRL            (SCSS_REGISTER_BASE + 0x018)
/* SPI */
#define SOC_MST_SPI1_REGISTER_BASE      (0xB0001400)

SPIClass.h only touches SPI1 so I am assuming that SPI0 is what the BMI160 is using.
So if we look at the bit that the clock gate control is being defined as it is 0x018 = 24. However, the documentation shows that it should be at bit 28 (or 29 if we are starting at 1).

2.1.6.86 CREG register detailed description
2.1.6.87 IO_CREG_MST0_CTRL (IO_CREG_MST0_CTRL)
MEM Offset(80018000)

31 AD_CLK_GATE
30 I2C1_CLK_GATE
29 I2C0_CLK_GATE
28 SPI1_CLK_GATE
27 SPI0_CLK_GATE
26:20 ADC CALIBRATION VALUE

The specific code that I am looking at lives in SPI.cpp (SPIClass.end())

SPI1_M_REG_VAL(SPIEN) &= SPI_DISABLE;
MMIO_REG_VAL(PERIPH_CLK_GATE_CTRL) &= DISABLE_SPI_MASTER_1;

Disabling the SPI seems ok, but when we disable the clock, I'm confused as to what bit is being changed. Am I missing something obvious here?

[eriknyquist]

Hi @claudiaAl,

#define PERIPH_CLK_GATE_CTRL (SCSS_REGISTER_BASE + 0x018)

This is actually a memory location, rather than a bitmask (it's the address of the PERIPH_CLK_GATE_CTRL register).

so, when we look at this line;

MMIO_REG_VAL(PERIPH_CLK_GATE_CTRL) &= DISABLE_SPI_MASTER_1;

it's saying "access the memory location PERIPH_CLK_GATE_CTRL, and apply the bitmask DISABLE_SPI_MASTER_1 to the value that lives there"

As to what bit is being changed, look in SPI_registers.h

#define     ENABLE_SPI_MASTER_0   (0x1 << 14)
#define     DISABLE_SPI_MASTER_0  (~ENABLE_SPI_MASTER_0)
#define     ENABLE_SPI_MASTER_1   (0x1 << 15)
#define     DISABLE_SPI_MASTER_1  (~ENABLE_SPI_MASTER_1)

So apparently it's bit 14 for SPI0, and bit 15 for SPI1

[eriknyquist]

But-- an unrelated question-- is there any particular reason you need to re-implement SPI.end()? why can't you just call the existing method to disable the SPI bus? And also, I believe that SPI is disabled anyway until you call SPI.begin() or SPI1.begin(), right?

[claudiaAl]

Good question. I can. That's actually where I started, but I didn't see any change in my current readings, so in an effort to be as thorough as possible, I wanted to go in and read the registers and understand what was really happening. If this all eventually goes into a library, I am assuming I would just use my end() function rather than duplicating the code...?

[eriknyquist]

like I said, I think SPI will be disabled by default anyway until you call *.begin(). So calling SPI.end() without first calling SPI.begin() is effectively changing nothing.

[claudiaAl]

got it! thank you!

[claudiaAl]

ok, so I have played with calling begin and end in order to see what's happening in the register. It's just for my own learning and to prove to myself that I can see the changes. The register looks like this initially, and after calling SPI.begin(), SPI.end(), and SPI.begin() again... for anyone that is interested!

CTRL0 initial 0
SPIEN initial 0
SER initial 0
BAUDR initial 0
TXFL initial 0
RXFL initial 0
SR initial 0
IMR initial 0
DR initial 0

CTRL0 after SPI begin() 1110000000000000000
SPIEN after SPI begin() 1
SER after SPI begin() 1
BAUDR after SPI begin() 1000
TXFL after SPI begin() 0
RXFL after SPI begin() 0
SR after SPI begin() 110
IMR after SPI begin() 0
DR after SPI begin() 0

CTRL0 after SPI end() 1
SPIEN after SPI end() 1
SER after SPI end() 1
BAUDR after SPI end() 1
TXFL after SPI end() 1
RXFL after SPI end() 1
SR after SPI end() 1
IMR after SPI end() 1
DR after SPI end() 1

CTRL0 after SPI begin() 1110000000000000000
SPIEN after SPI begin() 1
SER after SPI begin() 1
BAUDR after SPI begin() 1000
TXFL after SPI begin() 0
RXFL after SPI begin() 0
SR after SPI begin() 110
IMR after SPI begin() 0
DR after SPI begin() 0

[eriknyquist]

Do you have the latest version? I do, and I can't see SPI1_M_REG_VAL, only SPI_M_REG_VAL.
Maybe you have an old version?

You have the right idea, though; if you are using the latest, then you can read it like this;

creg = SPI_M_REG_VAL(SOC_MST_SPI1_REGISTER_BASE, SPIEN);

But, there is a sneaky twist here; SPI (i.e. SPI.begin()) actually uses the hardware SPI1 (i.e. SOC_MST_SPI1_REGISTER_BASE). So when I added support for SPI1 (i.e. SPI1.begin() the remaining SPI controller available to use is unfortunately named SPI0. The result is that SPI.begin() accesses SOC_MST_SPI1_REGISTER_BASE, and SPI1.begin() accesses SOC_MST_SPI0_REGISTER_BASE. You can see this in SPI.cpp:

SPIClass SPI(SPIDEV_1);
SPIClass SPI1(SPIDEV_0);

and SPI.h:

#define SPIDEV_0 0
#define SPIDEV_1 1

...

int spidevs[NUM_SPIDEVS][4] =
{
    /* base addr.                     Clk. enable value    Clk. disable value    SS GPIO */
    {(int)SOC_MST_SPI0_REGISTER_BASE, ENABLE_SPI_MASTER_0, DISABLE_SPI_MASTER_0, SPI0_CS},
    {(int)SOC_MST_SPI1_REGISTER_BASE, ENABLE_SPI_MASTER_1, DISABLE_SPI_MASTER_1, SPI1_CS}
};

So, you would test the Arduino SPI1 instance like this;

/* enable SPI1 */
SPI1.begin()

/* Read SPIEN */
creg = SPI_M_REG_VAL(SOC_MST_SPI0_REGISTER_BASE, SPIEN);

/* Disable SPI1 */
SPI1.end()

/* Read SPIEN */
creg = SPI_M_REG_VAL(SOC_MST_SPI0_REGISTER_BASE, SPIEN);

Does that make sense? it can get a bit confusing with all the back-and-forth between 0 and 1...

[eriknyquist]

I just edited my last post- I had mistakenly used SOC_MST_SPI1_REGISTER_BASE in the final example. It's correct now :)

[eriknyquist]

And, I was answering the original question I saw in the email notification-- I didn't notice you had removed the question. Did you figure it out?

[claudiaAl]

I think I am close... I ended up using this after referencing SPI_registers.h
creg = SPI1_M_REG_VAL(CTRL0);

I just compared the two versions and it looks like the definition changed from

/* Macro to access SPI1 Master controller register offset */
#define SPI1_M_REG_VAL(reg) \
    MMIO_REG_VAL_FROM_BASE(SOC_MST_SPI1_REGISTER_BASE, (reg))

to

/* Macro to access SPI Master controller register offset */
#define SPI_M_REG_VAL(base, reg) MMIO_REG_VAL_FROM_BASE(base, (reg))

It looks like they do the same thing... but I need to change my code so that I am looking at SPI0 and not SPI1.

I thought that there was only going to be access to one of the SPIs because the other was attached to the BM160 by default. Is this still the case? Should I only be considering SPI0 when developing the low power lib?

Thanks!!!

[eriknyquist]

CurieIMU class uses SOC_MST_SPI1_REGISTER_BASE (i.e. SPI.begin()), but this SPI controller is only initialised by CurieIMUClass::begin()

Honestly, I don't think there's any point in re-implementing the SPI.end() method for your low power lib. Simply not calling SPI.begin() is already enough to ensure that the SPI controller is disabled.