TTL RGB OUTPUT Normallly High during VSYNC

[coucouillu]

Hi @KerJoe

On RTD2660, and with TTL mode , I try to get all RGB output normally HIGH while now they are normally LOW.
I am turning around since weeks now without finding a solution.
Could someone help me to find the correct REGISTER setting from the RTD2660
It should be like an INVERSION setting like I did for the VSYNC and HSYNC signals but cant' find it for the RGB outputs.

See in the example here, RED signal is currently normally LOW from my RTD2660 (first picture)
I need to obtain HIGH output like that (signals RED and GREEN) captured for the source I need to reproduce (second picture).

I tried to tweak Address 29 bit0 but without success.
Any advise?
Thank you for your help

[KerJoe]

Have you tried the following sequence?

ScalerWriteBit(S_VDISP_CONTROL, 1, 0b0) // Clamp data bus to 0
ScalerWriteBit(S_VDISP_CONTROL, 6, 0b1) // Enable data bus inversion
ScalerWriteBit(S_VDISP_CONTROL, 1, 0b1) // Restore normal data bus output

[coucouillu]

Hi @KerJoe
This sequence does not seems to work. no impact on RGB output. Seems weird. I will try more deeper before coming back to you. Thank you for your reply.

[coucouillu]

Hi @KerJoe
I was not initially on your code but on another relying on KeilV5.

So, I switched to your code and I am now able to compile and flash through Windows.

As your code is not structured like the previous I was working on, could you please precise where to put the sequence in your code please?

My goal is to put at the start of the power of the screen with a background screen in order to sniff signals with the USB analyser without need to input signal to the board (VGA, HDMI etc..).

ScalerWriteBit(S_VDISP_CONTROL, 1, 0b0) // Clamp data bus to 0
ScalerWriteBit(S_VDISP_CONTROL, 6, 0b1) // Enable data bus inversion
ScalerWriteBit(S_VDISP_CONTROL, 1, 0b1) // Restore normal data bus output

thanks

[KerJoe]

You can try inserting those 3 lines after InitScaler() call in core/main.c.
And add the while loop (while(1);) after SetOverlayColor() to stay in the background output mode.

[coucouillu]

Hi @KerJoe,

Unfortunately, I compared before the new settings and after the new settings : these settings have no effect.
I worry that this RTD2660 can't manage RGB normally High during VSYNC Period . If it is confirmed, my project is down.
Same results as the other source code for RTD2660 that I tried since weeks

In details :
I took your code
I switched from LVDS to TTL (#define PANEL_TYPE TTL) in (panel_config.h)
I add the settings you shared.
compile+load+scan

What i get :

[KerJoe]

By the way, why do you need the data bus to be high during the VSYNC period?

[coucouillu]

Hi @KerJoe
The panel I need to connect has an exotic signal. It is a proprietary signal without any datasheet available. I succeed to reverse engineer the signal with a logic analyser and generate a video test picture with an ESP32-S3 and then with a FPGA TANG NANO 9 to confirm the expected signal. Now I need to switch to RTD266x in order to have the VGA/HDMI inputs. My current code that I branched from yours generate a signal at 80% OK except the High level of RGB during BACK_PORCH+VSYNC+FRONT_PORCH period (you notice that currently VSYNC signal during "BACK_PORCH+VSYNC+FRONT_PORCH" period is not good too but it is not a matter because I was able to generate it correctly with another code. So I know that VSYNC signal issue is feasable. But for High RGB, I have no clue yet.

Could we go further together with tests on your side for the RGB output matter ? Do the settings have effect on your side? This is weird that they change nothing on my signal.
And again thank you for your time

Reminder what i get :

what I need to generate ("VSYNC PERIOD" on the picture may include the PORCHS) :

[KerJoe]

Ok, I'll see what I can do on my board.
If all else fails maybe you can try using some high speed logic gates on the output... just a thought.

[Coucouillu2009]

For the high speed logic gates I thought about it but I conclude that will not work during the 2 PORCH periods. Without a firmware solution, my project is dead :( In still continue to search on my side but I explorered all ideas without success. And again, fornme the weird thing is that I do not understand why your proposal settings have no effect. It is like they are inhibited. Are you able to exchange with the RTD through a serial terminal for debugging ? I would like use some PRINTF functions to monitor values but don't know how.

[KerJoe]

Ok, I've managed to recreate the output. The starting and ending hsync pulses in data bits are slightly cut short, but hopefully that won't be a problem.

1. VSYNC
2. Data bus bit
3. TCON[0] (Data inversion)
4. HSYNC

Here's the code:

    InitScaler();
    SetOverlayColor(0xff, 0xff, 0xff);

/////////////////////////////////////    

    // TODO: Modify scaler_registers.h to use these macro names
#   define SP_TCON_VSTA_LO(n)       (0x08 + n * 8) // TCON[n] Vertical Start LByte
#   define SP_TCON_VEND_VSTA_HI(n)  (0x09 + n * 8) // TCON[n] Vertical End/Start HByte
#   define SP_TCON_VEND_LO(n)       (0x0A + n * 8) // TCON[n] Vertical End LByte
#   define SP_TCON_HSTA_LO(n)       (0x0B + n * 8) // TCON[n] Horizontal Start LByte
#   define SP_TCON_HEND_HSTA_HI(n)  (0x0C + n * 8) // TCON[n] Horizontal End/Start HByte
#   define SP_TCON_HEND_LO(n)       (0x0D + n * 8) // TCON[n] Horizontal End LByte
#   define SP_TCON_CONTROL(n)       (0x0E + n * 8) // TCON[n] Control

#   define TCON_VSTA (PANEL_V_SYNC_WIDTH + PANEL_V_BACK_PORCH)
#   define TCON_VEND (PANEL_V_SYNC_WIDTH + PANEL_V_BACK_PORCH + PANEL_V_ACTIVE)
#   define TCON_HSTA (0x000)
#   define TCON_HEND (0xFFF)

    SetGPIOShare(PIN097, 0b100); // DVS on pin 97
    ScalerWritePortBit(S_TCON_PORT, SP_TCON_CONTROL0, 7, 0b1); // Enable timing controller function    

    // Vertical timings for TCON[0]
    ScalerWritePortByte(S_TCON_PORT, SP_TCON_VSTA_LO(0), TCON_VSTA); // Set signal start line number low
    ScalerWritePortByte(S_TCON_PORT, SP_TCON_VEND_VSTA_HI(0),
        ((TCON_VEND & 0xF00) >> 4) | // Set signal stop line number high
        (TCON_VSTA >> 8));   // Set signal start line number high
    ScalerWritePortByte(S_TCON_PORT, SP_TCON_VEND_LO(0), TCON_VEND); // Set signal stop line number low
    // Horizontal timings for TCON[0]
    ScalerWritePortByte(S_TCON_PORT, SP_TCON_HSTA_LO(0), TCON_HSTA); // Set signal start pixel number low
    ScalerWritePortByte(S_TCON_PORT, SP_TCON_HEND_HSTA_HI(0), 
        ((TCON_HEND & 0xF00) >> 4) | // Set signal stop pixel number high
        (TCON_HSTA >> 8));   // Set signal start pixel number high
    ScalerWritePortByte(S_TCON_PORT, SP_TCON_HEND_LO(0), TCON_HEND); // Set signal stop pixel number low
    // Control register for TCON[0]
    ScalerWritePortBit(S_TCON_PORT, SP_TCON_CONTROL(0), 7, 0b1); // Enable TCON
    ScalerWritePortBits(S_TCON_PORT, SP_TCON_CONTROL(0), 0, 3, 0b100); // Invert data bus when TCON[0] is 0

/////////////////////////////////////  

    // On screen display example
    OSDInit();
    char* entries[]= { "scaling", "other" };
    OSDCreateMenu("Settings", entries, 2);
    SetOverlayColor(0xaa, 0xaa, 0xaa);

[KerJoe]

As for my debugging setup I compile for PC using make native, afterwards I use VS Code (with gdb backend) to step through and send values to the scaler. The PC communicates with the scaler using the I2C interface used for programming and DDC+EDID. The communication code is in core/i2c_native_iface.c, it is Linux specific though.

[Coucouillu2009]

Hi @KerJoe. I am reading you during a job travel. I am impatient to go back home and be able to test your code this weekend.

For the debug, I understand that you work under linux, do you? If not, how do you use core/i2c_native_iface.c? Through Windows WSL?

Thanks a lot. Please share to me your paypal account, I woukd be pleased to offer you a beer/softdrink/whatever_you_drink.

[coucouillu]

Hi @KerJoe,
Your code helped a lot and get now a satisfying RGB signal. A big step done! Unfortunately, the screen does not accept yet the global signal (no image on the screen). The signal should miss something.
I guess that it is caused by the signal on CLK pin (GPIO52, PIN096 = GPIO52). The signal I catch does not seem to be a pixel clock, but a horizontal clock.
Have you any advise? thanks

What I get

What I should get

[KerJoe]

Sorry, I forgot about the clock output. The pin 96 should be assigned to the display clock signal just like the vsync pin.

SetGPIOShare(PIN096, 0b100); // DCK on pin 96
SetGPIOShare(PIN097, 0b100); // DVS on pin 97

I've also created a separate branch for this issue here.

[KerJoe]

As for debugging, the core/i2c_native_iface.c relies on i2cdev Linux kernel module, so it can't be used in WSL (because the WSL's kernel does not have full access to the hardware).
However there is an #if 0'ed code there, that can use interface classes written in python from RTDMultiProg. Windows, unlike Linux, does not have a unified i2c api, so separate code has to be written for each device. So far you can use mcp2221, ch341 or nvidia gpu to connect to the scaler.

[KerJoe]

The RTD2662 also supports switching to UART instead of the first i2c channel, which means you can't program through it or use it for EDID, after the switch. The code for it is in peripherals/uart.c, I can reenable it if you need it.

[coucouillu]

Sorry, I forgot about the clock output. The pin 96 should be assigned to the display clock signal just like the vsync pin.

SetGPIOShare(PIN096, 0b100); // DCK on pin 96
SetGPIOShare(PIN097, 0b100); // DVS on pin 97

I've also created a separate branch for this issue here.

Hi @KerJoe
I think it is nit just a declaration issue because declaring PIN96 still give the same result. I think it is more due to settings on the CLK pin.
Currently, it does not clock at pixel. It clocks currently at HSYNC. It should also cock during VSYNC+xPORCHS periods

Any new Idea?

[KerJoe]

No, what you are meassuring is just noise from the data pins. I've missed enabling the clock output in the register SP_VDISP_TIMING. Here is the fix.

[coucouillu]

Hi @KerJoe
First good result. I recover hope for my project. 😘

The code is looping with the while(1) just after OSDInit and SetOverlayColor in order to have a unic frame but the screen is flickering a lot. I will try to check the clock signal that seems very high voltage and never goes below 1.5Volts

[coucouillu]

Hi @KerJoe
Next step, I try to make the HDMI input working but no success ; the code seems to loop in the while(1); of the # ifdef __SDCC

My goal is to input any HDMI resolution (1080p, 720p, etc..) and let the scaler scale the good resolution according to the panel settings. Is it possible?

[KerJoe]

By the time the execution reaches this line, it should have already setup the HDMI input, measured it and set the appropriate scale up/down factors.
Are you sure you are setting up the correct TMDS and I2C channels, what scaler pins do the HDMI port video and I2C pins connect to? Is the scaler detected by the computer as a video output?

[KerJoe]

Can you send me the video of what the "screen flickering" looks like, and also a photo of the screen with HDMI connected.

[coucouillu]

Hi @KerJoe
I remind you that I am on PCB900099_V9 board while you created your own. Perhaps a pinout issue?
The board is recognized by the PC (windows sound). I kept te original EDID from your code and I can see several resolution defined under PC display parameters.

For the rest of the code, I also kept yours, I just adapted only few lines to fit my screen. Exemple: from FALSE to TRUE the values of PANEL_INVERT_DCLK, PANEL_INVERT_DHS, and PANEL_INVERT_DVS
I also modified from
ScalerWritePortBit(S_VDISP_PORT, SP_VDISP_TIMING, 0, 0b1); to
ScalerWritePortBit(S_VDISP_PORT, SP_VDISP_TIMING, 1, 0b1);

So here are my tests through 2 videos
With HDMI connected > Edit : during my first tests, I good picture appears (I recognized on the LCD the icons on desktop from the PC). but now the picture is vertical bars generated from the signal (you can recognize the color of the icon in vertical.

Without HDMI connected > the screen flickers (OSD included) BUT is stable when the HDMI cable is connected to PC

I still not well equiped for the debugging so I used the OSD_menu+delay in order to display the different step of the code.
The picture appears on screen after the line SetFIFOWindow(hact, vact);

[KerJoe]

Can you please attach the video in the comment and not the google drive.

[coucouillu]

EDIT : videos are too big. I shared to all in my GDrive

I will try to attach videos in the comment

In the meantime, I just shared the links "to all" in my GDrive

I try to display the values of hact and vact in the OSD for debugguing but without success to convert values to strings

    char* valuesToMenu[]= { "hact-vact", hact, vact };
        OSDCreateMenu("PostSetFIFOWin", valuesToMenu, 3); 

[KerJoe]

char hact_str[11], vact_str[11];
sprintf(hact_str, "%i", (int)hact);
sprintf(vact_str, "%i", (int)vact);
char* valuesToMenu[] = { "scaling", hact_str, vact_str };

[KerJoe]

1.webm

2.webm

[coucouillu]

char hact_str[11], vact_str[11];
sprintf(hact_str, "%i", (int)hact);
sprintf(vact_str, "%i", (int)vact);
char* valuesToMenu[] = { "scaling", hact_str, vact_str };

Well done

[KerJoe]

It's getting late here, I'll try things on my board tomorrow, meanwhile...
Can you post results from ScalerReadByte(S_STATUS0), ScalerReadByte(S_STATUS1) and values from other members of InputMeasData.
Does the image on the panel change when you move the cursor?
Try manually specifying InputMeasData.HFreq, hact and vact.
Comment out ScaleUp and ScaleDown and feed the native resolution to the scaler.

[coucouillu]

set breakpoints, run functions when the program is paused, read/write variables, read/write scaler registers, etc.

is it possible to modify/read/write scaler registers to the RTD while this one is running connected to the LCD_screen. Like if i want to tweak some parameters and notice immediatly in live the results on the LCD_screen?

[KerJoe]

Native on my WINDOWS_PC does not open any windows app. I am just getting the printf in the VSCode Terminal.

Well, yeah... It's a console app there is no GUI.
By native I mean it compiles for the PC's native architecture x86_64, unlike the sdcc which cross-compiles on PC for 8051 core in RTD2662

is it possible to modify/read/write scaler registers to the RTD while this one is running connected to the LCD_screen. Like if i want to tweak some parameters and notice immediatly in live the results on the LCD_screen?

Yes. As I said you can use the DEBUG CONSOLE of VSCode, to query variables, run functions, change RTD2662 registers, etc.

[coucouillu]

Try opening the C:\msys64\home\NUCi7\ORTD2662 in VSCode, opening the Run and Debug on the left pane, then starting the program with Debug Native Build task, when you pause you will be able to issue commands in the DEBUG CONSOLE, like: changing the capture window SetCaptureWindow(0, 0, hact, vact, 0, 0); or getting the measured parameters: inputMeasData.

I am trying to do what you said above and get that:

[coucouillu]

seems to be an issue between Windows and MSYS and/or MINGW installation about "Mldebuggerpath" . I am making some google searchs

[KerJoe]

Try running pacman -S gdb in MSYS

[coucouillu]

Ok. Now it seems to launchdebbug and immedatly sto on an "Arithmetic exception" (in red)

[KerJoe]

That happens when there is no signal.

[coucouillu]

OK. So now the signal ison LCD screen, the debugger seems running.
When I try csome commands, the system says Unable to perform this action because the process is running.

[KerJoe]

Well.. pause it.

[coucouillu]

If I pause It, I am ejected.
The program 'C:\msys64\home\NUCi7\ORTD2662/output_native/native.exe' has exited with code 0 (0x00000000)

[KerJoe]

Ok, then put the breakpoint on getchar(). That should pause it.

[coucouillu]

breakpoint on getchar() paused well.

inputMeasData or SetCaptureWindow(0, 0, hact, vact, 0, 0); in debug prompt gives : -var-create: unable to create variable object

[KerJoe]

Oops, sorry I renamed InputMeasData to inputMeasData in my new code, use InputMeasData. As for SetCaptureWindow(0, 0, hact, vact, 0, 0);, remove the semicolon -> SetCaptureWindow(0, 0, hact, vact, 0, 0)

[coucouillu]

OK so here is the result of both commands

InputMeasData
>{...}
SetCaptureWindow(0, 0, hact, vact, 0, 0)
>void

[coucouillu]

when I change values like

SetCaptureWindow(120, 0, hact, vact, 0, 0)
[New Thread 15136.0x2370]
[New Thread 15136.0x3150]
void

image udate immediatly on LCD_SCREEN
Now I will play a bit with that this week end.
Thank you

[KerJoe]

1. Press on {...} to expand the struct
2. void means that SetCaptureWindow has executed. Try changing the last two parameters of SetCaptureWindow, they are the ones thad usually need adjusting.

[coucouillu]

Great!!

InputMeasData
{...}
HFreq = 0x9247
VFreq = 0x3c
HTotal = 0x2d1
VTotal = 0x270
HSync = 0x2e
VSync = 0x26b
HActive  = 0x0
VActive = 0x0
HSPolarity = 0x1
VSPolarity = 0x0

and changing the last two parameters of SetCaptureWindow is making the image better.

Perfect for the moment

[coucouillu]

SetCaptureWindow(0, 0, hact, vact, 0, 0) is too hard to be determined manually :(.
The combinatory of 2 first + 2 last parameters are like 1920x1920x1920x1920 possibilities.
What the others firmware are doing? could it not be determined with analyser of the RTD functions?

[KerJoe]

The other firmware also changes the S_IVS2DVS_DELAY_LINES register, but it behaves similarly to (and is added to) the vertical delay (last parameter of SetCaptureWindow). You can also try changing SetDPLLFrequncy, around your display frequency. Can you post a video of you modifying the VDelay and HDelay?

[coucouillu]

The other firmware also changes the S_IVS2DVS_DELAY_LINES register, but it behaves similarly to (and is added to) the vertical delay (last parameter of SetCaptureWindow). You can also try changing SetDPLLFrequncy, around your display frequency. Can you post a video of you modifying the VDelay and HDelay?

SetCaptureWindow
T o make a video, I have to change my bench setup to correctly record the WINDOWS_Screen and the results on LCD_Screen, side by side. I will do later. Playing with SetCaptureWindow through VDelay and HDelay is not satifying. Just notice that no really effect until several hundreds (320/520 respectively)

best value currently is SetCaptureWindow(0,60, hact, vact, 0, 0); but I get a white bar of ~30 pixels at the top. horizonal seems100% OK. I got issue on vertical.
But everything is also influenced by the values in panel_config. A real nightmare.

SetDPLLFrequncy VS SetAPLLFrequncy(uint32_t pixelClock, uint16_t linePixelCount)
About SetDPLLFrequncy I will try now.
But what about the other function SetAPLLFrequncy I can find commented at the end of main.c? Does is compatible with HDMI input?

[coucouillu]

I finally found the parameters fitting the LCD_screen (one standard to understand what i am doing) playing with panel_config.h values + EDID in standard 1920x1080x60.
Now I switch to the Exoctic_LCD_screen to do the same.

[KerJoe]

SetAPLLFrequncy is used for VGA/YPbPr, not HDMI/DVI.

[KerJoe]

You can also try changing ScalerWriteByte(S_IVS2DVS_DELAY_LINES, 0x---).
Changing hStart and vStart in SetCaptureWindow results in the picture shifting left and the 'dead space' at the top, but I'm not sure what causes the extra space on the bottom, respectively. Does hact, vact match the active resolution of the output in the Windows settings?

Now I switch to the Exoctic_LCD_screen to do the same.

What do you mean by that?

[coucouillu]

Now I switch to the Exoctic_LCD_screen to do the same.

What do you mean by that?

At the beginning of our echange is for a project on an exotic, proprietary signal LSCD_SCREEN.
But It was too hard to reverse enginner and learning your code at the same time.
So right now I took a 7" LCD_screen with same resolution and with standard values. I mean that this "standars" LCD_screen work with plenty of available firmware. But the exotic ones does not. here is the goal to program a new firmware. Now I have learnt on the standard, I switch back to the exotic one.

[coucouillu]

Changing hStart and vStart in SetCaptureWindow results in the picture shifting left and the 'dead space' at the top, but I'm not sure what causes the extra space on the bottom, respectively.

It seems not to really work exactly like that. sometimes the behaviour is like you say, sometimes not, depending of the values.

Does hact, vact match the active resolution of the output in the Windows settings?

Yes for hact, vact and VSync (in green) but not for HSync (in red). Very strange!

I changed the launch.json in order to prevuew value directly in decimal instead of hexa with 'text": "-gdb-set output-radix 10' but it displays well low values but not high values (in yellow).
Any tips?
It is possible to display "HEX | DEC" at the same time?

You can also try changing ScalerWriteByte(S_IVS2DVS_DELAY_LINES, 0x---).

It the next test I will do

[KerJoe]

It is possible to display "HEX | DEC" at the same time?

AFAIK - no, but you can change it with -exec set output-radix 16 in debug console.

The reason why horizontal values are different is because they are measured in master clock (27 MHz) ticks, meanwhile vertical ones are measured in lines.

[coucouillu]

Hi @KerJoe . How are you?
I am still working on the firmware. To be be honnest I am comparing with 2 other sources code (I know you do want me to talk of other firmwares here :) )

My next step it to check the HDCP compatibility.
For that test, I am using an old Google Chromecast.

The Chromecast is 3 steps:

1. loader with "Chromecast" written
2. boot with a big colored "G" Google letter
3. then the chromecast wallpaper.

I checked all setting in your code like '_HDCP_SUPPORT' and '_TMDS_SUPPORT' to '_ON' but I only get the number 1 in sequence, then the rest is black screen.
With other firmwares every thing is OK.

My conclusions are that the HDCP protocol not managed in you firmware. Do you confirm?

[KerJoe]

Hi, Sorry for not writing for a while.

I know you do want me to talk of other firmwares here

Just so you know, it's not the legal issues I am concerned about (the folder alien literally contains the leaked firmware adapted to compile with sdcc), but the fact that trying to adapt the leaked firmware, does nothing to improve my own.

My conclusions are that the HDCP protocol not managed in you firmware. Do you confirm?

No, there's no code dedicated to supporting HDCP in my firmware. And honestly I don't think there's any good in even trying to implement it, as the scaler only supports two ancient versions of HDCP: 1.1 and 1.0. This google help page mentions requiring at least HDCP 1.3 for chromecast to function: https://support.google.com/chromecast/answer/7022492.

BTW, this IC's datasheet has HDCP registers matching the RTD2662 (while it does have the words 'HDCP' and '1.3' together on page 148, it's probably a mistake and they meant 'HDCP for HDMI 1.3').
https://github.com/KerJoe/ORTD2662/blob/master/docs/misc/RTD2525-SimilarScaler.pdf

[coucouillu]

Hi @KerJoe
I did not write to you for a while. I hope you're fine.

I worked a lot on another firmwares and now I am going back to your :).

Just so you know, it's not the legal issues I am concerned about (the folder alien literally contains the leaked firmware adapted to compile with sdcc), but the fact that trying to adapt the leaked firmware, does nothing to improve my own.

I can't include properlly "alien" code in your code without compilation issues. example : for the interrupts wth int_.c file I activated the #if 1 but compilation issues :

 ./alien/int_.c:21:26: error: expected declaration specifiers before ‘interrupt’
   21 | void IntProcTimer0(void) interrupt 1

Any advice?

No, there's no code dedicated to supporting HDCP in my firmware. And honestly I don't think there's any good in even trying to implement it, as the scaler only supports two ancient versions of HDCP: 1.1 and 1.0. This google help page mentions requiring at least HDCP 1.3 for chromecast to function: https://support.google.com/chromecast/answer/7022492.

BTW, this IC's datasheet has HDCP registers matching the RTD2662 (while it does have the words 'HDCP' and '1.3' together on page 148, it's probably a mistake and they meant 'HDCP for HDMI 1.3'). https://github.com/KerJoe/ORTD2662/blob/master/docs/misc/RTD2525-SimilarScaler.pdf

With other firmwares I successfully displayed my Chromast on my LCD_SCEEN (but picture not well fitting the screen), meaning that HDCP seems to work on my RTD2660 chip board. So related to my previous question (and the need to implement part of other firmwares in your), I think we could improve you code with HDCP support. What do yo think about?