Device Tree Overlay & Pitft display?

peepo

is a device tree overlay for the LogiPi available?
RPi B or RPi 2?

I now have my SPI Pitft 320x240 display working on RPi B using device tree**
but when I add LogiPi screen no longer shows console text,
changes from white to black to grey.
is this expected behaviour?

this is a brand new uptodate install of raspian,
there are no peripherals attached, ethernet only.
logi

https://www.raspberrypi.org/forums/viewtopic.php?f=41&t=110634&p=761236

jpiat

Hi,

we don't have a specific device-tree overlay for the LOGI-Pi. The LOGI-Pi requires to have spi and i2c enabled and both can be activated using the dtparam argument in the config.txt (see logi-tool github page).

The SPI piTFT usually uses the SPI port and the two chip select, so i guess that the problem can come from the FPGA messing up with the SPI pins and thus preventing the SPI display to work. Do you have the schematic of the SPI display ? Are you using a LOGI-PI v1 or V2 ?

peepo

I have 2x LogiPi v1 on RPi B, (did not yet get RPi 2 working with this display.)

SPI schematics pages 69-71:
https://learn.adafruit.com/downloads/pdf/adafruit-pitft-28-inch-resistive-touchscreen-display-raspberry-pi.pdf

sudo nano /boot/config.txt
...
dtoverlay=pitft28-resistive,...

I added
dtparam=i2c=on
without result

jpiat

The i2c is not used on the LOGI-Pi v1 so i guess that the problem comes from the SPI. The display problem occurs even if the FPGA is not loaded ? One problem that can also occur is that the FPGA config pins are exposed on the raspberry pi GPIO header and these pins are used by the LCD ... From what i see on the schematic, the interrupt pin of the touchscreen is connected to the PROG_B pin of the FPGA. This PROG_B pin triggers a configuration on the FPGA which takes control of the SPI pins (this might be one explanation).

Another explanation could be that the FPGA loads the SPI pins and prevent them to run at the configured speed for the LCD. Could you try to see if you can lower the SPI speed of the LCD ?

peepo

okay, just to be clear, in fact logi-tools is not installed, though LogiPi power up green light is on.

1M works on RPi, but not with LogiPi
also tried 500k on LogiPi & 320k on RPi these did not work,

ps ax
  288 ?        S<     0:00 [20204000.spi]

peepo

Jonathan,

please could you suggest alternate pins to try?
or other workaround?

I only connected pins 19 21 23 25 2 22 24
ie mosi miso sclk gnd 5v spio, on RPi
pin 22 or GPIO25 timing? sets horizontal offset

RPi displays as normal
LogiPi display shows all white, does not setup.

peepo

perhaps there is a way to switch off SPI on LogiPI?
and use JTAG to load hardware.

it seems that something is happening on SPI as soon as power is applied?
pin 18 RP_GPIO_GEN5_PROG_B is not connected for display as above
pin 21 miso is also not needed.

so only pins 19 23 25 2 22 24

jpiat

The SPI pins of the FPGA are left floating if the FPGA is not configured. Pins 11 and 12 of the raspberry pi connectors are also used to set the programming mode (self boot from flash or slave serial configuration), depending on the state of these pins, the FPGA could try to load itself and thus take control of the SPI bus. The default mode on these pins is 11 which should denote slave serial configuration. By default the configuration flash of the FPGA isnot selected (CS high)  but could also cause interferences on the bus. Any idea of what could go wrong @mjones ; ?

mjones

@jpiat which CS pin are you using to communicate with the FPGA?  

@peepo How will you use the FPGA if you cannot comunicate between the FPGA and the Rpi?

The biggest killer here would be the shared use of the PRGB pin.  It is the reset for the FPGA.  If the pin is ever pulled low it will reset the FPGA.

peepo

Mike,

thanks for getting back, this tft dsiplay runs okay using only pins 19 23 25 2 22 24 it has touchscreen etc, but that is minimum.
 the screen is detached and wire is connecting.

as jpiat suggests, in theory one might use logi_loader, reboot and then use SPI for display,
rebooting does not seem to effect hardware running on LogiPi.
alternately use JTAG to load hardware,
I'm currently using uart to communicate, though i2c is a possibility.

what needs clarification, is why the display works when these pins are directly connected to RPi 1 or 2,
but not when connected to the same pins on LogiPi, even though Logi-tools is not installed and hence Logi_loader has not been run,
so presumably there is no hardware running?

anyway please excuse my ignorance,
I had assumed it might be possible to run SPI display with LogiPi?
is it likely there is a way?

mjones

It is hard to say what the current problem is.  

It might be possible to run things but it will take careful inspections of pins states on the FPGA and the TFT display.  Even if the pins are not being used on the TFT there may still be conflict with one of the unused pins and the FPGA.  The LOGI PI V2 uses an i2c gpio expander to detach all of the fgpa config pins from the Pi header so that minimal conflicts arise - this could be a longer term solution if the conflict is not resolvable. 

1) We need to find out which pin Jonathan is using for the Rpi/LOGI communication.  It sounds like you might be able to communicate with the FPGA and with the TFT display if they are using different CS pins.  

2) It would be best if you force the FPGA into reset with the TFT attached and see if the TFT runs OK.  The reset will force HiZ on all FPGA pins.  But this will also force the PRGB pin low which may conflict with the TFT.  You can short pins 1-2 on the J6 header of the LOGI Pi to force the FPGA into reset.  This will help to pin point the current conflict you are experiencing.

If TFT is not running still you will need to inspect the pin states and determine if a pin is being held low or high when it is not supposed to be, monitor the SPI sck,mosi, cs pins to see if they are running as expected.

Run further steps from here depending on the results of above tests.  

peepo

Mike,

V2 may be way to go, for now on V1,
do hope this is not spam:

Pin states tested for RPi 1: 19 23 25 2 22 24
RPi alone pin 22 is +3.28v
with LogiPi V1 +0.9v
other 5 pins did not appear to change.[1]

tft display was not connected for these tests.**

thanks again

Jonathan

[1] I assume as my skills and kit are basic, other variations may not be relevant:
pins 23 and 24 appear to fluctuate and may have a slightly broader range with LogiPi?
pin 23 0.00v to 0.05v, pin 24 3.19v to 3.24v

**further notes regarding Mike's post above

1) not quite sure what is meant, please expand.
my most recent tests involved RX and TX pins to send data from fpga to RPi

2) I mounted TFT display on LogiPi V1 on RPI B, then shorted JTAG pins 1 and 2 this caused RPi to reboot.
display responded as per normal boot. ie the display does not run through its normal routine, and goes to grey.
for completeness tested again connecting only pins 19 23 25 2 22 24 same result.


I am trying to find a good way to use a small portable display.

The usb DFRobot tft display is hard to setup, it requires rather old kernel, or complete kernel build
Their website has been seriously hacked for quite some time, which also is not good

The Adafruit type tft display is much easier to setup using device tree on current kernel,
and easy to mount using GPIO ))

peepo

further to above:
if RPi 1 pin 22 is not connected to display at boot time,
display does not go through setup and is not operational.
LogiPi not connected.

mjones

Do not short pin1/2 of the JTAG header (J5) this shorts 3.3V to gnd.  

Short Pins 1/2 of P6 as shown in the image.  What happens with the LCD when you do this?

peepo

no effect

this is quite hard, as display effectively covers FPGA, but I tried twice with good contact in each case.

mjones

Dang.  Well it appears that it is not the FPGA pins that are the problem - other than possibly the PRGB pin.  It could also be a pull-up/down on the board that is the problem which would be seen in the following "DC" test.  

Next step you would need to go through is evaluating the pins states of pin of concern with the LCD running - withouit the LPi attached - then do the same thing with the Lpi attached to see if you see any DC differences.  

You will have a hard time doing debugging further, watching the SPI transaction, etc without a scope.

peepo

when I attach LCD to RPi only with wire connectors to pins 19 23 25 2 22 24 it works

RPi alone pin 22 is +3.28v

however when LogiPi only is attached pin 22 is V1 +0.9v

mjones

Ahhh, yes the done pin could be an issue.  The schematic on your referenced link is unreadable for what Pin 22 is doing on the LCD.  Do you know what pin 22 functions as on the LCD?

What happens if you disconnect the pin 22 pin from your wire connector test you did previously?  What happens if you tie it directly to 3.3V?

Done pin description on page 31.  It is pulled low when the FPGA is not configured.  It must be creating a voltage divider with the LCD which produces the .9V

http://www.xilinx.com/support/documentation/user_guides/ug380.pdf

It is possible to remove the Done pin from connecting to pin22 of the Pi header and it would work ok (would get an error wehn running logi-loader but it would still load fine).  This would require cutting a trace on the PCB, so you may not want to do this, especially if you don't know that if that is the only problem....

peepo

looking good, got stuck in, so not today...

LCD does work with LPi provided pin22 is looped around, only checked with pins 19 23 25 2 22 24
so when I get a chance will check against all pins,
then we can cut a trace, if we get that far....

thanks again

~:"

rather confusingly Logi_loader reports: Init pin not going high !
when one is running the Rpi logi_loader on RPi2
it does also report: Loader was compiled for PIB/B+/A/A+
but....

peepo

cutting the trace on LogiPi 'done' above RPi pin 22 : wfm!

only a few tests such as:

sudo cat /dev/urandom > /dev/fb1
and logi_loader vga_bar.bit

seems to boot okay without display and run logi_loader
not yet found an error message though...

many thanks once again

~:"

mjones

Great to hear!