STM32F411CEU6 BlackPill @nspsck build SPI weird behaviour

[davefes]

I am trying to get ulora to work using the @nspsck build for the STM32F411.

I had one board sending a test message for hours then it stopped. Re-booting shows
"LoRa initialization failed", which I have worked out is that the SPI init has failed.

Doing a mass_erase and putting the firmware/software back on it still would not work.

I have found that I if I do the SPI stuff (both pyb.SPI and machine.SoftSPI) before I
call the lora class, that SPI works. I can only guess that doing the SPI stuff in:

ulora.py see (https://github.com/martynwheeler/u-lora/blob/main/ulora.py)

class LoRa(object):
    def __init__():

seems to be the problem. BTW, another board running the same ulora.py and a receive
script works OK.

Also, I am assuming that I can put a SoftSPI on pins that were mapped in the build for
a hardware SPI2.

I can only conclude that when the board failed that something got broken that now does
not allow the SPI stuff to be done in a class. I know next to nothing about writing classes.

Why in a class does spi.write('hello') become self._spi_write('hello')??
My understanding is that self._spi is private but why does it change to spi_write?
I searched dunder method, but it doesn't look like one to me.

I have some more BlackPills on order but was hoping that I could understand what
may have gone wrong.

[nspsck]

Ugh, it is really hard to tell you what is going on without seeing what exactly you were doing/trying to do.

Why in a class does spi.write('hello') become self._spi_write('hello')??

The spi.write() is provided by the machine module and it provides only a basic communication protocol. The _spi_write() is provided by the ulora module and it includes some setups for the lora device and uses spi.write() to communicate with the lora device. These are two different functions with different purpose, hence one never became another.

My understanding is that self._spi is private but why does it change to spi_write?

To my knowledge, there is no "private" function like Java in Python. The "_" at the beginning is just a convention to prevent the _spi_write() function showing up when you type dir(ulora). You can still access it through ulora._spi_write(). It's intention is to hide the functions, which the user should not use, from the user.

Also, I am assuming that I can put a SoftSPI on pins that were mapped in the build for
a hardware SPI2.

Sorry, I do not fully understand what you are trying to do here, but I hope I could help you with the following:

Based on the included modules by the ulora module, it uses hardware SPI. My suggestion is the following, go to line 63-69 and add an option let's say: stm32_2 = (2), etc, to it.

class SPIConfig():
    # spi pin defs for various boards (channel, sck, mosi, miso)
    stm32_2 = (2)
    stm32_3 = (3)
    rp2_0 = (0, 6, 7, 4)
    rp2_1 = (1, 10, 11, 8)
    esp8286_1 = (1, 14, 13, 12)
    esp32_1 = (1, 14, 13, 12)
    esp32_2 = (2, 18, 23, 19)

Because the SPI pins on stm32 ports are predefined, you can not change the on the fly. So you need to do the following to line 127.

if len(self._spi_channel) < 4:                             # That is: you only have one value in the list.
    self.spi = SPI(self._spi_channel[0], baudrate=3000000) # You can only get 3MHz on this board.
else:
    self.spi = SPI(self._spi_channel[0], 5000000,
                         sck=Pin(self._spi_channel[1]), mosi=Pin(self._spi_channel[2]), miso=Pin(self._spi_channel[3]))

Then you should be able to use the module as in the README.md.

Sadly, neither did I own a lora device nor I ever had experience with those, this is as far as I could help. The preconfigured SPI pins should be correct, since these are configured according to the official reference manual. Ugh, and I am going to sleep... So if you have quetions to my explaination.. I won't be able to respond for the next few (6-12) hours.

[davefes]

Thank you for your answer re _spi_write If I look further down ulora.py I do see that method, so that issue is sorted.

I had put stm32_2 = (2, 'B13', 'B15', B14') into SPIConfig() thinking that I could put a SoftSPI on the pins that you had mapped in your README.md for SPI2. I also put in from machine import SoftSPI

NSS is not used

If you do not use SPI2 then you could use those pins for a SoftSPI, correct?

A few minor changes to your suggestion as a list with one item is a singleton list and is of type int.. So you can not find it's length.
Also, the singleton list is not subscriptable. Here are my modifications, there could be a better way to do this.

      # setup the hardware SPI
        if self._spi_channel == SPIConfig.stm32_2 or self._spi_channel == SPIConfig.stm32_3:
            self.spi = SPI(self._spi_channel, baudrate=3000000)  # you can only get 3MHz on the BlackPill
        else:
            self.spi = SPI(self._spi_channel[0], 5000000,
                sck=Pin(self._spi_channel[1]), mosi=Pin(self._spi_channel[2]), miso=Pin(self._spi_channel[3]))

Really appreciate your very helpful answer.

However, the board with the above changes worked once or twice and then stop working ... throws-up "LoRa initialization failed".
I think one board must have something wrong with it. They are not official WeACT boards, so maybe I should just wait until the official boards arrive.

Some testing ... if I put this in main.py:

from time import sleep
from machine import Pin, SPI

print ('wait 2 seconds for a CTRL-C')
sleep(2)

try:
    spi = SPI(2, baudrate=3000000)
    spi.write(b'hello')
except:
    print ('write failed')

print ('finished')

No problems.

However, if I do this in ulora.py

      # setup the hardware SPI
        if self._spi_channel == SPIConfig.stm32_2 or self._spi_channel == SPIConfig.stm32_3:
            self.spi = SPI(self._spi_channel, baudrate=3000000)  # you can only get 3MHz on the BlackPill
        else:
            self.spi = SPI(self._spi_channel[0], 5000000,
                sck=Pin(self._spi_channel[1]), mosi=Pin(self._spi_channel[2]), miso=Pin(self._spi_channel[3]))

        print (f'self.spi = {self.spi}')

        try:
            self._spi_write(b'hello')
        except:
            print ('spi write failed')

I get some 'spi write failed' and then "LoRa initialization failed". Maybe, my try/except test is not valid and SPI comms with the RFM96W is what is really failing.

[davefes]

Traceback (most recent call last): File "ulora_modified.py", line 259, in _handle_interrupt AttributeError: 'LoRa' object has no attribute '_freq'

[davefes]

if self._freq >= 779: should it be if self.freq >= 779: ??

[davefes]

Yup, now:
Traceback (most recent call last): File "ulora_modified.py", line 271, in _handle_interrupt NameError: name 'BROADCAST_ADDRESS' isn't defined
Put that at the top and now the receiver stops working

[rkompass]

Yep. Sorry for so much little trouble, but, as you see (and I expected) self.freq is accessed from outside and therefore there is no need for the underscore. Perhaps the same with _pirq.
Oh - just see, it is internally accessed. So this was an incomplete change. freq seems better though.

[davefes]

For _pirq I did:

        # Setup the module
        gpio_interrupt = Pin(self._pirq, Pin.IN)
        gpio_interrupt.irq(trigger=Pin.IRQ_RISING, handler=self._handle_interrupt)
        self.reset()                                                       # reset the board
        self.set_mode(MODE_SLEEP | LONG_RANGE_MODE)                        # set mode
        sleep_ms(100)

[davefes]

My original server.py and Martyn's ulora.py works with a sender using ulora_rkompass.py
But with a modified server.py and ulora_modified.py the RX stops working. I looks like it is sitting waiting for an interrupt from the RFM96W.

[rkompass]

In line 271 it should be: if not header_flags & 0x80: # FLAGS_ACK = 0x80 , another miss of mine. But still this should give an exception as FLAGS_ACK would be an unknown variable. So this probably is not the culprit.
I would appreciate if you renamed the refactored driver to ulora_rfm95.py , or something similar:_)

I will solder in the next few hours and plug things together.
If you could specify what you did for the above observations it would be helpful to replicate.

[rkompass]

Continued on Martyns issues. SPI was no problem.

[davefes]

I re-named all my posts to ulora_modified.py. If you change your two posts then that "reference" will disappear.