SPI projects and MAIN

[thestumbler]

I'm using the recently added SPI / BMI088 project for STM32H7 as a baseline for my own SPI / Wiznet code.

I tried to put the code into a separate class, and ran into some C++ issues that stump me. The problem happens when I moved things that were in MAIN, specifically the atomic booleans and function calls connecting up the interrupt lambda functions. Seems I can't separate those. For example, if I create them in my new class's initialization function, they're not visible from any other function of the same class.

Can those be extracted from MAIN and put in their own class? Or not?

[salkinium]

Could you post some code? I don't really understand what you did from the description.

[thestumbler]

Here ya go...

https://github.com/thestumbler/modm-bmi-test

[thestumbler]

As I made that minimal example, and after a full night's sleep, I think the problem is with the lambda functions? Instead, I should be connecting "real" functions. Maybe.

[chris-durand]

Try there:

Exti::connect<AccInt1>(Exti::Trigger::RisingEdge, [this](auto){
    accReady = true;
});

To access class member variables from the lambda you need to capture the this-pointer.

[thestumbler]

Is there a reason / MODM coding style convention that signals names are swapped in different modules, for example AccCs vs CsAcc?

[thestumbler]

I should say that the program runs either way, no faults. The "failure" is simply that the SPI doesn't operate. And when the code does work, it's when it is declared in the global space.

[chris-durand]

With the current linker script the stack is placed in DTCM which isn't accessible by DMA1/2. We should make that configurable and choose the safer option of placing the stack in AXI SRAM by default.

[rleh]

Also, I would consider silently failing a bug in the SPI-DMA platform driver. (Not sure if a fix would be possible with the given API...)

[salkinium]

We could at least add a modm_assert in there somewhere ;-P

[chris-durand]

@thestumbler #1100 should fix the issue that the DMA buffer can't be on the stack. Could you try that commit with your BMI088 example? I won't have access to any H7 boards for a few days.

[thestumbler]

I'm content for now to keep the SPI interface in global. There's no compelling reason to put it in MAIN.

But I do have a question about sharing the SPI interface with multiple devices. An earlier reply indicated that this will work. Are there any examples in the examples folder of such sharing?

I started testing my Wiznet module yesterday while the BMI088 was still wired into the circuit. I had no reason to run them simultaneously, but I did observe that each device seemed to work by itself. That is, if I initialized one and not the other, things looked normal.

I say "looked", because I started noticing weird mistakes as I began exercising the Wiznet module registers more extensively. I would see occasional erroneous stray pulses on the data line which very subtly interfered with the register values I was writing / reading to the Wiznet. I first suspected noise in my unkempt prototype breadboard, and later suspected a timing issues running the SPI at higher speeds.

Finally I became suspicious of having both devices on the SPI bus at the same time. While theoretically that should be okay, I had to admit to myself that I didn't really know if I was doing that correctly in MODM.

So I pulled out the BMI088 module and POOF -- no more issues. No glitches and all the register transfers with the Wiznet worked exactly as expected.

I'm fine now and work is proceeding well. But I would like to know the MODM method of hooking up two SPI devices on the same bus for future applications.

[thestumbler]

[chris-durand]

The modm drivers based on SpiDevice call SpiDevice::acquireMaster() and SpiDevice::releaseMaster() to guarantee exclusive access to the peripheral. Did you use that or acquire()/release() of the SpiMaster when implementing the Wiznet driver?

Another issue could be that somehow the BMI088 chip select is asserted while the SPI is still communicating with the Wiznet chip.

[thestumbler]

I have the acquire and release in both modules. On the logic analyzer, I did not see either of the BMI chip selects being asserted. I did, however, see the interrupts firing all the time.

I guess my question was more about the code to initialize such dual usage of an SPI bus. I note that I'm double-defining a few things as my code now exists, which I can't help but think isn't quite right.

For example, in my header files:

using Spi = SpiMaster2_Dma<Dma1::Channel0, Dma1::Channel1>;
using Transport = modm::W5100sSpiTransport<Spi, EthCs, EthRst>;
using Eth = modm::W5100s<Transport>;

and

using Spi = SpiMaster2_Dma<Dma1::Channel0, Dma1::Channel1>;
using Transport = modm::Bmi088SpiTransport<Spi, CsAcc, CsGyro>;
using Imu = modm::Bmi088<Transport>;

And in my source code:

Dma1::enable();
Spi::connect<Sck::Sck, Mosi::Mosi, Miso::Miso>();
Spi::initialize<Board::SystemClock, 4_MHz, 10_pct>();
Spi::setDataMode(Spi::DataMode::Mode0);

and

Dma1::enable();
Spi::connect<Sck::Sck, Mosi::Mosi, Miso::Miso>();
Spi::initialize<Board::SystemClock, 9_MHz, 10_pct>();

Note: those different clock speeds seem to definitely be a problem, but that is something I changed after I started seeing the issue. Originally they were both at 9 MHz.