Mity CPU Platforms » MitySOM-5CSX Altera Cyclone V

Hello Steve,

There was a bit of stability issue with the I2C interface to the HDMI transmitter IC. I thought my newest build of the demo had the stability issue ironed out though, let me take try it here again and I'll post back with my findings.

Dan

Hello Steve,

I've created an alpha SD card image that from my testing has fixed the i2c failures. The filesystem also now has X11 and launches XFCE on boot (if you have a USB OTG cable a mouse/keyboard can be used)

The image should be attached to this post and should just need to be written to an SD card.

I'm hoping to get the project updated on the wiki in the beginning of next week.

If you wouldn't mind, can you let me know if you tried the new image and if it worked better for you?

Thanks!

Dan

Hi Dan

Thanks for this. I can try the image on Monday and report back results.

Can you provide a little detail on the fix? Alternately if it is in Git (or will be there shortly), I can just look at the commit.

Best,

Steve

Hi Dan,

This image doesn't show anything on my monitor. Upon first booting it, right after the console printed "Setting Up HDMI Transmitter", the monitor came out of standby but the screen stayed black. After powering the system off, the monitor never went to standby. I then booted again and still saw a black screen.

Attached are the two logs of the console for each boot. Also some other log files that I thought could help. Let me know if there are others that would be useful.

Thanks,

Steve

Hi Steve,

Sorry for the delay, I was travelling Friday afternoon.

To fix for the I2C issue was that I resampled and debounced the I2C signals coming into the FPGA before feeding them to the HPS I2C master. I expected the HPS to take care of the debouncing but that feature might only be enabled if I'm not routing the signals through the fabric. I also cleaned up the timing constraints to make sure all the paths were constrained.

I've tested this on both a high res monitor and 720p TV. The HDMI transmitter is current hard set to output 1280x720, so when I used the 720p TV the output looked perfect. But when I tried using my normal high res monitor at my desk, I did see X and XFCE but the monitor didn't scale the image as I expected. This most likely is due to me forcing the HDMI transmitter into 720p resolution with the hdmi program. If you have a TV you can easily try, I would recommend giving that a try. I'll look into the HDMI transmitter setup to see if there is something off there.

Dan

Hi Dan,

Thanks for the detail on the I2C fix.

I've tested on two monitors. On one of them, I am certain it supports 1280x720 because I can set it to that resolution when driving it with my PC. Additionally, this monitor is the one that did display the splash screen sometimes with the previous HDMI SD image. I will try and scrounge up a HDTV just as another data point, but I suspect something else is causing the issue.

Let me know if there's any log files that may help or if you want me to scope some lines.

Best,

Steve

Hi Steve,

Hmm good point that it you've already vetted the monitor you're using. Seeing as you're getting the display to come out of standby and you're boot log didn't have any I2C errors, I'm going to assume the configuration of the transmitter is working as expected. Which makes me think this is more of a timing issue between the clock and data pins, we must be close to margin seeing is it works on my board but not yours.

Would you mind scoping the clock and data or hsync/vsync line on the AD9889B? They should be edge aligned and the clock should be 74.25Mhz. The data sheet is here: http://www.analog.com/media/en/technical-documentation/data-sheets/AD9889B.pdf

I could also just invert the output clock, which should increase the margin.

Dan

Hi Dan,

Sure thing, I can take these shots first thing in the morning and get them back to you.

Steve

Hi Dan,

See attached. The index.txt file in the zip package describes each scope shot. Let me know what other measurements I can take.

I've read there is a Quartus reference design for the Microtronix card. Have you compared your own timing constraints with those from that design? I can't seem to find my CD that came with the card to look it over myself.

Thanks and Best,

Steve

Hi Dan,

Any update on this? Have you been able to review the scope shots?

Best,

Steve

Steve,

I'm terribly sorry for the radio silence. Unfortunately I've been travelling for the past week so I haven't been able put as much time towards this as I'd like. Thank you for providing the scope captures, the data looks to be pretty delayed from the clock edge. I took your suggestion and have merged in the hdmi cards example project's timing constraints into the project. I'll be back in the office tomorrow and will be able to make sure it still works on my dev kit and will try a few more monitors.

Sorry again for the delay

Dan

That's ok, thanks for the update Dan. Feel free to post an updated image anytime, even if you don't have a ton of testing. I don't mind being a guinea pig if it gets us to a working example a little bit sooner.

Hi Steve,

Attached is a new image. The only thing I changed was that I updated the output delays for the data/control lines to match what the microtronix's example project used. It did work in my dev kit.

Let me know how it goes

Dan

No luck, same result, just a black screen.

One thing of note, based on the original qsys file from the wiki page, it seems the back porch values are not the same as those used in the AD9889B programming guide for 720p-60. See attached screenshots. It may be that the display's I'm using are more sensitive to the shorter back porch than yours. I will also try with a few more display's, specifically an HDTV.

Best,

Steve

Good catch, I'm doing a build now with the those back porch values. I'll let you know when it's finished.

Awesome, thanks.

I tried a large screen Samsung HDTV and your latest build works.

I'm hoping that the HDTV's are a bit more forgiving with the back porch value than the monitors, and this latest build works on both.

Awesome, I'll glad it did work on the TV!

I was able to recreate what I think you're seeing on your monitor. If I set my monitor's image size to auto instead of wide then it only showed up as a black screen. When I set it to wide I was able to get an image, though the resolution didn't look right. I was using the updated FPGA image with the correct porching timing.

Dan

Can you post that image for me to try?

Sorry about that, it's attached now

Hi Dan,

So I'm still not getting any output on my monitors. However, I tried adjusting the monitor settings and I get a message saying out of range signal. I don't understand how I saw the yocto splash screen on this monitor at some point. I also don't fully understand why Windows can drive this display at 720p. Perhaps it's doing something "smart".

I think what would be most beneficial at this point would be if you could post an updated Quartus project, source files, etc that I can modify for different resolutions. I'll want to pickup the I2C stability changes that you solved. We'll eventually define a fixed resolution for our product and will expect a compatible display to be provided. Along with the updated sources, if you could point out where changes need to be made to change the resolution, that would be helpful. My understanding is it's in the Qsys project clocked video output peripheral and device tree. Anywhere else?

Thanks,

Steve

Hi Steve,

I'll cleanup and push the project today. I'll also go through and write down what needs to be updated in order to change resolution, I think it will be qsys, device tree, and maybe the initialization code for the HDMI chip but I'll double check.

Dan

Hi Daniel,

I saw the project got pushed, thanks.

When do you think you can put together those instructions for updating the resolution?

Thanks a lot,

Steve

Hi Steve,

I'm testing this now. Hopefully it's just the mods to the device tree/qsys project. I'll update once my build is finished and (fingers crossed) I'm able to get video.

Dan

Alright my testing today wasn't as successful as I'd liked. I tried both 1920x1080 and 720x576. Doing 1920x1080 caused the kernel to crash when it tried to allocate the RAM for the frame buffer to use. 720x576 appeared to boot fine but my monitor said it couldn't support the output. I was using those resolutions because the hsync and vsync settings were documented by analog devices. Here is what I changed for the resolutions:

            hdmi_0: hdmi0x0100 {
                compatible = "altr,vip-frame-reader-1.0";
                reg = <0x0100 0x80>;
                max-width = <0x500>;
                max-height = <0x2d0>;
                bits-per-color = <0x8>;
                mem-word-width = <0x80>;
            };

• Update Image width/Image height
• Separate Sync Only - Frame/Field 1 HSync/VSync settings
• Pixel Fifo Size set to the width
• Fifo level at which to start output set to the width - 1

• Update Maximum image width/height