Shutdown / Disable an Interface?

[thestumbler]

What's the technique to completely disable a peripheral interface in MODM?

I tried to make such a function for the SPI master DMA that is controlling my Wiznet chip. But I'm unable to succeed in a successful compile. Before I go deeper down that path, I'm curious if there's an existing mechanism that has escaped me so far.

I'm asking because that exact DMA channel I'm using is also being used by the application that my boot loader jumps to. Even though I disable MCU interrupts before jumping, it seems the DMA engine interrupt generator is still enabled. So that somehow kills the application which hasn't yet setup its IRQ and an unexpected interrupt from the DMA engine drives it into a hard fault.

[thestumbler]

Here's the error message, which I can almost understand after I spent some time reformatting it in an editor. Well, I can understand what it's saying, but not exactly how it matches the function I added.

In file included from modm\src/modm/driver/ethernet/w5100s_transport.hpp:207,                                                                                                                              from modm\src/modm/driver/ethernet/w5100s.hpp:20,
from C:\files\projs\hybo\boot23\boot2\src\wiznet.hpp:6,
from C:\files\projs\hybo\boot23\boot2\src\wiznet.cpp:1:
  modm\src/modm/driver/ethernet/w5100s_transport_impl.hpp:
  In instantiation of
  'void modm::W5100sSpiTransport<SpiMaster, EthCs, EthRst>::reset_to_factory_defaults()
  ¦ [with
  ¦ ¦ SpiMaster = modm::platform::SpiMaster2_Dma<
  ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦modm::platform::DmaController<1>::Channel<modm::platform::DmaBase::Channel::Channel0>,
  ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦modm::platform::DmaController<1>::Channel<modm::platform::DmaBase::Channel::Channel1> >;
  ¦ ¦ EthCs = modm::platform::GpioStatic<modm::platform::detail::DataC8>;
  ¦ ¦ EthRst = modm::platform::GpioStatic<modm::platform::detail::DataD10>
  ¦ ]':
modm\src/modm/driver/ethernet/w5100s_impl.hpp:66:39:
required from
'void modm::W5100s<Transport>::shutdown()
`[with
  ¦ ¦Transport = modm::W5100sSpiTransport<modm::platform::SpiMaster2_Dma<
  ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ modm::platform::DmaController<1>::Channel<modm::platform::DmaBase::Channel::Channel0>,
  ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ modm::platform::DmaController<1>::Channel<modm::platform::DmaBase::Channel::Channel1> >,
  ¦ ¦ modm::platform::GpioStatic<modm::platform::detail::DataC8>,
  ¦ ¦ modm::platform::GpioStatic<modm::platform::detail::DataD10> >
]'

C:\files\projs\hybo\boot23\boot2\src\wiznet.cpp:165:15:
required from here
  modm\src/modm/driver/ethernet/w5100s_transport_impl.hpp:73:22:
  error: 'shutdown' is not a member of
'modm::platform::SpiMaster2_Dma<
  ¦ ¦ ¦ modm::platform::DmaController<1>::Channel<modm::platform::DmaBase::Channel::Channel0>,
  ¦ ¦ ¦ modm::platform::DmaController<1>::Channel<modm::platform::DmaBase::Channel::Channel1> >'

scons: *** [C:\files\projs\hybo\boot23\boot2\build\h735\scons-release\src\wiznet.o] Error 1
scons: building terminated because of errors.                                                                                                                                                                                                                                                                                                                                                                                                                                                      

[thestumbler]

And last but not least, here is the function in question, whose format I copied from the DmaTransferError() function in the same file. Searching all the code and examples for someplace that calls that function, I failed.

[HPP (inside the class)

	static void
	shutdown();

[_IMPL_HPP]

template <class DmaChannelRx, class DmaChannelTx>
void
modm::platform::SpiMaster{{ id }}_Dma<DmaChannelRx, DmaChannelTx>::shutdown()
{
	SpiHal{{ id }}::disableInterrupt(SpiBase::Interrupt::TxDmaEnable |
			SpiBase::Interrupt::RxDmaEnable);
	Dma::RxChannel::stop();
	Dma::TxChannel::stop();
}

And here's where I try to call it, in the same class where I do other SPI operations, like transfer, in the w5100s_transport_impl.hpp file.

template<typename SpiMaster, typename EthCs, typename EthRst>
void 
W5100sSpiTransport<SpiMaster, EthCs, EthRst>::
reset_to_factory_defaults(void) {
  EthRst::reset();
  modm::delay_ns(1000); // 560 ns low minimum resets chip to defaults
  EthRst::set();
  modm::delay_ms(100); // it takes 60.3 ms to initialize
  // also kill DMA
  SpiMaster::shutdown();
}

[thestumbler]

Just one hour after posting this, I figured out a workaround ( yet to be tested ).

In the main boot loader code, when I need to jump, instead of jumping, I'll put a message in RAM containing the desired jump address. Then I'll issue an NVIC System Reset, thus putting all the peripherals in their default state.

In my boot loader code start up code, I'll check for such a valid message before I initialize all the peripherals. If a jump address message is found, I'll jump.

That may not be a perfect solution, because in MODM some things are "configured" just by their existence. I'm not entirely clear but I think things like the interrupts and any DMA setup happens when you connect something in your app startup code. In the case of this problematic SPI / Ethernet case, that's easy. For the UART, which isn't causing problems but theoretically should also probably be disabled (not enabled) as well, that's more tricky since it's done in my custom MODM BSP code -- tricky but not impossible.

Well, on further thought, this is going to be non-trivial to implement. I'm instantiating my devices in global space because of memory issues. I guess I can instantiate a memory-message-checking class before all other devices. That class would rudely jump to the application program if warranted, instead of returning.

But regardless, I'd like to know how to disable things in the code after they've been initialized, if such a procedure exists.

[salkinium]

The RCC peripheral has reset bits for all peripherals. That's probably what you want? I think it's Rcc::reset<Peripheral>() or something similar in modm.

[thestumbler]

Yes. I just found that five minutes ago.

I would like to suggest that the MODM peripherals include a shutdown function as a future idea. My usage here is extreme in that I really want to kill every peripheral on the chip. But there could be situations where an application would want to take down a single interface.

For the application to turn off a device, you have to figure out which peripherals are used -- the SPI master DMA device I'm using grabs an SPI, DMA, and interrupt(s?) which all need to be brought down. Also, as a MODM beginner, you have to wade through and learn the correct syntax to call all these different shutdown functions -- lacking an existing device shutdown function, it's not always clear how to reach down and access each associated peripheral. And in addition you have to properly sequence these shutdown calls.

It seems to me that such a function naturally belongs in the same class that initializes it. That way you can be sure all these related things are disabled and in the correct sequence.

[thestumbler]

Okay -- I found out why my that function addition I had made to the SPI class wasn't recognized. It isn't being processed by LBUILD. Unlike other directories in the main MODM directory tree, like say PLATFORM/UART/STM32 or DRIVER/ETHERNET, any changes I make in PLATFORM/SPI/STM32 are simply ignored. I confirmed this on two different machines.

Interestingly it's clearly fetching the SPI code from somewhere. I can completely delete the local MODM directory, and it gets recreated with the original files before I started editing them

SOLVED... The separate STM32H7 directory for the SPI peripheral escaped my attention. DOH

[thestumbler]

I'm going to close this discussion as "wrapped up". I was able to disable the things which I wanted to, and I see how to add a shutdown function in the future. Unfortunately, I was not able to accomplish my ultimate goal, which was to fix a problem with the application when it is jumped-to from the boot loader. I figured out exactly what instruction "kills" things, but there was no obvious reason at first glance. I'm pressing forward with Plan B using RAM memory messages, something I need to do anyway for other reasons. I will revisit this problem in a later issue once the overall project wraps up and I have some time to better trace it.