Shop OBEX P1 Docs P2 Docs Learn Events
All PASM2 gurus - help optimizing a text driver over DVI? - Page 19 — Parallax Forums

All PASM2 gurus - help optimizing a text driver over DVI?

1161719212229

Comments

  • RS_Jim wrote: »
    Potatohead

    “This PVM has a "Blue Only" mode, I've not used much. Holy moly! I know what it's for now. Shows phase error like a sore thumb. I'll have to get a photo.”

    Back in the day when I used to work around TV studios, we would use a standard set of color bars and Blue Only mode to quickly set up a color monitor. With blue only mode you can quickly set hue and saturation by balancing the bars.

    Maybe this can be an aid to you fellows designing display software.

    Jim

    Yes, that was shown to me by the person who gave me the PVM. That's fast and clever.

    It has the side effect of highlighting our chroma phase challenges. Stands right out. My plan for it was to use it to help with what I will call the 15Khz project. It has TTL, RGB, S-video, composite. I'll get a component converter for it. And will set the yoke right this weekend. That tilt annoys me, but it's also why I got the thing. Easy peasy.

  • roglohrogloh Posts: 5,122
    edited 2019-11-30 01:59
    @potatohead (or anyone who has used this driver so far), on your revB board, which I presume is a normal P2-EVAL board with a production packaged P2 (non-glob top), when you run the complexdemo on your monitor do you see the text regions along the entire width of the screen or just on the right side with some flashing/scrolling coloured vertical stripes/bars filling the left/middle of screen in the text region? I'm tracking down an issue I see between my glob-top and production packaged revB boards that behave quite differently with the exact same code. During development of this driver on the glob-top board, I didn't ever encounter this issue and can't make it happen there, but started noticing it a few days back when I ran on the production packaged board mostly everyone else uses.

    Right now I see different behaviour on the screen in text regions. It may just be streamer timing initialisation or hub RAM related, still trying to get to the bottom of it in case I am using uninitialized hub data somewhere (don't think I am). I only have a sample size of 2 boards here so it may not be glob/non-glob difference, but just different startup+PLL timing or random hub data between different P2's (I hope). Occasionally the non-glob top P2 board works as expected, but the majority (>90%) of times I download it causes this issue - which is helpful to be able to reproduce it for debug. It's weird.

    First I thought this was overclock related as ozpropdev mentioned his glob-top chip overclocks a bit more than the standard packaged one, but I see it also on normal SDTV output running the P2 at 100MHz or so, so it doesn't appear to be related to the clock speed.

    When I account for the 16 pixel side border size it look like the bad version is reading rendered text from memory 64 longs later than it should which could well indicate a fifo setup issue somewhere, but it is strange it works reliably on the original glob top based P2-EVAL board.

    Good case (VGA output):
    IMG_2573.jpg

    Bad case (VGA output):
    IMG_2572.jpg
    640 x 480 - 116K
    640 x 480 - 120K
  • roglohrogloh Posts: 5,122
    edited 2019-11-30 03:39
    Aha, just noticed something. On my RevB normal P2 package board that was failing the complex demo before, I also had the HDMI breakout board plugged into P32-P39 pins but it is not fitted there on the glob top board right now, and whenever it was fitted on that board for earlier testing it was on P24-P31. The A/V breakout for VGA was always on P8-P15 on both boards. That was another difference between setups.

    Now when I yank this HDMI breakout out on the new non-glob top board, the VGA output screen works okay. When I add it back, the 64 character offset appears in text regions next time I download the image (it appears to be consistent behaviour). This is really strange as I am not even driving these DVI pins from code in this case (or don't think I am), so maybe the extra current load or noise the cable introduces somehow couples in and affects the fifo read position at startup. If I just disconnect the DVI cable from the monitor end, it also works. WTH? How can this have an effect? Some additional small delay at startup? Voltage differences between Port A and Port B?

    Update: with the DVI cable plugged into the Dell monitor (with VGA as well), there appears to be less noise than without. That wide DVI earth connector might be helping. I measured about 60mV p-p noise on the V0815 IO pins of the VGA and 90mV without it the DVI plugged in.

    Update2: if I move the HDMI breakout on the new board to pins 24-31 where I used to have it on the original board, the VGA output works fine too, so this has nothing to do with glob-top vs production package. (I think I had moved it up to pins 32-39 recently to be able to quickly run Chip's oscilloscope demo). I'll try it on other port B pins to see if it is a portA/portB loading thing.

  • evanhevanh Posts: 15,126
    So everything before the "Update" is without any cable attached to the HDMI accessory board, right?
  • roglohrogloh Posts: 5,122
    edited 2019-11-30 04:26
    Yes. Here is some more information I have found.

    1) Both glob-top and non-glob top boards behave the same.

    2) I get the VGA text problem only when the HDMI accessory board is plugged into pins 32-39 AND connected to my Dell monitor at the other end of the cable.

    3) I have moved the HDMI accessory board to other positions i.e. pins 0-7, 16-23, 24-31, 40-47, 48-55 and this problem did NOT appear. I couldn't fit it 8-15 because the VGA board was operating from there and I didn't want to put it into 56-63.

    So something is special about the load on low byte of port B and startup timing. I have to check my code for anything it might be doing like polling these pins at startup etc which could introduce a delay, but I don't think it should be (no need to).

    I hope it is not a fastspin thing, perhaps something is buried in there. I can only easily check my own code.

    Update:
    4) The problem also appears on the DVI screen video output (if I modify the code to send over that instead of VGA) when the HDMI breakout board is plugged into port pins 32-39, regardless of the presence of A/V breakout board connection. Something in my code seems timing sensitive to having a load on pins 32-39.

    Chip has used these HDMI output pins okay in his oscilloscope demo though of course that's going to be rather different code.

    Update:
    5) if the A/V accessory board is plugged into pin 32-39 with nothing else fitted, I get the problem again on VGA, but it has stripes over all the text regions. There is no normal text shown.

    What on earth is special about these pins?
  • evanhevanh Posts: 15,126
    edited 2019-11-30 05:28
    It is sounding like a software bug. Maybe a missing # or uninitialised variable.

    EDIT: Whoa, that's a lot of conditional execution! Just looked for the first time. :) The zip file I've got is from the 21st November. Is there an up to date one?
  • evanhevanh Posts: 15,126
    Well, you've had fun building the pixel doubler. I like the combined skip pattern and rep count encoding.
  • I didn't see that problem. Only ran one input at a time, only that board connected. I saw the good case. Non-glob top.

  • roglohrogloh Posts: 5,122
    edited 2019-11-30 06:24
    evanh wrote: »
    It is sounding like a software bug. Maybe a missing # or uninitialised variable.

    EDIT: Whoa, that's a lot of conditional execution! Just looked for the first time. :) The zip file I've got is from the 21st November. Is there an up to date one?

    I've been testing/adding a couple of things for the next (beta?) release related to NTSC but that zipfile you looked at is still valid for now and causes the problem if you put the board on P32-P39.

    I'd agree with an uninitialised variable being a symptom. I will try to print out the key state variables to the screen down the remaining right side on region change to text mode to compare good with bad. Might show up something. I realized that if you subtract $100 from the line buffer it might mean the text scanline could operate that way. Perhaps there is a long that has bit8 state still setup from prior execution and it is a 1 or a 0 depending on the presence of the load on port B and this causes the extra $100 hex to be added in...?

    evanh wrote: »
    Well, you've had fun building the pixel doubler. I like the combined skip pattern and rep count encoding.

    Yes that was partly thanks to some ideas from forum members. A few people contributed to that one, it's pretty well optimised now.
    potatohead wrote: »
    I didn't see that problem. Only ran one input at a time, only that board connected. I saw the good case. Non-glob top.


    Thanks for checking potatohead. I think you'd need to put the A/V board on pins 32-39 to make it happen if you only have one board. If you used other pins, it doesn't happen.


    I am also going to try pulling up pins 32-39 one at a time to see if they cause a problem. The terminated HDMI board would likely see a logic high when plugged into a monitor. I guess P2 pins float low.

  • Roger
    I'm seeing the fault on both globtop and production boards with board on pin group 32.

  • evanhevanh Posts: 15,126
    rogloh wrote: »
    I've been testing/adding a couple of things for the next (beta?) release related to NTSC but that zipfile you looked at is still valid for now and causes the problem if you put the board on P32-P39.
    Ah, right, yep, getting the problem now I've tried. It happens with the simple text demo too.

  • roglohrogloh Posts: 5,122
    edited 2019-11-30 06:53
    ozpropdev wrote: »
    Roger
    I'm seeing the fault on both globtop and production boards with board on pin group 32.

    Yes. That's in agreement.

    The save & ptrb stuff in my code related to the linebuf1 pointer and its hub writes and fifo reads needs careful checking as it was recently optimized to save a long, but I think it should be good. I still cannot yet fathom how any inb pin states would affect it, but they must somehow. I will try to print these values in good and bad cases. The line buffer is shared with graphics regions and they still work okay so that variable should be fine.

    Kind of lucky I stumbled onto this. You need to use a specific port group to even encounter it.
  • ozpropdevozpropdev Posts: 2,791
    edited 2019-11-30 07:00
    I'm also getting the fault on pin group 40 on the production eval board.

    Edit: Globtop has fault on pin group 40 too.
  • evanhevanh Posts: 15,126
    edited 2019-11-30 07:09
    Yep, same here, pin group 40 also bad. Content is slightly different though.
  • roglohrogloh Posts: 5,122
    edited 2019-11-30 07:11
    Hmm. That is different to me.

    I think I just fried my glob top board VIO supply with my latest test. :frown: I wanted to pull each pin high on each pin from 32-39 so I got two female jumper breakout board cables and put a 680 ohm resistor in the middle then jumpered VIO to each pin. At one point from the jumper cable spring the partially exposed resistor leg metal scraped over the nearby earthing pin post and looks like it shorted VIO very briefly. Now after power off and repower I measure the board supply VIO voltage and it is only 0.28V or so. Looks dead and nothing downloads to the board! Damn. It was not the 5V as that is off. It was the ground post.

    Repeated this test (extremely carefully) on my remaining production board and wasn't able to reproduce the problem by pulling only one pin from 32-39 high at a time, so it must need a different combination. I am not going to go further there. Too risky.

  • roglohrogloh Posts: 5,122
    edited 2019-11-30 07:18
    Actually if I plug the VGA board in 40-47 I do see the bad problem, no text at all, all stripes.

    It doesn't happen if I plug in the HDMI board into 40-47 with VGA in 8-15. That's what I tested before.

    Update: A/V board on P48-55 is okay. This is really weird.
  • evanhevanh Posts: 15,126
    edited 2019-11-30 07:25
    rogloh wrote: »
    I think I just fried my glob top board VIO supply with my latest test. :frown: I wanted to pull each pin high on each pin from 32-39 so I got two female jumper breakout board cables and put a 680 ohm resistor in the middle then jumpered VIO to each pin. At one point from the jumper cable spring the partially exposed resistor leg metal scraped over the nearby earthing pin post and looks like it shorted VIO very briefly. Now after power off and repower I measure the board supply VIO voltage and it is only 0.28V or so. Looks dead and nothing downloads to the board! Damn. It was not the 5V as that is off. It was the ground post.
    Is that a revB board? If so then the most likely failure is the LDO regulator. The prop2 is probably fine.

  • cgraceycgracey Posts: 14,133
    Rogloh, I wonder what happenef. It sounds like the local LDO is trying to deliver 3.3V, but it's getting pulled down exceedingly hard by maybe an internal short in the P2.

    This other stuff sounds like a software bug.
  • Yes it is a revB EVAL board - so the VIO supply looks very vulnerable. It was just for the briefest of moments touching ground so BE CAREFUL with your boards. I need to look at the schematic to see if I can work out what is dead.
  • cgracey wrote: »
    Rogloh, I wonder what happenef. It sounds like the local LDO is trying to deliver 3.3V, but it's getting pulled down exceedingly hard by maybe an internal short in the P2.

    This other stuff sounds like a software bug.

    I will tell you what happened. A jumper wire from V3239 touched the large grounding post next to it for maybe 0.3seconds as a cable flicked past it and the screen went off. At that point I don't believe I had even touched any P2 pins with the other end, and if I did they were via the 680 ohm resistor.
  • evanhevanh Posts: 15,126
    You'll have to remove the LDO to separate it from the prop2 to see which is shorted.
  • Hopefully just the LDO and I might replace it with help from Tubular/ozprop. In the meantime I am lucky I have the 2nd working board. It does worry me that the VIO supply is not robust against brief shorts to ground as other people might hit this quite easily if working with pins.
  • evanhevanh Posts: 15,126
    It'll only be the one VIO group. The other seven groups will be okay.
  • Well I measured some of the other VIO and they were also bad (very low voltage). I need to measure all of it again to see what is up, I might be lucky and see it come back to life....
  • cgraceycgracey Posts: 14,133
    rogloh wrote: »
    Yes it is a revB EVAL board - so the VIO supply looks very vulnerable. It was just for the briefest of moments touching ground so BE CAREFUL with your boards. I need to look at the schematic to see if I can work out what is dead.

    Those LDO's have a good amount of thermal shutdown protection. They seem designed to be safe and indestructable. It would be good to measure the current going into all LDO's, which there is a jumper for. Are other LDO's outputting 3.3V? If the LDO input current is light, maybe just that LDO failed. If there is a huge current, the P2 might have developed an internal short.
  • cgraceycgracey Posts: 14,133
    It sounds like the USB supply opened up.
  • evanhevanh Posts: 15,126
    rogloh wrote: »
    Well I measured some of the other VIO and they were also bad (very low voltage). I need to measure all of it again to see what is up, I might be lucky and see it come back to life....
    Oh, that means that LDO is shorting its supply too, and is preventing the 5V_Common from coming up.

  • Well it is powered from my Mac laptop so hopefully it would be protected against overloads. I don't have one of those inline USB meters that shows current draw so it is hard to know what current is being drawn unless I can feed in power separately to USB somehow.
  • evanhevanh Posts: 15,126
    If you remove the LDO-VIN supply jumper then VDD should come up. It won't boot but proves that it's just shorted and nothing else is dead.

  • cgraceycgracey Posts: 14,133
    Maybe that sudden current surge tripped some breaker that VonSzarvas designed into the USB 5V connection.

    Have you unplugged everything and plugged it back in?
Sign In or Register to comment.