16-bit SPI reads on STM32F413 - duplicated second byte
Port, board and/or hardware
stm32 port, NUCLEO-F413ZH board
MicroPython version
MicroPython v1.24.0-preview.449.g1b89c503d on 2024-10-20; NUCLEO-F413ZH with STM
32F413
Reproduction
Built with:
git clone git@github.com:micropython/micropython.git
cd micropython/ports/stm32
make BOARD=STM32F413ZH'
16-bit SPI reads work, with the same SPI device, on other platform(ESP32). On STM32 we observe two identical bytes, same as the 2nd one in normal operation
Expected behaviour
For reference, this is the same code (after initialization) run on ESP32
where it works like it should
MicroPython v1.23.0 on 2024-06-02; Generic ESP32 module with ESP32
Type "help()" for more information.
from machine import Pin, SPI
import struct, array
import binascii
spi=SPI(2)
spi.init(baudrate=1000000, polarity=0, phase=0, bits=16, firstbit=SPI.MSB, s
ck=Pin(18), miso=Pin(19), mosi=Pin(23))
cs = Pin(5, Pin.OUT, value=1)
bin = bytearray(2)
cs.off()
spi.write(struct.pack('>h', 0x5627))
spi.readinto(bin)
spi.readinto(bin)
binascii.hexlify(bin)
b'246a'
spi.write(struct.pack('>h', 0x5417))
spi.readinto(bin)
spi.readinto(bin)
binascii.hexlify(bin)
b'8f7b'
spi.write(struct.pack('>h', 0x5617))
spi.readinto(bin)
spi.readinto(bin)
binascii.hexlify(bin)
b'c840'
Observed behaviour
This is STM32 run. As we can see, the second byte of SPI.read is propagated
into the first one.
MicroPython v1.24.0-preview.449.g1b89c503d on 2024-10-20; NUCLEO-F413ZH with ST3
Type "help()" for more information.
from machine import Pin, SPI
import struct, array
import binascii
spi=SPI(2)
spi.init(baudrate=1000000, polarity=0, phase=0, bits=16, firstbit=SPI.MSB)
cs = Pin('B10', Pin.OUT, value=1)
miso = Pin('C2', Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI2)
mosi = Pin('B15', Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI2)
sck = Pin('B10', Pin.AF_PP, pull=Pin.PULL_UP, af=Pin.AF5_SPI2)cs.off()
bin = bytearray(2)
spi.write(struct.pack('>h', 0x5627))
spi.readinto(bin)
spi.readinto(bin)
binascii.hexlify(bin)
b'6a6a'
spi.write(struct.pack('>h', 0x5417))
spi.readinto(bin)
spi.readinto(bin)
binascii.hexlify(bin)
b'5151'
spi.write(struct.pack('>h', 0x5617))
spi.readinto(bin)
spi.readinto(bin)
binascii.hexlify(bin)
b'6a6a'
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree
Attempting to use SPI(6) on STM32H747BIT6 does not seem to work.
Port, board and/or hardware
I am using a custom board with STM32H747BIT6
MicroPython version
Micropython 1.23 on stm32h747BIT6 using a custom board.
Reproduction
Spi device is created with..
spi1 = SPI(6, baudrate=1000000, polarity=0, phase=0, bits=8 )
later attempt to write to this device generates a timeout.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "main.py", line 112, in <module>
File "valve_control.py", line 84, in init
File "valve_control.py", line 148, in drv_spi_write_buf
File "valve_control.py", line 131, in drv_spi_write_reg
OSError: [Errno 110] ETIMEDOUT
So the device appears to be there, I have defined thee pins in mpconfigboard.h
#define MICROPY_HW_SPI6_SCK (pyb_pin_SPI6_SCK)
#define MICROPY_HW_SPI6_MISO (pyb_pin_SPI6_MISO)
#define MICROPY_HW_SPI6_MOSI (pyb_pin_SPI6_MOSI)
Expected behaviour
I was expecting micropython to perform the write to the SPI6 port on the stm32h747BIT6 device.
Observed behaviour
However, I get the following instead.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "main.py", line 112, in <module>
File "valve_control.py", line 84, in init
File "valve_control.py", line 148, in drv_spi_write_buf
File "valve_control.py", line 131, in drv_spi_write_reg
OSError: [Errno 110] ETIMEDOUT
It is almost as if the pins are not actually being configured for output via the spi, like the alternate function register is not being set up?
I'm guessing this might be a bug in configuration management when micropython starts up, but so far I've not been able to find any documentation that indicates the correct way to set up a new hardware spi port.. The code appears to be there for SPI device 6. It just does not seem to actually function, though.
Additional Information
No, I've provided everything above.
Also, I THINK this is a bug, but it might be that I need to posts this some where else, if so, please provide me with a whack from a clue by four so I can put this in the right place.
Thanks!
Code of Conduct
Yes, I agree