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
ESP32S3N16R8：Missing flash ORIGINALLY 16M , ACTUALLY 8M
Port, board and/or hardware
esp32s3N16R8 port
MicroPython version
MicroPython v1.25.0 on 2025-04-15; Generic ESP32S3 module with Octal-SPIRAM with ESP32S3
<img width="1075" height="667" alt="Image" src="https://github.com/user-attachments/assets/3ee7bfa2-4046-4e5e-abd8-e6382d9e62a7" />
Reproduction
In according to official guidance , open powershell echo：
esptool --baud 460800 write_flash 0 .\ESP32_GENERIC_S3-SPIRAM_OCT-20250415-v1.25.0.bin
click RST button，and open thonny，execute
import esp
import gc
print(esp.flash_size())
print(esp.flash_user_start())
print(gc.mem_free())
you will find a problem like result below.
- First line is flash size ,equals 8M，corresponds to rom
- Second Line is user partition start，I know，
ESP32_GENERIC_S3-SPIRAM_OCT-20250415-v1.25.0.binis 1.5M , from 2M maybe reasonable. - Third Line is mem_free, corresponds to ram .
8388608
2097152
8320080
Actually my board is N16R8, means 16M psrom and 8M psram. after using Micropython bin, I got 8M rom , and 8M ram ,where is 8M left from flash?
I chose OCT version bin due to 8M psram, but normal and OCT version both miss flash size. I don't know why and how i need to do or it's something being limited.
And thonny is also 6m，maybe 8M-2M?
<img width="1427" height="700" alt="Image" src="https://github.com/user-attachments/assets/0b63906e-d976-478f-82e7-b166ddc521f8" />
Expected behaviour
get missed 8m flash size for using
Observed behaviour
like above.
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree