DM355 800x600 SVGA flicker issue

Hey Garry,

                   This has been highlighted before as a DDR2 bandwidth issue on both the DM6446/DM355 - your best bet is to jack the PLL settings to their maximum ranges. Althought the 800x600x55 in theory has a slightly less bitrate than the 720P-30, they're both on the fringe in terms of bandwidth usage. Perhaps the refresh rate incurs a bigger hit on the memory than a 30fps 1280x720 redraw. You can try increasing the priority of the VPBE bus master as well to see if it helps you (they're a few of these config. registers in the ARM Subsystem datasheet).

As a side note, were you able to get the default 720P-60 mode to work? I've got the THS8200 EVM + DM6446/DM355 EVMs as well, and although i can get images to display on my monitor, the colors are all quite out of wack; I've tried displaying my own color bar pattern in YUV 4:2:2 16-bit samps mode, as well as invoking the VPBE hardware's color bar generator, and both have really wierd colorings. Did you notice this on the out-of-the box 1.20 LSP kernel? This is my bootargs:

sete bootargs video=davincifb:vid1=off:vid0=1280x720x16,4000K:osd0=1280x720,2025K:osd1=1280x720,2025K davinci_enc_mngr.ch0_output=COMPONENT1 davinci_enc_mngr.ch0_mode=720P-60 console=ttyS0,115200n8 noinitrd ip=dhcp root=/dev/nfs nfsroot=$(nfshost):$(rootpath),nolock mem=120M

Any help would be appreciated,

Jerry

Hi Jerry

I am afraid my work has all been with my custom DM355+THS8200 board using RGB +Syncs (svga monitor drive) o/p from the THS8200 rather than YC and as such I have never tried the 'out of the box' 720P support using the EV<+THS8200 daughter board.

What I can say from my testing I have detailed below, quite long but may be useful to somebody:

- if your colours are 'odd' then try flipping the YUYV sequence using YCCTL register or even swap the YC output pins using VIDENC_VIDCTL - for my tests I modified these registers at the end of  davinci_enc_set_720p()  in \lsp\ti-davinci\drivers\media\video\davinci\davinci_platform.c or  you could use an interactive access from the linux terminal as but I am not familiar with this method (something like the fix for DDR2 known issue:    echo 0x20000020 0x10 > /sys/class/davinci_system/system/reg)

- I found its always worth putting a prink in the driver functions you expect to be called as part of the video device/mode setup.

- The performance from the viewpoint of perceived display flickering with DM355 activity seems to be related to ubl version. I assume the ubl configures core ARM/Peripheral registers that remain unchanged by uboot or the linux kernel. Anybody confirm this or enlighten me ?

- The ubl, that comes with release 1.1 of the serial flashing toolbox ,together with the fix, 'echo 0x20000020 0x6 > /sys/class/davinci_system/system/reg' does NOT eliminate the flickering of static displays in the video/osd window - even at 640x480x59Hz and is significantly worse when decoding video or moving data from the VPFE to the VPBE.

- The ubl, that comes with release 1.5 of the serial flashing toolbox ,together with the fix, 'echo 0x20000020 0x6 > /sys/class/davinci_system/system/reg' seems to eliminate flickering of static displays in the video/osd window at 640x480 at 59 Hz when terminal or ethernet activity is present - even with a 640x480 video decode or 640x480 image capture and display.

- The ubl, that comes with release 1.5 of the serial flashing toolbox ,together with the fix, 'echo 0x20000020 0x6 > /sys/class/davinci_system/system/reg' seems to eliminate flickering of static displays in the video/osd window at 800x600 at 59 Hz when terminal or ethernet activity is present - however with a video decode or image capture and display - artefacts become visible again.

Hope this is of some help, I am still trying to achieve 800x600 at 59 Hz with no flickering during video decode and image capture so any advice welcomed...

Cheers

Garry Jackson

J43 Design Limited

Garry Jackson said:

- The performance from the viewpoint of perceived display flickering with DM355 activity seems to be related to ubl version. I assume the ubl configures core ARM/Peripheral registers that remain unchanged by uboot or the linux kernel. Anybody confirm this or enlighten me ?

There is an App Note on the works which explains some of the limitations in the device that may lead to flickering; you are correct that this is related to the memory bandwidth, although I do not believe this is UBL related.  Hvae you tried playing with the PBBPR register setting (0x30 is recommended for 720p). 

Also, I wanted to send a quick thank you; we really appreciate you sharing your lessons learned with the community.

Hi Juan

Thanks for the quick follow up - the echo 0x20000020 0x10 > /sys/class/davinci_system/system/reg command line actually changes the PBBPR register. Only when this is changed from defualt down below 0x10 does the flickering stop at 640x480 (including for decode/vpfe loading). However for 800x600 at 59Hz massaging this register improves the situation but does not eliminate the flicker under DM355 loading.

As for the ubl with the SERIAL tools, 1.1 I think sets up the DDR2 clock to a lower speed than that in ubl that comes with 1.5 and switching between the 2 versions its possible to have flicker that can not be eliminated at 640x480 (at least by me) by changing PBBPR.

My FAE advises that TI are working on a 270MHz/216MHz version of the ubl for the serial tools which may just give that extra bandwidth to eliminate the problems I observe. If there is another suggestion or experience I would really welcome the advice or help.

Best regards

Garry J

You are correct that the DDR2 speed configuration happens at the UBL and U-boot level and that if you wanted to speed up your part, you will need to upgrade your UBL and possibly your u-boot.  However, this is a totally solution than what I had in mind since it involves using 270 Mhz silicon; please note that before bumping up your speed, you need to ensure you have the 270 MHZ DM355 silicon; simply bumping up your speed while using the 216 MHz silicon may not yield dependable results over time.

FYI, the source code for both UBL and U-boot are readily available; therefore, if you have some 270 MHz silicon available you can theoretically make the changes yourself (no need to wait for FAE).

Hi Juan

I have 270MHz silicon on my board (thankfully) and hope the 270MHz ubl fix will work. I must have a version of ubl that works with the serial loader tools for realistic production - it seems these utilities only work with the ubl thats part of the serial loader project release. For some reason I can not compile the ubl that comes with release 1.5 (I have CCS3.3)

I think this is a brute force apporach but do not have any more stones to look under - I need to get a stable 800x600 at 59 Hz main display that I can decode  mpeg4's (or display vpfe live data) into a 640x480 video

Any further advice welcomed.

Best regards

Garry J

The 270 MHz silicon should definitely give you some extra bandwidth.  Also, I would recommend disabling any VPBE window that is not in use (for example the attribute window, OSD windows...); these all take precious bandwidth....

Hi Juan

Is setting 'vid1=off' in the bootargs for the venc OK ?

Thanks for the advice. Clawing back bandwidth seems to be the key.

Cheers

Garry J

that should work via bootargs. 

Hi Garry,

Even I faced the flicker issue with ubl 1.0/1.2 and same was resolved with ubl 1.5.

As per "http://wiki.davincidsp.com/index.php/TMS320DM355_High-Definition_(HD)_Display" link I have configured PBBPR and TC RDRATE also. ARM speed is 270 MHz and DDR 216 Mhz. Along with that I have disabled video channel 1 and OSD channel 1. Video channel 0 and OSD 0 are configured for 1024x768 resolution. Inspite of managing all this video flickers were prominent with UBL 1.2 (One available in dvsdk 1.30.00.40).

I have downloaded all available versions of UBL from "http://sourceforge.net/projects/dvflashutils/files" link and tested with them.

To my surprise there were no flickers with UBL 1.5 version, but source code of that UBL is not available in "DM35x_FlashAndBootUtils_1_50.tar.gz" package downloaded from sourceforge. Can you please tell me from where can I download the source code?

Thanks in advance.

Regards,

Deepika

Addition to that: UBL code(1.2 :( )  availabe in dvsdk package can be build with CCS i guess, I am unable to build it on Linux machine.

I just downloaded DM35x_FlashAndBootUtils_1_50.tar.gz from http://sourceforge.net/projects/dvflashutils/files and can see source code under ../common/ubl/src; I am not real familiar with this project, but could this be what you are looking for?

Even I have downloaded the same but according to me, there should be source files in DM35x/GNU/ubl/src also, which were missing in 1.5 version and were present in 1.0 version. I want to build UBL source in linux, for that I will need GNU files (correct me if I am wrong).

I hope directory structure is not changed in new UBL?

UBL source code is not available on TI repository/site? Other than the one available in dvsdk??

Thanks, I got the source and also found the problem in UBL 1.1

SDRCR register which is used to set the DDR refresh rate was set incorrect.

UBL 1.1  :  DDR->SDRCR &= (0xFFFF0000 | DDR_RR);                /* DDR refresh rate is incorrect over here */

UBL 1.5:  DDR->SDRCR = (0x0000FFFF & DDR_RR);

where DDR_RR = 1336

Thank you for sharing this.

Deepika said:

Thanks, I got the source and also found the problem in UBL 1.1

SDRCR register which is used to set the DDR refresh rate was set incorrect.

UBL 1.1  :  DDR->SDRCR &= (0xFFFF0000 | DDR_RR);                /* DDR refresh rate is incorrect over here */

UBL 1.5:  DDR->SDRCR = (0x0000FFFF & DDR_RR);

where DDR_RR = 1336

The above register seems to set the refresh rate of your DDR; I am wondering what type of DDR you have on your custom board?  Also, I wanted to make sure future readers of this post know that depending on the type of DDR they are using, they may want a different value here.

Juan, all this observations were not for the custom board, these were done on DM355 EVM.

DDR2 refresh rate for DDR on DM355 EVM should be 1336, however it was set incorrect in UBL 1.0/1.1 available on sourceforge.net and was set correct in UBL 1.5, and that was the cause of  much more flickers with older UBL version on EVM. I meant incorrect refresh rate was worsening the flicker problem.

got it.  thanks for the heads up; I will be sure to keep it in mind should other customers inquire about this.