• State
  • Locked Locked
  • Replies 16 replies
  • Subscribers 102 subscribers
  • Views 1126 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Beaglebone completely locks up after long idle times when custom LCD Cape is installed

Ali Asgar Sohanghpurwala
Prodigy 180 points
Other Parts Discussed in Thread: SN74AHC1G08

So we built a custom cape board to support a FEMA 4.3" LCD, and for the most part it seems to work great.

The problem is that if I leave the Bone on for long periods of time with our Cape Board plugged in the Bone will eventually lock up.  At this point the beaglebone is completely unresponsive: the serial console is dead, the LCD display is garbled, and I can no longer ssh into the board.  There are no kernel panics or other messages printed to the serial console.  I was able to ping the board though which suggests that maybe the MAC/PHY was still alive?

At first this seemed like some sort of power management issue, but even after disabling CPUIDLE and PM_SUSPEND in the kernel configuration, we see the same problem. 

In fact I tried a bunch of different configurations and only two things seemed to prevent the lockup: 1) disabling the LCD controller (comment out call to lcdc_init to setup PLL and pin mux) and 2) completely removing the cape board.  Even with the Cape board installed, but LCD flex cable unplugged we get the same issue.

The only major difference I see between our board and the EVM, ULCD, and other BeagleBoardToys capes is that we did not put down a 74AVC32T245 translator chip.  Are the LCD_DATA pins too weak to drive a 3.3V LCD directly?  If so could prolonged overloading of these pins cause the LCDC/MPU to lock up completely?

What's really odd is that the lockup occurs even with the LCD cable unplugged.  The only other active components on our board are an LT3593 backlight driver and SN74AHC1G08 AND gate.  Note that we populated R3 with a 0-ohm and did not populate R2, contrary to what the schematic says.

Any assistance you can give us in this matter would be greatly appreciated.

Schematic:

5125.FEMA_CAPE_TestBrd.pdf

Regards,
Ali

  • 0
    Prodigy 180 points

    Ok I've been testing various scenarios to try and isolate the problem.  Looks like the lockup only occurs if something is being displayed on the LCD.  IE if I run the bone wihtout the TI Matrix UI running it does not crash, it will eventually crash with the TI Matrix UI running.


    Does anybody have any insight here?  Has anyone left their BeagleBone or AM335XEVM running with an LCD on overnight?

    Ali

  • 0 in reply to Ali Asgar Sohanghpurwala
    Intellectual 315 points

    I did the same as you. But with some differences ....
    a) I have not used resistor on the data lines, soldered directly.
    b) I set the display to 16bit.
    c) I'm running an application in QT that I did it myself.

      Distributions I did with "BuildRoot" and compiled the QT.

    This running well. It appears only a problem in some pixel. Now I do not know if it's because I have not used 74AVC32T245. I'm still doing some testing.

    But this applications running well and I left a lot of time on.


    See you..

  • 0 in reply to Fabio Martins
    Prodigy 180 points

    Fabio, thanks for the feedback.  I might try setting the display to 16-bit to see if it still locks up, unfortunately if that is the only fix we will have to respin the board.

    I had looked into the drive strength of the AM335X  pins and it seems to have more than enough to drive the LCD we are using, I am not sure why TI used the buffer chip in all their designs, it would be nice if a TI employee could explain why the 74AVC32T245 was necessary.

    Now I have noticed that if I used the GPU acceleration with Qt5 and Qt4.8 it seems like there is a glitch in the center of the screen where a white square appears on screen updates.  Is this what you are seeing?

    Regards,

    Ali

  • 0 in reply to Ali Asgar Sohanghpurwala
    Intellectual 315 points

    Hello Ali,

    I usually figured it out in the figures. The figures are managed by SVG. I do not know how to use GPU acceleration, I will search if that may be the cause.

    Thank you.

    Let's wait for some help on the IT staff 74AVC32T245.

    thank you
    Fabio.

  • 0
    Prodigy 20 points

    Hello

    We need to develop a board for interfacing the beaglebone card with a LCD display

    We need to interface this display:

    http://www.femacorp.com/TFT/ColorTFT/7inchTFTLCD.html

    But we have poor knowledge in electronics, could you point me to some site where we can find the pinout description of the LCD lines and how to interface them to the beaglebone board?

    Regards

    Frank

  • 0
    Prodigy 20 points

    Hello

    We need to develop a board for interfacing the beaglebone card with a LCD display

    We need to interface this display:

    http://www.femacorp.com/TFT/ColorTFT/7inchTFTLCD.html

    But we have poor knowledge in electronics, could you point me to some site where we can find the pinout description of the LCD lines and how to interface them to the beaglebone board?

    Regards

    Frank

  • 0 in reply to Ali Asgar Sohanghpurwala
    Intellectual 360 points

    My guess is that the 74AVC32T245 is *not* necessary and it was put on there because if a static zap comes in on the LCD cable and fries the first chip it sees, it's probably a little better if it fries this chip and not the AM335x.. That's the logic I've seen before.. Of course it's a BGA like the SOC, and looks like it isn't trivial to replace it, so the difference doesn't seem to be that huge. Well, the 74AVC32T245 is 3 bucks, the AM335x is 30 bucks.. so there's a little cheap insurance. Also, if the zap kills the processor entirely as opposed to just killing the display section you have a board that is dead in the water instead of one that is merely crippled. How valuable this is depends on your application.

    It could also be for reliability.. If you have long cables to the LCD, driving all of that capacitance will tend to heat up the AM335x.. maybe you'd rather share that heat with the 74AVC32T245 instead? Thermal cycling can cause BGA solder joints to fail faster.. Will the cost of replacing one unit in the field pay for a whole production run's worth of 74AVC32T245 driver chips?

    I saw the 74AVC32T245 chip on the Beaglebone DVI cape.. it doesn't seem necessary there at all, (static zap argument doesn't apply, neither does the thermal argument) so I had the same question. I'm guessing it's on the DVI cape because someone copied it from a previous schematic? Like you, I'd like to hear TI chime in on the question.

  • 0 in reply to Ali Asgar Sohanghpurwala
    Prodigy 30 points

    Hello ali,

    i'm newbie using this board with lcd cape.what inch do u used for TI matrix UI.i'm using beaglebone ra6 with 3' tft version a2.

    i can only view my matrix app by remotely from my dekstop but nothing appear in my lcd cape.i dont know why, what is going on with my lcd cape?

    what a minimum resolution for matrix supporting...?

    anyone know thi issue..?

     

    azli

     

  • 0 in reply to azli fakhri
    Intellectual 360 points

    Azli, you might want to re-post this as a separate issue.

  • 0 in reply to Fabio Martins
    Prodigy 45 points

    Hello Fabio,
    Please can you provide the list of connections that you used to run the lcd 16 bit along with the beagle? If you can I'd appreciate it. thank you

  • 0 in reply to Tiago Ribeiro
    Intellectual 315 points

    What kind of LCD do you have? You're from Brazil?

  • 0 in reply to Fabio Martins
    Prodigy 45 points

    Yes i am from Brazil.

    The LCD i am using is that:
    http://elinux.org/images/0/07/AT070TN83.pdf

  • 0 in reply to Tiago Ribeiro
    Intellectual 315 points

    You already connected the pins? What exactly is your question? 

  • 0 in reply to Fabio Martins
    Prodigy 45 points

    Yes I connected the pins.
    Like this:

    BEAGLE                                    LCD


    DATA15-----------------------------R5

    DATA14-----------------------------R4

    DATA13-----------------------------R3

    DATA12-----------------------------R2

    DATA11-----------------------------R1

    DATA10-----------------------------G5

    DATA9-----------------------------G4

    DATA8-----------------------------G3

    DATA7-----------------------------G2

    DATA6-----------------------------G1

    DATA5-----------------------------G0

    DATA4-----------------------------B5

    DATA3-----------------------------B4

    DATA2-----------------------------B3

    DATA1-----------------------------B2

    DATA0-----------------------------B1

    LCD_EN-------------------------DE

    VSYNC---------------------------VS

    HSYNC---------------------------HS

    EHRPWM1A--------------------ADJ

    CLK------------------------------CLK

    think that the connections are correct?

    see this:
    http://elinux.org/4D_4.3_LCD_CAPE

  • 0 in reply to Tiago Ribeiro
    Intellectual 315 points

    Yes I connected that way too. Now the other connections as the LED driver are OK?
    A few more questions:
    Something show when you turn on?
    This display you are connecting directly or made ​​a board to interface them. Do you put EEPROM.?
    You changed the kernel?

  • 0 in reply to Fabio Martins
    Prodigy 45 points

    VLED - 5V

    VCC - 3,3V

    Yes, as did a separate interface between the LCD and the Beagle board, and put it to EEPROM CAT24C256.I did a file and even recorded it but did not work. Maybe I'm wrong setting, not given much attention in this part. I tried to boot with the Android SD card and that came in the angstrom beagle. When the LCD is turned on it is in white screen. But now he is in black screen gives no video signal transmitted.

    You have the file to memory?