Testers needed: re: Range check error: TLCD_HD.UsecDelay

Post by **clansley** » February 20th, 2006, 9:38 pm

A huge number of bug reports are coming in for a Range Check error.

The generated bug report looks something like:

...
exception class : ERangeError
exception message : Range check error.

main thread ($fcc):
005004a7 +097 LCDSmartie.exe ULCD_HD 393 +16 TLCD_HD.UsecDelay
...

Is anybody having this problem able to test a fix?

Post by **limbo** » February 21st, 2006, 6:27 pm

Hey Chris you're back on scene again!
Thats nice...

NO I Never Experienced this error...

Post by **IFR** » February 22nd, 2006, 11:20 pm

me neither.

beldaal · Post by **beldaal** » March 10th, 2006, 10:28 pm

Hi
I experienced this today for the first time. I've been using Smartie for some time on one machine, and I've just set up a new one, which I access exclusively via Remote Desktop Connection (no monitor, keyboard or mouse). Not exactly the same error, but Range Check, etc. I mailed it his morning.

After getting the errors - hundreds, everytime I did anything on the machine: copy, paste, open windows etc - I gave the box it's own monitor, keyboard and mouse, primarily to check the bios and confirm I was using EPP. After booting, Smartie worked faultlessly. However, as soon as I was back accessing via RDC I got the errors.

I would be very happy to do any testing that I could, as I'd love to get rid of the errors. Eventually, there will be 4 unattended machines, and the whole purpose of the LCD and Smartie is to display what each machine is and what its function is. All I really need (sad really) is simple static text display, and as it stands, I can ignore the errors, and the LCD does what I want. But I would like to extend to more sophisticated stuff in the future (perfmon etc).

It's also got an AMDX2 3800.

Regards to a great piece of software and a great forum

Nigel

beldaal · Post by **beldaal** » March 10th, 2006, 10:49 pm

Well
Further to the above, I've just looked further (that'll teach me) and found mysteryman's reply in another thread on 3Nov2005

Problem solved for me

I changed in the Device Manager the LPT1 setting from Never use a Interupt to Use any interrupt assigned to the Port. Also in LCD Smarties for the configuration of the HD44780, I set the Timing Multiplier to zero.

Weill I tried this (under RDC) and the errors stopped.

Thank you mysteryman! I'm not yet sure whether it was the Device Manager change or the Timing Multiplier value, but I'll test further on Monday.

Nigel

beldaal · Post by **beldaal** » March 13th, 2006, 11:28 am

Well - after my pleasure at getting the errors stopped, I got into work this morning, and saw that the LCD was blank.

So I went back to the HD44780 configuration, and set Timing Multiplier back to 1, and up it came.

Note that I haven't restarted the machine (or LCDSmartie) for over 3 days.

And no more errors. So it looks like, if you do get the problems, then changing LPT1 from "Never use an Interrupt" to "Use any interrupt assigned to the port" is a good place to start.

Nigel

beldaal · Post by **beldaal** » March 14th, 2006, 6:19 pm

Actually, having done a lot more with 4 identical machines, the errors have returned so badly that I'm now tempted to turn off LCDSmartie, and try and find some other software to run the LCDs (not found anything yet half as good as Smartie, though

).

I've tried messing with the BIOS - EPP/ECP, different versions, different IRQs etc, and some options seem to make it happier for a bit, and then it just goes bad again - often, it seems, triggered by mouse movements (could it be IRQ related?).

Help anyone? If there is any testing I could help with, I'd be more than happy to get involved.

Regards all
Nigel

ReverseEngineered · Post by **ReverseEngineered** » March 14th, 2006, 11:14 pm

Unfortunately, we need some idea of what line in the program is causing this RangeError to come up. A range error seems a strange thing to be triggered by IRQ activity...

Have you been able to come up with any reliable way of reproducing it? Perhaps if we could reproduce it, we would be able to find out where the problem is. Otherwise, there's very little we can do.

I will take a look at the source where the error report said it occured and see if I can find any reason for this reaction.

ReverseEngineered · Post by **ReverseEngineered** » March 14th, 2006, 11:20 pm

Hmm, more importantly, can you post the entire contents of that bug report? I really need to know the entire call stack at that time to be able to figure out why the error would have occured.

beldaal · Post by **beldaal** » March 15th, 2006, 9:24 pm

Hi ReverseEngineered,
I have sent a zip of 4 bugreports direct to your personal mail. I wasn't sure if there was any way of attaching them to my forum post.

regards
Nigel

ReverseEngineered · Post by **ReverseEngineered** » March 18th, 2006, 3:02 am

Thank you beldaal for your excellent reports. I found an very obvious problem which would have caused that.

The timers which we use to count the delays between sending commands to the LCD are Windows "high performance counters", which are essentially 64-bit ints that count instruction cycles. When the scaling was first written, to get microsecond counts (instead of seconds), a multiplier of one million was used. Of course, with fast machines, a million times the number of clock cycles during this delay could very well overflow a 64-bit integer. I have changed it to instead divide the frequency by one million. This has the same effect but is safe from overflows.

I have fixed this both in CVS and in the final version of 5.3.2 which I will be posting soon (hopefully Monday; very busy with school at the moment).

beldaal · Post by **beldaal** » March 18th, 2006, 11:41 am

Great news, ReverseEngineered
I look forward to eliminating all my errors!
Thanks,
Nigel