BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - AT38

Pages: 1 [2]
16
Discussion - EVE / Re: FT81x Backlight not working?
« on: June 20, 2019, 03:01:20 PM »
I've gone back to an earlier commit and it seems to be working again.

Relieved. Thought I'd blown the hardware.  :-[

Darned odd though, as it worked until I power cycled.

I'll report back once I figure out what kind of stupid I've been.  ;)

Cheers.


17
Discussion - EVE / FT81x Backlight not working? [SOLVED]
« on: June 20, 2019, 11:08:47 AM »
Hi,

I'm currently developing on an ME813A-WH50C display module.

I've had several days of trouble free operation.

Last night I power cycled the board as part of a debugging process.

Since then the display has not worked.

I am able to communicate over SPI and read out the chip ID register as 0x7C.

On examination of the display, I noticed that the back light was not on (no light bleeding out at the edges).

I have measured the voltage on the backlight pin and it is zero.

I've read out the values of REG_PWM_DUTY and REG_PWM_HZ and verified that their values are correct, 0x80 and 250 respectively.

I've tried shorting out the backlight pin to 3V3. This enables the backlight, but also sinks 30mA into the FT813.

There was no contact with the module between working and non working states.

Only the power button of the bench top supply was touched. ESD seems unlikely.

The PSU outputs 5v and drops to 3.3v on the MCU board via a linear regulator, and on the display module via a buck converter. Surge damage seems unlikely.

Wiring between the boards looks ok, and would foul SPI comms if not.

Can anyone tell me:
1) Why this has happened,
2) How do I fix it (preferably without shorting the pin to 3V3)
3) How do I prevent this from happening again?

Cheers


EDIT:

I've loaded a display list and forced the backlight on, but it looks like nothing is being displayed.
Possibly all out pins at zero. I'm going to check PCLK and DISP next.

EDIT2:

PCLK is outputting at 1.13MHz, should be 30MHz

DISP, VSYNC, HSYNC and DE are all Zero.

18
Discussion - EVE / FT81x not rendering display lists? [SOLVED]
« on: June 03, 2019, 04:29:42 PM »
Hi folks.

I am in the process of moving my project from a back buffer based display to the FT81x

My target MCU is STM32F407 and I am using a Gameduino3 shield as a display dev board.

I have SPI comms up and running, reset the FT81x with the PWRDOWN and ACTIVE host commands,
wait for 7C in REG_ID, and enable the display by writing 0x80 to REG_GPIO and 5 to REG_PCLK.

I now have a black screen with a single red pixel in the top left corner. (could be the bottom right, but beside the point)

I have also written a simple display list to clear the screen to a distinct colour and finally written 1 to REG_DLSWAP to swap in the new list.

However, the display is still black with a single red pixel in the top left.

I've checked the display timings and verified that the default parameters are correct for this screen, and that also the gameduino library makes no changes to the timing registers.

Since I am able to reset, activate, read id and enable the display, I believe my SPI routines are working correctly.

I've also checked the Display List Command macros to make sure they're putting out the correct values.

I've had a jolly good look through the application notes, programmer's guide and data sheet, and I see nothing that I am missing.

I don't know why I have just a single red pixel in the corner of a black background.

My next step will be to start reading out registers and the display list, and verifying their values are correct.

But if anyone knows what causes this situation and how to fix it, I'd really appreciate it.

Cheers,

AT38


SOLVED:

Data is little-endian, address is big-endian. I was sending data as big-endian.

Pages: 1 [2]