Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Rudolph]

Ok, a datasheet is released now, but this leaves me a little confused.

So far EVE5 was anounced as BT822 with 1Gbit of embedded DDR3L.
And now we got a datasheet for a BT820 with up to 4GBit of external DDR memory?

The clock source is a 38.4MHz crystal, but the system clock is 72MHz?

The fonts remained unchanged - really?

As I predicted, the SPI host interface has been updated from 22 bit adressing.
But I am not 100% sure how it is working so far.

Ok, the BT820 has 31 bit adressing with the MSB beeing the "WR" bit, so writing when it is set to '1'.
Also it is Addr3, Addr2, Addr1, Addr0, followed by Data0, Data1 and so on.

As it always was since FT800, address and data use different byte orders, ok then.

When reading from the BT820 there no longer is a simple dummy byte though, first the address is send, then data is read untill 0x01 is returned, when 0x01 was returned the following transfers are for the actual data bytes.
Well, at least reads are less common and usually short.
I wonder how long that polling can last though.

"The transactions are word based, i.e., the data width must be in blocks of 32 bit when accessing the
registers and the DDR memory of the BT820. Addressing to the registers and the DDR memory must also
be word aligned, i.e., the last two bits of the received address is ignored"
"The write data is expected to be in blocks of 32-bit. Any incomplete data is discarded when SS_N deactivates."

Ok, I guess implementing rd8, rd16, wr8 and wr16 functions won't be necessary then.

That seems to be pretty clear so far.

Then we have host commands.
Ok, host commands are always 5 bytes long.
The ACTIVE command is just 0x00 0x00 0x00 0x00 0x00.
And writing parameters such as the the memory configuration is done with:
0xff Command Parameter 0x00 0x00
And then we still have POWERDOWN, STANDBY and SLEEP, at least.

So the host controller will do 32 bit transfers for the most part but still has to be able to do 8 bit tranfers,
for the host commands at startup and to poll for 0x01 during every read sequence, correct?


Now for the touch engine, turns out that resistive touch is not supported directly after all.
It is supported by using an external resistive touch controller that is connected via I2C.
Interesting.

A memory map is missing from the first revision of the datasheet.

And speaking of memory, that 1Gbit still is a surprise for me, I have no idea what this could be filled with.
Well, more can't really hurt, that "24-bit RGB framebuffer up to 2048 x 2048 pixels" would be 16Mbyte.
The registers, fonts, FIFO, ROM(s) and display lists likely also use regions in RAM.


The most interesting question is still when I can buy anything with a BT82x on it though. :-)

[BRT Community]

Hi Rudolph,

The BT820 will be launched at the EW2025 show in March and so not long to go now...
We'll have a development module too.

Great to hear that you're looking at the protocol etc. with a view to supporting BT82x in your code, and we'll keep everyone updated here as new documents / example code become available that will help with that.

Yes, you can use resistive and capacitive touch, with both using I2C connection to an external touch controller.

The memory map is actually in the Programmers guide for this device this time instead of the datasheet, and so we'll let you know once that document is available.

As you said, the frame buffer will use up some of the RAM and leaves plenty of RAM even with 1Gbit.

Best Regards, BRT Community

[Rudolph]

With the release of the BT820 getting closer, I did a analyses of the BT820 commands in comparision with the BT81x commands.

Display-List commands:
Mostly compatibel from the command number to the bits, with a few exceptions.
TAG, CLEAR_TAG - use 24 bits now instead of 8
BITMAP_HANDLE - uses 5 bits now instead of 4
CALL, JUMP - new valid range is 0...4095
PALETTE_SOURCE - uses 24 bits now instead of 22

New commands:
0x31 BITMAP_SOURCE_H, 0x32 PALETTE_SOURCEH - for the high byte of the extended address
0x33 BITMAP_ZORDER - "Set the z-order address pattern for a bitmap" - whatever this is, found chapter 2.17, still not sure
0x34 REGION - this is for a rendering optimization in the display list, by default all the co-processor widgets are using this

"missing" is the display-list command that would use 0x30 as identifier.

What I am missing:
There is no new graphics primitive to be used with BEGIN.
There is no VERTEX3F or VERTEX2F2 command using code 0x60 that uses a pixel precision of 1 pixel and 12 bits for the encoding with a range of -2048 to 2047 while encoding y in bits 0...11 and x in bits 16 to 28 to address the bottleneck that VERTEX2F and VERTEX2II are imposing.


Co-Processor commands:
Unfortunately except for CMD_DLSTART, CMD_SWAP and CMD_INTERRUPT, the command numbers are completely incompatible.
I really would have apreciated it if the new commands would have used numbers 0xFFFFFF71 and up.

A large number of commands moved back to using int16_t and in32_t types in the BRT_AN_086_BT82X-Series-Programming-Guide
while actually requiring uint16_t and uint32_t types: TEXT, BUTTON, KEYS, PROGRESS, SLIDER, SCROLLBAR, TOGGLE, GAUGE, CLOCK, CALIBRATE, ROTATE, SETMATRIX, TRACK, DIAL, NUMBER and ROTATEAROUND

The description for CMD_GETMATRIX still does not help me to understand what this is supposed to do.
CMD_MEDIAFIFO notes in the example: "0x100000 is the top of RAM_G"

Commands with incompatible changes to the API:
CMD_SETFONT is actually CMD_SETFONT2
CMD_INFLATE is actually CMD_INFLATE2
CMD_VIDEOSTART added options

Odd:
CMD_SNAPSHOT is not using the old CMD_SNAPSHOT2
CMD_APPENDF, never noticed this, applies to BT81x as well, documented to use REG_CMD_WRITE in contrast to CMD_APPEND which uses REG_CMD_DL, can't be true.

Removed:
CMD_ANIMFRAMERAM - the new CMD_ANIMFRAME plays from RAM_G, the original played from flash
CMD_ANIMSTARTRAM - the new CMD_ANIMSTARTRAM plays from RAM_G, the original played from flash
CMD_CLEARCACHE - why?
CMD_VIDEOSTARTF - somehow CMD_VIDEOSTART plays video from flash though
CMD_APILEVEL, CMD_FONTCACHE, CMD_FONTCACHEQUERY, CMD_PCLKFREQ
CMD_HSF - why?

New:
CMD_DDRSHUTDOWN, CMD_DDRSTARTUP
CMD_WAITCHANGE, CMD_GRAPHICSFINISH, CMD_WAITCOND, CMD_SKIPCOND, CMD_REGWRITE - unlikely to be used in real display lists?
CMD_FENCE - not sure what this is actually good for, yet
CMD_I2SSTARTUP - sounds like CMD_I2SSHUTDOWN might be missing
CMD_FSOPTIONS, CMD_FSREAD, CMD_FSSOURCE, CMD_FSSIZE - looks like a way to write files to SD card is missing
CMD_FSDIR - looks like a CMD_CHGDIR is missing?
CMD_SDATTACH, CMD_SDBLOCKREAD - looks like CMD_SDDETACH might be missing
CMD_PLAYWAV - oddly does not allow to play from RAM_G, a loophole would be to configure the MEDIAFIFO, does only complete when the playback ends
CMD_LOADWAV - oddly loads the sound into memory, sets the loop flag but does not play the sound
CMD_SAVECONTEXT / CMD_RESTORECONTEXT - no idea why these are commands, sending display-list commands to the co-processor works fine and all other display list commands are not added as co-processor commands
CMD_ENABLEREGION - allows to disable the render optimization for widgets
CMD_LOADASSET - loads files in new .reloc format, likely a EAB generated file which has a header before ZLIB / ZOPFLI compressed data - ah, yes, found chapter 2.12
CMD_WATCHDOG - the watchdog description is missing vital information, what the default timeout is after activation during system reset, how to actually reset the counter and what happens when the time runs out
CMD_TEXTDIM - calculates length and height in pixel for UTF-8 encoded texts
CMD_ARC - still specifies "If the angles specify a complete circle, a disc is drawn."
CMD_COPYLIST - not sure what this is good for and why it would be used with CMD_CALLIST and not CMD_APPEND
CMD_RESULT - hmm
CMD_CGRADIENT
CMD_GLOW
CMD_RENDERTARGET - found chapter 2.11, still not sure what this is about

[Rudolph]

Next part, registers.
I went thru the programming guide and put all registers in a spreadsheet to first get a kind of explicit memory map and to be able to sort the lines by register name for the export to a header file.

Just some bits of statistics.
There are fewer registers than I expected, a total of 155 are documented.
The documented memory regions have room for 1792 registers of 32 bits width.
There are at least three more undocumented memory regions that may have registers and have room for 320 more registers.

region/address/space for registers/registers used
EVE_REG_CORE_R1 0x7F006000 1024 114
EVE_REG_CORE_R2 0x7F004000 512 15

Odd, why not just use the region starting from 0x7F004000 for all registers and be done?

Some register groups are oddly spread over the memory like the REG_CMD registers:
REG_CMD_DL        0x7F006154
REG_CMD_READ    0x7F00614C
REG_CMD_WRITE   0x7F006150
REG_CMDB_SPACE 0x7F006594
REG_CMDB_WRITE 0x7F010000

Not that there is anything wrong with this, it just make me wonder why.

Some "holes" in the memory obviously have undocumented registers, like 0x7F006030 or 0x7F800308.
And then there are larger regions like 0xFf0061B8 to 0x7F006590.

Does this matter? No, of course not, it just leaves me curious.
And I wonder what is planned for alle the unused registers.


Then there a few odd things.

REG_TOUCH_SCREEN_XY and REG_CTOUCH_TOUCH0_XY use the same address
REG_TOUCH_RAW_XY  and REG_CTOUCH_TOUCHA_XY use the same address

This is not exactly new, I just wonder why this is still a thing and also why "Compatibility mode"
is the default setup in RED_CTOUCH_EXTEND when there is nothing to be compatible with and
the two supported resistive touch I2C controllers should be outliers and not the standard to be expected.
Well ok, single touch might not be the same as multi-touch and only using the first touch.

Then there is this:
REG_CTOUCH_TOUCH0_XY
REG_CTOUCH_TOUCHA_XY
REG_CTOUCH_TOUCHB_XY
REG_CTOUCH_TOUCHC_XY
REG_CTOUCH_TOUCH4_XY

And this:
REG_TOUCH_TAG
REG_TOUCH_TAG_XY
REG_TRACKER
REG_TOUCH_TAG1
REG_TOUCH_TAG1_XY
REG_TRACKER_1
REG_TOUCH_TAG2
REG_TOUCH_TAG2_XY
REG_TRACKER_2
REG_TOUCH_TAG3
REG_TOUCH_TAG3_XY
REG_TRACKER_3
REG_TOUCH_TAG4
REG_TOUCH_TAG4_XY
REG_TRACKER_4

Please consider renaming the first set in the programming guide to this:
REG_CTOUCH_TOUCH_XY
REG_CTOUCH_TOUCH1_XY
REG_CTOUCH_TOUCH2_XY
REG_CTOUCH_TOUCH3_XY
REG_CTOUCH_TOUCH4_XY

[Rudolph]

I have a question about the VM820C.

6.2 Selecting Power Source
When powering the system via USB-C (FT4222H interface) or 5V_Host (MPSSE or Host_MCU),
the maximum power supply is limited to 500mA at 5V. In cases where large LCD panels are used
or the power demand exceeds the available supply, it is strongly recommended to provide a 12V
power supply through the DC jack connector for the development module.

Ok, the limit on the USB-C probably is there because it is hardwired to USB-2.

But why is the host supply limited to 5V and 500mA?
From the schematic it looks to me that HOST_5V is only connected to VSYS which can also be powered by DC_IN.
So shouldn't it be HOST_DC with the same limit of 5...12V as for the DC_IN?

The RVT101 for example uses a higher voltage for the backlight to bring down the current on these lines.
So I do have a MCU board for this interface that uses a dedicated buck converter to provide 9.6V at these pins.


Edit: and a few question about the BT820 itself

Going over the host commands and the initialization sequence I noticed that the host command RST_PULSE has been removed from the BT820.
And instead of PD_N there is a RST_N pin now which pretty much does the same thing.

Does this mean that using RST_N with the BT82x is pretty much mandatory when doing a warm-start?

Then I am wondering when to raise RST_N again, there is a minimum time provided of 214µs to trigger a reset and that would be sufficent for a warm-start.
But then there also is this:

The RST_N signal must be de-asserted at least 5ms after the power rails from Group 4 have powered up.

Well, there is no way to tell for the host controller that the voltage rails are indeed powered up.
Given that the host controller also needs some time to boot, power up the oscillator and so on, is it save to assume that setting RST_N as early
as possible to low and raising it in the init function after an extra 6ms would be ok?

And the last question for the moment, FT81x and BT81x needed 20ms after raising PD_N before issuing the first host command.
I can not find such timing for the BT820 - any suggestions?

My idea is to initially try 1ms before sending BOOTCFGEN and see what happens.
But seeing "Figure 28 - Power State Transition" in the datasheet, there is actually a state after RSN_N = 1 : POWER UP INITIALIZATION.

Perhaps I am overthinking this but the initialization sequence in the programming guide might need a few extra steps to be complete.


Edit2:
With nothing (yet) to test against (but soon), I started implementing.
My initialization is sending out five host commands and apart from the timing (see above), at least the SPI traffic looks correct in the logic analyzer.
Now I am at the point in the initialization that suggests to read REG_BOOT_STATUS untill 0x522E2E2EU is returned.

I am looking at my EVE_memRead32() which is of course the implementation of the rd32() function mentioned in the programming guide.
Switching to 31 bit adressing was the easy part.
Adding the loop to read bytes untill 0x01 is returned or a break occured, done.

But looking at the logic analyzer trace with the failed read attempts as I have no BT820 attached so far,
I do not like this new read protocoll.

What is the supposed reaction when reading fails?
Ok, fair enough, I have no error detection up to BT81x either, if there is catastrophic failure, like when there is no EVE chip at all,
then the initial reading of 0x7c fails and my initialization would return EVE_FAIL_REGID_TIMEOUT.
So I guess I could add a REG_FAIL_BOOT_STATUS_TIMEOUT.
And then I am using a flag in my application module to indicate that initialization worked.

I previously observed that invalid data is read when the SPI clock is too high to properly work with my host interface setup,
so I had to reduce the clock or reading touch data would not work.

But what about the possibility of non catastrophic failures?
What drives the delay that prevents the BT820 from responding with 0x01 immediately?
Why is a BT82x even potentially slower in answering the SPI than FT80x, FT81x and BT81x?
Is a response guaranteed and what is the maximum acceptable number of bytes read that are not 0x01?
I would prefer a more deterministic read protocoll, even the need to send two dummy bytes instead of one would have been better.

Oh yes, SPI clock, is it true that there is no longer a limitation of 11MHz on the clock speed during initialization?

[Rudolph]

And it is alive. :-)

I have the BT820 on the VM820C running thru the boot sequence. :-)

Doesn't really do much so far, host commands are working, EVE_memRead32() is working.
The whole thing compiles with just two warnings for unused functions.

Still a long way to go.

I can not connect a display right now, an ER-TFT070-3 with cap touch arrived last week, it uses a 40pin LVDS connector which seems to be quite common.
Then I got myself a "Universal LVDS Signal Interface Converter DF14 20Pin to FPC 40Pin Connector" board to connect the display to.
I am still waiting on connectors and I just noticed that I might have forgotten to order an apapter PCB to connect the touch from the display to.

Right now I am running on a STM32F407, mostly for conveniance as I had a STM32CubeIDE project up and running and the Nucleo board was already connected to one of my boards with the FFC-20 connector I usually connect displays to.
Oh yes, and I have pins for the logic analyzer on my adapter boards.

So far everything for EVE2/EVE3/EVE4 is still in the library, maybe I keep it this way.

What did I learn from looking at the logic analyzer so far?
I just removed the delay between raising RESET_N and issuing the host commands and the BT820 seems to be booting fine, but I added 2ms delay there to be safe.
From the end of the ACTIVE command to the first response on the SPI are <34ms and this does not change with the delay between the raising of RESET_N and the host commands.
The very first response is 0x55 0xaa 0x55 0xaa.
The time from the start of the next SPI transfer that reads 0x2e 0x2e 0x2e 0x49 - which surprisingly means "coprocessor is running" - to the end of the boot when 0x2e 0x2e 0x2e 0x52 is returned takes around 27ms.
So maybe I will give the BT820 like 60ms to boot before checking the REG_BOOT_STATUS register.

On the unusual SPI read-protocol, I did continous reads thru the complete boot-sequence now.
And all the responses after the initial first answer had a 0x01 returned on the sixth byte after the address.
So for some odd reason the BT820 needs 5 dummy bytes when reading.
Just an observation, waiting for 0x01 returned is the documented way to go.

Oh, I just noticed, I enabled only DDR in SETBOOTCFG, not touch, audio or the watchdog.
Well, I could not use the watchdog as there is no hint in the programming guide so far on how to reset the timer.
Enabling touch and audio added about 100µs - but then there is no I2S chip on the board and I do not have a touch CTP connected.

Hmm, I just noticed that enabling audio has a side effect, the currect from my PSU nearly trippled.
I have my PSU set to 8V and the VM820C + my board are drawing 78mA without audio enabled.
And 220mA with audio enabled - strange.

This here feels like a blog, but I still would like to get a few answers out of this. :-)

[Rudolph]

Chapter 1.4 API Reference Definitions

wr32() -> EVE_memWrite32() - works
rd32() -> EVE_memRead32() - works
cmd() / cmd_*() / dl() - mostly the same as wr32(), all my commands go thru REG_CMDB_WRITE, if I ever would write the display list directly, I would use EVE_memWrite32().

Now for the fun part:
EVE_memRead8() - works, sort of
EVE_memRead16() - works, sort of
EVE_memWrite8() - does not work, memory is not changed
EVE_memWrite16() - does not work, memory is not changed

The rd8()/wr8()/rd16()/wr16() functions are not just omitted from the programming guide of the BT820, these do indeed not fully work.
From the datasheet, chapter 4.5.1 QSPI Host Interface Protocol:

The transactions are word based, i.e., the data width must be in blocks of 32 bit when accessing the
registers and the DDR memory of the BT820. Addressing to the registers and the DDR memory must also
be word aligned, i.e., the last two bits of the received address are ignored.

And

The write data is expected to be in blocks of 32-bit. Any incomplete data is discarded when SS_N deactivates.

So, not a surprise, I was expecting this, but I still had to try. :-)

My EVE_memRead8() and EVE_memRead16() work fine as long the address is word-aligned.
For example EVE_memRead8(REG_ID) returns 0x7C since all registers are word aligned of course and the bytes are read from Low-Byte to High-Byte.
Reading is only stopped before EVE is expecting it to.
Edit, EVE_memRead8(REG_ID+1) still returns 0x7C.

Writing, well, damn, the data really is discarded. :-)
Means I need to change some more things for the BT82x, for example writing only a byte to REG_CPURESET as it only uses 3 bit anyways is no longer an option.

[BRT Community]

Hello Rudolph,

Glad to see you are making progress with your testing!

Please let us know if there are any specific questions you may have concerning the BT820B protocols or if you run into any issues.

Best Regards,
BRT Community

[Rudolph]

Yeah, thank you! I am having fun here. :-)
And there is no need to rush things as no ready-to-use modules are available to far.

I just found this though: https://riverdi.com/product/15-6-eve5-display
For "Embedded" this is nutz, they even added "External DDR3 SDRAM: 4Gbits".
Can't wait to use this with an Arduino UNO. :-)
Anyways, I put my name on the waiting list.
I wouldn't mind 7" or 10", I still have no idea where to put a 15.6" on my desk - desperately need to spring-clean.

I am hoping to use the panel I bought by the end of the weekend, can not connect touch so far though.

Edit: turns out that the "driver-board" I bought to adapt between VM820C LVDS and the 40pin FFC on the LCD is a bigger issue than I anticipated.
It is a "PCB800182" and there is very little real information for it available.

After a bit of reverse-engineering I know that the board uses a PT4103 as step-up converter for the backlight.
The image on EBay from the seller I bought from shows a feedback resistor of 1R which would mean about 100mA backlight current.
Populated however is a 0.68R -> 150mA - and the LCD I bought specifies 120mA max.

And since the backlight driver is supplied with the 3.3V from the LVDS connection and the backlight voltage is 9.6V typical,  the current drawn is about 2.9 x of the backlight current, 435mA might be a bit much.
I will populate 4.7R for 22mA, that should be more reasonable.

Why am I not using the backlight driver on the VM820C? I would like to, but there is no header for LEDA / LEDK on the VM820C, these are only connected to CN4 which is the 45pin LCD header.
There is CN7 which has BKLIT_PWM and DC_IN, but there is no indication what make and model CN7 actually is beyond that it is a 2mm connector.
And since it uses DC_IN, this would remove the option to only power the VM820C from USB or the HOST interface.
Well, the PT4103 is only rated for 2.5V to 6V anyways, so using CN7 would mean to limit DC_IN to below 6V.

And then I am not sure yet what the extra pins on the TFT side of the PCB800182 are configured to.
It is very likely setup for 8 bit operation.
RESET and STBYB should be connected to 3.3V.
That leaves VCOM, DIMO, AVDD, L/R, U/D, VGL, CANCEN0, CABCEN1 and VGH.

Well, the pinout on the 40pin FFC of the PCB800182 is the same as on the ER-TFT070 LCD.

[Rudolph]

Ok, I am trying to figure out how to configure the display output and I doubt now that my display will show anything by tomorrow.

With host command RST_PULSE removed, is using the pin PD_N / RST_N mandatory now?

What is the minimum recommended time to wait after raising RST_N?

Any suggestions on what to do if rd32() fails to read due to not receiving 0x01?

How to actually configure the display output? There is close to nothing so far in the programming guide.
What needs to be configured and in what order?
How do the older register like REG_HSYNC0 interact with the LVDSTX settings?
How do the REG_RE_ and REG_SO_ registers interact with this?

Where in the initialization sequence is setting up the Swap Chains supposed to be placed?
How is the size of a SwapChain buffer calculated? REG_SCx_SIZE holds the number of buffers, not their size. From REG_RE_FORMAT, REG_RE_H and REG_RE_W?

Why do the examples use different names for the registers than the programming guide? e.g. REG_LVDS_* -> REG_LVDSTX_*

How is the watchdog used?

With REG_TOUCH_RZTHRESH gone, how to configure the sensitivity of resistive touch?

[Rudolph]

A new milestone. :-)

I got to the point in reverse engineering the PCB800182 deep enough to be confident to attach my LCD to - and nothing bad happened, no magic smoke. :-)
I also modified the 20pin LVDS cable that came with the PCB800182 to use a 30pin connector with a single LVDS channel to attach to the VM820C.

So I tried to wiggle my way thru the initialization sequence.
First issue, there are no timing parameters in the "datasheet" of the ER-TFT070-3 I bought - argh.
Well, I checked what I have used for the BT817 7" with 1024x600.
 
To configure the LVDS output I came up with this:

Code: [Select]

void configure_lvds(void)
{
    EVE_memWrite32(REG_RE_DEST, EVE_SWAPCHAIN_0);
    EVE_memWrite32(REG_RE_FORMAT, EVE_ARGB8);
    EVE_memWrite32(REG_RE_W, EVE_HSIZE);
    EVE_memWrite32(REG_RE_H, EVE_VSIZE);
    EVE_memWrite32(REG_DISP, 1);

    EVE_memWrite32(REG_LVDSTX_PLLCFG, setlvdspll_value(0, PLL_LOCK_PERIOD, 1, 10, 7)); /* 38.4 MHz * 10 / 8 = 48MHz */
    EVE_memWrite32(REG_LVDSTX_EN, LVDS_CH0_EN);

    EVE_memWrite32(REG_SC0_RESET, 1);
    EVE_memWrite32(REG_SC0_SIZE, 2);
    EVE_memWrite32(REG_SC0_PTR0, 10 << 20);
    EVE_memWrite32(REG_SC0_PTR1, 20 << 20);

//    EVE_memWrite32(REG_SC1_SIZE, 2);
//    EVE_memWrite32(REG_SC1_PTR0, SC1_PTR0_STARTADDR);
//    EVE_memWrite32(REG_SC1_PTR1, SC1_PTR1_STARTADDR);

//    EVE_memWrite32(REG_SC2_SIZE, 2);
//    EVE_memWrite32(REG_SC2_PTR0, SC2_PTR0_STARTADDR);
//    EVE_memWrite32(REG_SC2_PTR1, SC2_PTR1_STARTADDR);

    EVE_memWrite32(REG_SO_EN, 0);
    EVE_memWrite32(REG_SO_MODE, EVE_SO_MODE_2);
    EVE_memWrite32(REG_SO_SOURCE, EVE_SWAPCHAIN_0);
    EVE_memWrite32(REG_SO_FORMAT, EVE_ARGB8);
    EVE_memWrite32(REG_SO_EN, 1UL); /* enable scanout */

    DELAY_MS(10);

}

But I am not sure if I got all the necessary register, if the order of writing them is correct and if I chose
values for all registers that actually make sense.

And it is not working, or only somewhat a little bit working.
I do get a white screen with some artifacts in the end.

I am not even sure how this all makes sense so far.
Why is there a REG_RE_FORMAT and a REG_SO_FORMAT?

Making this all configureable will be a challenge. :-)


Edit: I modified things a bit, changed the timing, switched the clock to 51.2MHz as suggested in the display controller datasheet of the LCD I have.
I also added:
EVE_memWrite32(REG_LVDSTX_CTRL_CH0, 1); /* JEIDA/Format 1 Mapping for 24-bit, Single Pixel per Clock */

And I am reading REG_LVDSTX_ERR_STAT and REG_LVDSTX_STAT now.
REG_LVDSTX_ERR_STAT reads as 3 which means: UNDERFLOW_CH0 + OVERFLOW_CH0

Hmm? Schroedingers LVDS, empty and full at the same time? :-)

The value of REG_LVDSTX_STAT changes with the value I put in REG_LVDSTX_CTRL_CH0
REG_LVDSTX_CTRL_CH0 = 0 -> REG_LVDSTX_STAT = 0x000015d1
REG_LVDSTX_CTRL_CH0 = 1 -> REG_LVDSTX_STAT = 0x00001791
REG_LVDSTX_CTRL_CH0 = 2 -> REG_LVDSTX_STAT = 0x00000fd1
REG_LVDSTX_CTRL_CH0 = 3 -> REG_LVDSTX_STAT = 0x00000e31

Bit 0 set = LVDSPLL_LOCK / PLL locked - that sounds correct
Bit 4 set = LVDS_CH0_ACTIVE - looking good
Bit 5 to 8 = LVDS_CH0_UNDFCNT - 14/12/14/1
Bit 9 to 12 = LVDS_CH0_OVFCNT - 10/11/7/7

The display is configured to 8 bit per color, SELB is set to GND, so REG_LVDSTX_CTRL_CH0 should be set to 1 or 2 (default).

What am I doing wrong?

[Rudolph]

I am getting closer,but the output on my LCD still is corrupted.
But at least I can see that there is something going on now, I am using CMD_LOGO and there is some movement in the chaos for a couple of seconds.

I found that my function of calculating the value for REG_LVDSTX_PLLCFG was completely broken.
But after fixing it, it still does not work.
As it turns out, the description for REG_LVDSTX_PLLCFG in the programming guide is wrong.
The reset default value is 0x00300877 - and that is correctly stated.
"Table 18 – LVDSTX Clock Configuration" can not be correct though, first indication is that 15 and 8 are not the default values.

And in the datasheet I finally found this:

4.12.2 Phase Locked Loop
There are 4 Phase Locked Loops (PLLs) inside the chip; the system PLL (PLL1), LVDSPLL (PLL2), DDRPLL
(PLL3) and the DDR PHYPLL (PLL4)
The system PLL receives the input clock from the oscillator and produce both the system clock and the
LVDSTX clock.
The LVDS PLL takes the input clock from the LVDSTX clock and generates the LVDS fast clock.
The DDRPLL and the DDR PHYPLL are used to generate clock for the DDR interface.

And while this not quite cleary written, it shows that that input for the LVDSPLL (PLL2) is not the Oscillator with 38.4MHz,
but the system clock that is generated by the system PLL (PLL1) and which defaults to 72MHz.

So when I tried to use NS = 8 and CLKDIV = 5 in order to setup the LVDSTX clock to 51.2MHz, I was setting it up to 96MHz instead,
which is out of spec for the LCD I have.

The default value of 0x00300877 should result in a pixel clock of 63MHz, however LVDSPLL_CK is configured incorrectly to 0b01, if I am understanding the
programming guide correctly, that would be for a CTLCLK range of 200MHz to 400MHz, NS = 7 and input = 72MHz results in 504MHz though.
So a valid default value should have been 0x00301077.

And with 72MHz as input for the LVDSTX PLL I can not set the clock to 51.2MHz - pretty close to 51.43MHz though.

There is no maximum range given for either SYSPLL_CKS or LVDSPLL_CK, according to REG_SYS_CFG and REG_LVDS_PLLCFG it might be
400MHz to 800MHz for SYSPLL_CKS and 200MHz to 800MHz for LVDSPLL_CK.
That would put the valid range for NS of system clock to a range of 11 to 20 while 72MHz might be the the highest Systemclock allowed.

And with 72MHz system clock the allowed range for NS of the LVDSTX PLL would be 3 to 12.
But well, the allowed range for the system clock might be 36MHz to 72MHz.

If I am correct on this, please provide updated versions of both the DS_BT820 and BRT_AN_086_BT82X-Series-Programming-Guide
with more and accurate information.

Oh yes, I also found BRT_AN_092-BT820-Hardware-Design-Example, unfortunately there is nothing in there on setting up LVDSTX.

Another source of information could have been EVE Screen Editor.
However, v5.0.0 only shows a fraction of the the registers in RAM_REG and there are no built-in settings for connecting to a 1024x600 LCD.

[Rudolph]

And I am celebrating the first stable output on a LCD from the BT820! 

I am still having a weird timing issue, the output of the 1024 x 600 image is only to 3/4 of the width of the screen.
And nothing I did to the timing parameters so far made that smaller or wider, it only changes from stable to chaos.

Edit:
And now I have the image stretched across the complete display area. 

Looks like my PixelClock was too low.
With some trial and error I ended up with NS = 7 and DIV = 4 - REG_LVDSTX_PLLCFG = 0x00300874
NS = 7 and DIV = 2 is not working.
NS = 7 and DIV = 3 to DIV = F is working, although it starts to flicker at DIV = B.
NS = 8 and DIV = F is not working, although this should only be a little higher than NS = 7 and DIV = F.

My guess is that the description of REG_LVDSTX_PLLCFG is not correct.
But I can not measure the resulting pixel clock directly, I do not have an oscilloscope here.

[Rudolph]

How do I use the touch engine?
As far as I understand it, setting bit 6 in SETBOOTCFG should be enough, this should enable the touch system and
during boot the touch system should do an auto-discovery to determine the touch controller connected.

My LCD does have a FT5316 and after connecting it to the VM820C it does nothing at all.
Reading REG_TOUCH_CONFIG returns 0x00000000, writing 0 or 0x381 does nothing either.

I can not calibrate and reading REG_TOUCH_RAW_XY returns 0xFFFFFFFF.

It should not be necessary to setup CTP_SCL/GPIO5, CPT_SDA/GPIO6, CTP_INT/GPIO7 or CTP_RST/GPIO8 in order to use the touch engine.
But then I can not find how to actually set this up anyways, how to configure them for alternate function or GPIO.

Edit: I soldered pins and to the FFC adapter I am using for the touch controller and looking at SCL, SDA and Reset with the logic analyzer.
And while the pins wiggle like expected for their function, the touch controller does not seem to answer.

What is odd though, when I write 0x381UL to REG_TOUCH_CONFIG to setup a FocalTech device, the lines are just dead.
SCL is Low - really odd for an open collector ouput with pullup-resistor, SDA and Reset are high.

When I write 0x380UL to REG_TOUCH_CONFIG, which should not do much according to the register description,
apparently auto discovery is triggered, Reset is pulled low, then there is a pause and then there is one or two byte transfers on SCL/SDA.
Same thing happens when not writing to REG_TOUCH_CONFIG or when writing 0.

Oddly I also see 311ms periods with SCL just low like this, even when I disconnect the CTP.

Maybe my touch controller is toast, but what the BT820 does is not looking correct either.

Looks like I need to check the touch controller with an Arduino, there was some I2C scan sketch somewhere.
Edit: I did just that, I have an Arduino UNO running at 3.3V with 4k7 pullup resistors to 3.3V scan the I2C right now, connected to the CTP of the display as written on it's FFC cable: 1 = GND, 2 = SDA, 3 = SCL, 7 = VDD - and nothing is found.
Strange.


Edit: I found the issue, I do have working touch now. 

The connector on the 10pin FFC adapter board I am using looks like is contacting on both sides of the cable,
but it definately is only contacting on the bottom side.
The cable for the CTP has the contacts on the top side...

Have two fotos to celebrate. :-)
Yes, I noticed that the backlight is a bit dim, but I can't control it by software and only set it to 20mA, maybe I'll add another resistor in parallel later.


Edit: I just put up a repository with the information from reverse engineering this display adapter: https://github.com/RudolphRiedel/PCB800182_LCD_Adapter

[BRT Community]

Hi Rudolph,

Congratulations on getting the BT810B up and running on your board !
Glad to hear that you found the cause of the issue with the contact side on the touch connector already and that it's working well now.

Is your picture nice and stable now on the display too?
We'll check the definitions of the REG_LVDSTX_PLLCFG in the guide.

Best Regards, BRT Community