Hardware issue: Modem and SPI flash contention on SERCOM4

[sslupsky]

There is a design flaw that has come to my attention regarding the modem and SPI flash.

The spi flash is wired to PA12 and PA15 on the SAMD21. The modem is wired to the same pins. The current MKRWAN library running on the SAMD21 and the modem firmware running on the murata module use an asynchronous serial communication (UART) interface. More specifically, the MKRWAN library uses "SerialLoRa" (Serial2) for communication with the modem. SerialLoRa uses SERCOM4 configured as a uart port. The spi flash uses "SPI1". SPI1 uses SERCOM4 configured as an spi port. This creates a conflict where SERCOM4 must be configured both as a uart and a spi port if the modem and flash are used concurrently. To avoid hardware contention the modem and flash cannot be used concurrently. Thus, the LoRa modem must be disabled when accessing the flash. The only way presently to disable the LoRa modem is to assert the RF_NRES (PA27) pin.

The intended purpose of the MKR WAN 1310 is to use LoRa. So, having to put the LoRa modem into a reset state when you want to access the flash is a significant problem. I think perhaps the original idea may have been to use spi communication for both the LoRa modem and spi flash. To do so requires a firmware change to the modem module so that it configures itself to use spi rather than uart communication.

If the spi flash were to be rewired to the "SPI" bus (SERCOM1), which does not share the same pins as the SerialLoRa connection, there would be no conflict between the modem and flash. Unfortunately, to implement this fix would require a board revision.

So, I see a few potential library and firmware changes that could address this:

1. Use spi instead of uart communication between the samd21 and the modem
2. Repurpose PA27 as a uart enable/disable (not a module reset)
3. Multiplex a reset and uart enable/disable function onto PA27.

Are any of these options, or something else, already in the works? If so, what is the ETA?

[facchinm]

Hi @sslupsky ,
option 1) was the one we chose initially but the firmware was not developed further to accept commands via SPI (this is still the plan if some nice soul would like to help 🙂 )

I understand that the workaround of:

• using the modem
• saving data in SAMD ram
• shutting down the modem
• bringing up the flash and save the data there
• go to deep sleep
  that exist nowadays needs more commands but (I think) is acceptable since LoRa requires to send a message to open the RX window (so no wakeup will ever be generated independently).

What do you think?

[sslupsky]

Hi @facchinm , I think that will work for a Class A device but I think there are problems for Class B and Class C devices because the RX window can be open at other time(s).

Can you comment on Arduino's position vis-a-vis the Zephyr RTOS? If Arduino is planning to support Zephyr, I think I would be willing to help out with a driver. I've done a little background work on this and it seems feasible. Zephyr is a tight squeeze into a SAMD but it can be done and the results are quite impressive.

BTW, I think Zephyr would be a great direction for Arduino ... the development environment shares the same philosophy of abstracting away a lot of the underlying complexity of building an application. In fact, you could probably deprecate the Arduino IDE entirely for SAMD and Nordic mcu's and replace it with west and the MS VSCode IDE without a great deal of work. I am less certain of the AVR's since I do not use them. Someone has also implemented a version of the Arduino API in Zephyr.

[sslupsky]

I have a prototype of a new driver that works with Zephyr.

[tohlh]

Hello, I am interested in making the the LoRa modem to communicate with SAMD21 via SPI.

May I know how this can be possibly done? Which SPI interface do you intend to use and what is the possible approach?

Thanks you!

[RobSmeenk]

Hi @sslupsky ,
option 1) was the one we chose initially but the firmware was not developed further to accept commands via SPI (this is still the plan if some nice soul would like to help 🙂 )

I understand that the workaround of:

• using the modem
• saving data in SAMD ram
• shutting down the modem
• bringing up the flash and save the data there
• go to deep sleep
  that exist nowadays needs more commands but (I think) is acceptable since LoRa requires to send a message to open the RX window (so no wakeup will ever be generated independently).

What do you think?

Can you point me to an example sketch where the MKR WAN 1310 stores the LORA settings, goes to deepsleep, wakes up, retrieves the LORA settings, and starts sending to LORA again without a 'full reconnect?'. All examples I found put the 'modem.begin' in the loop and that eats airtime. Also against best practices. Thanks, Rob

[sslupsky]

I am not aware of an example sketch as you describe. However, if the mkrwan firmware used a semaphore with the samd21 to coordinate access to the flash, contention could be avoided and access to the flash could be accomplished.