Physical interface between LCD and 52233 demo board

[MarcV]

Hello,

I was wondering if there is a document that describes the connection between the 52233 demo board and the LCD screen.
I assume the use of level shifters may be necessary because the coldfire is 3,3V based while most LCD's use 5V as power supply and sigal levels.

I have been playing a little with the simulator today, using the new SP7 of uTasker. I have set it up to use a time server, so the (simulated) LCD shows the time on screen after synchronisation. The display itself was configured as 4 lines x 20 columns.
The time did indeed appear on screen, but there also appeared a lot of rubbish on the screen. Not sure if that's OK...

[mark]

Hi Marc

Usually you should be able to use a direct connection and thus spare the level shifters. If you look at the LCD specifications you should find that they work fine at 3V3 (as opposed to 5V) although with the timing slightly slower. The project was configured to work with a direct 3V3 connection timing.

The only nuisance is usually the contrast voltage. With a 5V display this is typically about 0.5..1V to give optimum contrast. When the supply is only 3V3 it then requires a negative voltage of about -0.5..-1V, otherwise nothing is visible. There may be some LCD types which are optimised for 3V3 (and there are some with on-board converters to specifically generate the slightly negative voltage). I would take a look at a simple charge pump (eg. MAXIM has some) to generate a low current negative supply - it is also quite easy to control this with a PWM output from the processor to then have an electronically controllable contrast setting (the PWM value can be saved as a parameter to FLASH).

My preference is to invest a small amount of circuitry in the contrast voltage rather than in a level shifter... If you go for level shifter make sure that it is not only in one direction. At least the busy bit of the LCD (D7) needs to be able to be read.

As for the problem with the LCD in the simulator, this is not normal. I have just configured the SP7 with time server and 4 x 20 LCD to be sure and it worked OK:



Question.. Are you using Vista? I have not yet used Vista myself but a collegue of mine had difficulties with VS 2005 and Vista. We have been working on a project with a graphical LCD (128 x 64 or similar) and have added a graphical LCD simulator (not yet in the uTasker releases). On every one elses PC it worked well but on his only half of the display was visible, as if all content was shifted. We haven't looked into this yet. I wonder whether there is an incompatibility with the interface and Vista??

Can you send me a screen shot by mail so that I can get an impression of the problem?

Regards

Mark

[MarcV]

About the LCD simulation:
I have seen this happen on my old laptop which runs Win2000 and on which the simulator is compiled with Visual Studio 6 (Professional), as well as on my desktop which runs XP Pro (SP3) and on which the simulator is compiled with Visual Studio 2005 (Professional edition).

The odd thing is that I have seen it run fine on both systems and I have seen the rubbish appear on both systems. When I see the rubbish appear, it's like a string is copied to the screen past the end character.

I will post some screen shots later today as I'm at work now and I shouldn't be occupied with the uTasker!

[MarcV]

OK, here's what I get on my Win2K laptop, using VS6 Pro.
When running the program for the first time, the network connection is not yet selected. After I select the network card under the LAN menu, the IP address is resolved (I use DHCP) and then the time is displayed. Notice that there is no rubbish on the LCD but the line with asterisks isn't there either.



After quitting and restarting the simulator, it already knows the network connection to use. DHCP is immediately resolved and the time appears after the screen is filled with rubbish. The rubbish is frequently refreshed also. It looks like this:



The behaviour of this uTasker project on my XP PC compiled with VS2005 is nearly identical.

I have zipped this complete uTasker project and put it up on my web space. It can be found here:
http://www.mvdh.be/uTasker/ut.zip
Note that the zip file is encrypted with the usual uTasker Coldfire password.

[mark]

Hi Marc

I have tested your project and didn't have the problem with it here (?).

I can however explain a couple of things:
1. When using DHCP I first get the text "Fetching time" + "***************" in second line.
2. After about 2..3s (due to DHCP not yet being complete) the time client listener receives the event TCP_EVENT_ARP_RESOLUTION_FAILED, which causes the display of "No gateway?" and also a clear of the screen (command 0x01) which explains why there is no more second line with "***********" in this case.
3. Once the DHCP resolution has completed, the time is fetched from the Internet and displayed (all by itself).

I stepped through the process and didn't see where the strange LCD content is coming from - as I said I didn't see it when testing with your project as you sent it.

I do however remember seeing something quite similar once but I don't remember under what circumstances so I can imagine that there is something which can go wrong somewhere. My first thought is that the clear screen is somehow going wrong. In LCDSim.cpp the clear screen command simply fills the LCD graphic buffer with empty spaces as below:
        else if(ulCmd == LCD_CLEAR) {                                    // clear display and return to home position
            memset((void*)&tDisplayMem.ddrRam[0], ' ', tDisplayMem.uiDDRamLength) ;

In your case the content is obviously not empty but corrupted. I am wondering whether it could be due to certain network activity which you have causing task switches in the LCD simulator and WinPCap Ethernet simulator, leading to some data corruption. This is presently a long shot but apart from these parts there is not really any multi-threading going on and this means that such corruptions would normally be quite easy to see and find (which this probably is not).

I would be interested to know whether this only happens when using DHCP and the initial ARP resolve fails? You could also remove the clear screen and "No gateway?" text to see whether it is releated:
//      fnDoLCD_com_text(E_LCD_COMMAND_TEXT, (unsigned char *)cErrorLCDGW, (sizeof(cErrorLCDGW) - 1));

In any case I believe that it is a simulator issue and will not occur on real hardware. It is a shame that I can not reproduce it yet but I will be thinking of what could cause such an effect and hopefully it can be solved soon.

Regards

Mark

[mark]

Marc

Just after completing the last reply and before powering down the laptop for the night I ran the simulator once more. And...it did exactly the same as in your screen shot. In fact it happened well after the "No gateway?" which was displayed correctly for a couple of seconds - I think it happened about the time the first time was being displayed.

This means that I can indeed reproduce it, but, as you have also written, it doesn't always happen. The 'rubbish' is identical to yours so there is something systematic about this.

After a bit more checking I have found that I needed to start about 15 times before it happened again, but the chances are good that the cause can be identified.

Regards

Mark

[mark]

Hi Marc

This took some time but I have seen the problem - it occurs when the main simulator thread interrupts scheduling caused by Ethernet frame reception. This didn't corrupt the LCD simulator itself but instead the LCD transmit queue in the LCD task, which then sent an over long buffer with junk in it.

I hope that I also have a solution, but it may be best if you also test it since I have the feeling that you can reproduce it easier and if you don't get the problem any more it will be a very good sign.

Please do the following change in ReadDevice() in WinPcap.cpp

1. Add this initialisation right at the beginning of the routine.
    static CRITICAL_SECTION    cs;
    InitializeCriticalSection(&cs);

2. Protect the call main(RX_ETHERNET,ptr); as follows:
            EnterCriticalSection(&cs);                                   //  protect from task switching
            main(RX_ETHERNET, ptr);
            LeaveCriticalSection(&cs);

This should stop the processing from being interrupted by the main simulator thread and thus avoid this corruption possibility.

3. If you look in LCDSim.cpp you will see these three calls are there too. I believe that these are useless here so please comment them out.

If you can confirm stability this will be very good news. It may also explain some occurances of an exception in uEnable_Interrupt() in M5223X.c which has been reported by one or two users which I never managed to reproduce - this is a check of a non-serious error but something which is unexpected, which only occurs in the simulator. I think that I can explain it due to a similar mechanism (although it occurs much less frequently than the LCD problem) which would also be solved!

Thanks!

Regards

Mark

[MarcV]

Nope, still the same!...
I also switched back to using a fixed IP (no DHCP) and I still get the rubbish, with the only difference that those 3 rubbish characters on the 3rd line are now different.
Disabling the no gateway message makes no difference either.

[MarcV]

I played a little with "application.c" and found that one particular call caused the rubbish to appear. Commenting out this line makes it go away, while the time is still displayed including the line with asterisks. (there's still another fnDisplayTime call)

    #ifdef SUPPORT_LCD
        fnDisplayTime(ulPresentTime);

Code: [Select]

    case TCP_EVENT_DATA:                                                 // a time server sends the time in seconds from 0:0:0 1900 and terminates
        ulPresentTime = *ucIp_Data++;
        ulPresentTime <<= 8;
        ulPresentTime |= *ucIp_Data++;
        ulPresentTime <<= 8;
        ulPresentTime |= *ucIp_Data++;
        ulPresentTime <<= 8;
        ulPresentTime |= (*ucIp_Data);

        ulPresentTime -= REL_9_1_2007;                                   // relative to 0:0:0 on 9.1.2007
        ulPresentTime += GMT_OFFSET;
        while (ulPresentTime >= SECONDS_24_HOURS) {
            ulPresentTime -= SECONDS_24_HOURS;                           // convert to seconds of day
        }
    #ifdef SUPPORT_LCD
        fnDisplayTime(ulPresentTime);
    #endif
        uTaskerMonoTimer( OWN_TASK, (DELAY_LIMIT)(1*SEC), E_SECOND_TICK );
        break;

    case TCP_EVENT_CLOSE:
    case TCP_EVENT_CLOSED:
        if (ulPresentTime) {
            break;


[mark]

Marc

Unfortunately your observations are correct, also more tests here have shows that this doesn't work correctly. The problem is that the method using EnterCriticalSection() and LeaveCriticalSection() doesn't work correctly - the main thread still interrupts the WinPCap thread. I don't know these functions but copied them from some other code - I think that they are being used incorrectly and so they don't help. I think that I will need to study the Windows techniques more.

However I believe that there is a simple solution which will be adequate for our needs. I tested it by agrevating the problem with a long delay in the LCD simulator, increasing the chance of the event happening to about 50% (rather than about 5% as it normally was). Then I tested quite a number of times with and without the workaround and this time the chances of a cure look much better - again I will only be 100% sure when you give the 'thumbs-up' on it.

Remove the EnterCriticalSection() / LeaveCriticalSection() since this is not helping, but add the following line of code to main() in WinSim.c at the beginning of the TICK_CALL case:

    case TICK_CALL:
        if (iOpSysActive != 0) return 0;

This will simply skip a TICK (from main simulator) if it is seen that the WinPCap thread has activated the simulator and thus avoid the interruption, with possible corruption result.

I hope that the results are then better!

Good luck

Regards

Mark

[MarcV]

Great work Mark! That seems to have worked!

[mark]

Super - I am relieved.

I will be studing some more (professional) techniques (semaphores or mutex etc.) for the future but I think that this should be fine for the present project...

Regards

Mark