← index #8595Issue #6663
Off-topic · high · value 0.347
QUERY · ISSUE

pybd_sf2w: Code fails when located in external flash

openby peterhinchopened 2022-04-29updated 2022-06-09
port-stm32

Background: micro-gui test scripts displayed nothing when located in external flash. The code was evidently running, but the screen was blank. The scripts displayed when the display driver was located in the filesystem with all the rest of the code in spi flash. With all code except the driver in the filesystem, the script worked correctly if the driver was frozen normally, but failed to display if the driver was located in external flash.

The workround is simply to put the (small) driver in the filesystem but the fault appears to be symptomatic of a firmware issue.

When failing, the SPI transfer which occurs on initialisation was garbled, occurring as short incorrect bursts in place of one long sequence. The following test script demos the problem. Note that occasionally it runs correctly, but it usually fails.

import framebuf
import time
import gc
from machine import Pin, SPI

pp = Pin('EN_3V3')
pp(1)
time.sleep(1)

pdc = Pin('X1', Pin.OUT_PP, value=0)
pcs = Pin('X2', Pin.OUT_PP, value=1)
prst = Pin('X6', Pin.OUT_PP, value=1)
spi = SPI(2, baudrate=2_000_000)
gc.collect()  # Precaution before instantiating framebuf

class SSD1351(framebuf.FrameBuffer):

    def __init__(self, spi, pincs, pindc, pinrs, height=128, width=128):
        self.spi = spi
        self.pincs = pincs
        self.pindc = pindc  # 1 = data 0 = cmd
        self.height = height  # Required by Writer class
        self.width = width
        mode = framebuf.GS8  # Use 8bit greyscale for 8 bit color.
        gc.collect()
        self.buffer = bytearray(self.height * self.width)
        super().__init__(self.buffer, self.width, self.height, mode)
        self.linebuf = bytearray(self.width * 2)
        pinrs(0)  # Pulse the reset line
        time.sleep_ms(1)
        pinrs(1)
        time.sleep_ms(1)
        self._write(b'\xfd\x12\xfd\xb1\xae\xb3\xf1\xca\x7f\xa0\x74'\
        b'\x15\x00\x7f\x75\x00\x7f\xa1\x00\xa2\x00\xb5\x00\xab\x01'\
        b'\xb1\x32\xbe\x05\xa6\xc1\xc8\x80\xc8\xc7\x0f'\
        b'\xb4\xa0\xb5\x55\xb6\x01\xaf', 0)
        pinrs(0)  # For stand-alone test: pins are unconnected.
        pinrs(1)
        gc.collect()
        time.sleep(1)

    def _write(self, buf, dc):
        self.pincs(1)
        self.pindc(dc)
        self.pincs(0)
        self.spi.write(buf)
        self.pincs(1)

ssd = SSD1351(spi, pcs, pdc, prst)

I am writing to external flash with the following change to f722_qspi.ld and doing a clean build. The Pyboard is attached to no external hardware.

/* Define output sections */
SECTIONS
{
    .text_ext :
    {
        . = ALIGN(4);
        *frozen_content.o(.text* .rodata*)
        *lib/btstack/*(.text* .rodata*)

The following images show the behaviour where the transfer starts then prematurely terminates. No further data is transferred. Behaviour in the actual application is more complex, with further brief transfers with unexpected data occurring later.
Image
For comparison this is the start of a successful run:
Image
Zooming out of the failing run:
Image

Firmware:

MicroPython v1.18-355-g9ab66b50c-dirty on 2022-04-29; PYBD-SF2W with STM32F722IEK
CANDIDATE · ISSUE

RFC LCD160CR hardware/firmware

closedby peterhinchopened 2020-11-30updated 2024-08-19

This RFC is intended to create a record of issues I encountered interfacing an LCD160CR module with its official driver to ESP32. This was successful, enabling my GUI to run.

These notes might be of interest if a future hardware update occurs. Item 4 is a docs issue.

  1. I experienced sporadic initial I2C connection problems until I implemented code to assert PWR followed by a delay before instantiating the class. This implies that this delay should be increased. I can't claim this as proven, but I have had no issues since implementing this workround.
  2. The SPI interface appears to have no support for SS/. This precludes SPI bus sharing.
  3. The black connector P2 at the end of the PCB claims to support SPI, however the V1.0 schematic shows it being connected to different pins on the chip compared with the other SPI connections (SPI1_CLK vs SPI0_CLK, similar for MOSI). I don't know the reasoning here, but the SPI interface on the P2 connector doesn't seem to work.
  4. The docs provide links to a datasheet and schematic which are out of date. The current issue of both should be V1.1.

[EDIT]
This is my attempt at documenting how to interface an LCD160CR display to a non-pyboard host. Perhaps it will help flog a few units :)

Keyboard

j / / n
next pair
k / / p
previous pair
1 / / h
show query pane
2 / / l
show candidate pane
c
copy suggested comment
r
toggle reasoning
g i
go to index
?
show this help
esc
close overlays

press ? or esc to close

copied