STM32L0: Add DEVICE_SPI_COUNT to DISCO_L072CZ_LRWAN1 + MTB_MURATA_ABZ

[teijokinnunen]

Enables simultaneous use of both SPIs without interference.

Description

STM32L0x2 has two SPIs available, on Murata LoRaWAN SoC the other one is used for the LoRaWAN radio and the other can be used by the application. I noticed that when LoRaWAN is active, the other SPI did not work reliably (apparently as they are both using the GlobalSPI instance). Setting DEVICE_SPI_COUNT helped. After this change the application SPI works together with LoRaWAN.

Pull request type

[ X ] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

Release Notes

[ciarmcom]

@teijokinnunen, thank you for your changes.
@ARMmbed/mbed-os-maintainers please review.

[LMESTM]

@ARMmbed/mbed-os-maintainers can you clarify usage of DEVICE_SPI_COUNT and whether it should be declared for all targets that have more than 1 SPI peripheral ?

[jeromecoutant]

Hi
This means that SPI feature branch has been merged ???
(only STM32F429 were implemented...)

[0xc0170]

No, spi feature branch has not yet completed.

@ARMmbed/mbed-os-maintainers can you clarify usage of DEVICE_SPI_COUNT and whether it should be declared for all targets that have more than 1 SPI peripheral ?

@ARMmbed/mbed-os-hal rather to comment. To my understanding, it should be defined to be able to use more than one SPI peripheral (SPIx).

[0xc0170]

STM32L0x2 has two SPIs available, on Murata LoRaWAN SoC the other one is used for the LoRaWAN radio and the other can be used by the application. I noticed that when LoRaWAN is active, the other SPI did not work reliably (apparently as they are both using the GlobalSPI instance). Setting DEVICE_SPI_COUNT helped. After this change the application SPI works together with LoRaWAN.

This should also answer the question above - using just one instance (backward compatible).

[LMESTM]

This should also answer the question above - using just one instance (backward compatible).

I don't remember that the previous implementation was limiting the SPI usage to a single instance ... maybe I missed it.

In any case, shouldn't there be an issue or PR to deploy DEVICE_SPI_COUNT to all targets that have more than 1 SPI peripheral instance ?

[LMESTM]

in any case this PR looks good - thanks @teijokinnunen

[kjbracey]

If it's not defined you get the legacy (5.0 to 5.11) behaviour that all SPI accesses are protected by a single mutex, rather than having 1 mutex per SPI master peripheral.

The SPI devices will "work" without, it should just be a performance loss. Except that performance loss may be critical, eg an SD card access interfering with a radio.

In any case, shouldn't there be an issue or PR to deploy DEVICE_SPI_COUNT to all targets that have more than 1 SPI peripheral instance ?

This is being done on the "feature SPI" branch, among with lots other things. It would only be worth making an extra issue if we think that's going to take some time to land, and want to accelerate this. I don't actually know what the situation is now.

[0xc0170]

CI started

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts