My rpm code fails on a zx40 - why

[FFMan]

I have some very simple code for capturing a square wave that comes from a Stack electronics rpm interface. Now i know this code & interface h/w works ok as its been working in a small zx24 based project in the race car for a few months. I also know the h/w on the motorbike works as i can see the square wave on my scope.
This project has also an i2c interface to a 4 digit 7 segment led module. I'm using chan 0 for the i2c to avoid resource conflicts, but i'm not sure the problem is i2c related as if i comment out the i2c open i still see the problem which is this. The code works fine for about a minute and then debug traces all return blank (i thought cstr(0) would print zero but it doesn't in this case - maybe a clue).

Code: Select all

			Call InputCapture (pulses, pulseStreamLen, 0,20)
			'debug.print cstr(pulses(1))
			if pulses(1)=65534 then
				rpm=0.0
				debug.print "No"
				exit sub
			end if
			sn_Temp=0.0

			for by_Cnt=1 to 20 
				sn_Temp=sn_Temp+CSng(pulses(by_Cnt))
				'debug.print cstr(by_cnt);" ";cstr(pulses(by_Cnt))
			next by_Cnt
			
			'debug.print " avg=";cstr(sn_Temp); " ";
			sn_temp=sn_Temp*0.0000542							'542/10000000 inc avg divide
			rpm=((1.0/sn_temp)*30000.0) * 2.0					'*2 for motorbike
	

debug trace extract at the point of failure. :-


1 40843
2 10898
3 40917
4 10619
5 40500
6 12577
7 40769
8 12849
9 41635
10 10855
11 42042
12 10249
13 41415
14 11409
15 41254
16 11980
17 41436
18 10954
19 41664
20 10118
2109
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
2151

i saw this behaviour on my test zx24 device also but put this down to s/w i2c and a resource conflict. i need to check if the working shift light project is a VM or native ZX, i can't remember at the moment.

any pointers much appreciated. can send the whole test code if required, its quite small.

thanks

[dkinzer]

any pointers much appreciated.

It usually is a good idea to completely isolate problematic code, i.e. construct a small test program that contains only the subject code. If the code under test doesn't work in that environment, it is easier to develop a strategy for determining what aspect of the code is causing the problem. If it works in isolation, then add other pieces back to the system, one by one, until it begins to fail again.

[FFMan]

the code under test is pretty minimal now. the rpm capture used to run as a task now called as required as a sub.

i'll create a test version of just a few lines tomorrow and see what happens.

is it proper that debug.print cstr(value) can result in a blank being printed rather than a zero ?

thanks

[FFMan]

Have been doing some testing, cutting out of code etc to try and locate the issue, and at this stage it looks as if the problem has nothing to do with inputcapture or i2c issues but a string handling problem ?

original code is:-

Code: Select all

		
str_RPM=fmt(rpm,0)
		str_RPM=mid("    ",1,4-len(str_RPM))+str_RPM
		Call LED_String(str_rpm,0)

if i change the code to this:-

Code: Select all

		'str_RPM=fmt(rpm,0)
		'str_RPM=mid("    ",1,4-len(str_RPM))+str_RPM
		Call LED_String(cstr(cint(rpm)),0)

i ran this code for several minutes and even rode the motorbike down the road and this revised code appears to be stable. If i reinstate the old code, it goes wrong withing a minute or so.

more testing needs to be done, but at this stage this appears to be the problem area.

[dkinzer]

a string handling problem

Is this a VM or native mode ZX-40?

[FFMan]

zx40n

i tried the code extract on a zx24p last night and didn't see the issue, i'll try the same extract on the zx40n tonight if i get time. i'm pretty sure i saw the issue also on a zx24n before i moved to the zx40n for other reasons.

when i say the extract, i have literally cut out what i think is the offending code and put it in a loop.

i'll post back later

[dkinzer]

a string handling problem

We have confirmed that this problem occurs when the length of the value string is exactly 4 but we don't know yet why. The issue can be avoided by adding a conditional as shown below. Even if this problem didn't occur, the coding below is probably better advised because it handles the case where the length of the string value is greater than 4.

Code: Select all

str_RPM = Fmt(rpm, 0)
Dim slen as Integer
slen = Len(str_RPM)
If &#40;slen < 4&#41; Then
  ' right justify the value
  str_RPM = Mid&#40;"    ", 1, 4 - slen&#41; + str_RPM
End If
Call LED_String&#40;str_RPM, 0&#41;

An alternate way to code it to get a similar result is shown below. This implementation displays at most 4 digits of the value.

Code: Select all

str_RPM = Right("    " + Fmt(rpm, 0), 4)
Call LED_String(str_RPM, 0)

[FFMan]

ok thanks for the notification, saves me time in the garage tonight testing it.

In fact now i think on it, if the figures go above 9999 then i need to drop the least significant figure really - not that i expect i shall be looking at the instruments if the engine is doing more than 10k revs, i will be watching where i am going.

i'd be interested to hear what the problem is when you get to the bottom of it. some sort of cumulative internal issue that brings about a more general failure after a number of iterations.

regards

[dkinzer]

i'd be interested to hear what the problem is when you get to the bottom of it.

The cause of the problem was that the special handling for the case where the first parameter to a string concatenation was a zero length string wasn't coded correctly leading, in some cases, to double freeing of an allocation from the heap. Freeing an allocation multiple times always leads to heap corruption eventually resulting in allocation failure - that's why you saw zero-length string results when you should not have.

The problem has been corrected internally and the initial testing results are good. We'll post a ZX Library update after full testing has been completed.

[FFMan]

out of interest is the problem only seen on native mode devices ?

[dkinzer]

out of interest is the problem only seen on native mode devices ?

Yes. On native mode devices strings are handled slightly differently. String concatentation is handled by separate code that doesn't have the same defect.