A really wierd problem

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using a tiny13 chip& suspect there is something wrong with it...I am using 2 registers to hold 1 flag bit in each. All works fine. When I combine them into the SAME register the program quits working.
sysflag=r25, sss=r23 works
sysflag=r25, sss=r25 does not
sysflag=sss=r19 does not

since the flag bits are bit 0 & bit 2, combining them into one register should be fine

I tried other register combos, but the bottom line is when these are set to the SAME register it does not work, as though the bits are not independent. I verified that the ONLY places (throughout the code) these registers are used are as follows:
one flag is bit zero, the other flag is bit 2
I verified that the LST opecode for each looks good.
ALL lines using these locations from the code:
sbrc sysflags, 0
sbrs sss, 2
sbr sysflags, 1 ;phase 1
cbr sss, 4
cbr sysflags, 1 ;phase0
sbr sss, 4
cbr sysflags, 1 ;show phase0

The only thing affecting the bits are CBR & SBR & as shown only affect a single bit (bit 0 [value=1] or 2 [value=4]). I was using labels (like 1<<phase0), but got rid of them during the investigation
I am using interrupts, and some of these statements are located in interrupts, but are only used as already mentioned. I simply don't see why things work when sss & sysflags use different registers. Again, these registers are used ONLY where shown above. I thought perhaps it has something to do with interrupts and r-m-W cycles, but have never encountered such strangeness before. Its as though the SBR/CBR is not atomic through interrupts
Is this some flaw in the tiny13?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With SBR and CBR you can set MORE than 1 bit at the same time, so 1<<phase0 is the correct way to do it as long as phase0 is defined as 0 and phase2 is defined as 2.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yes, sss should be working with bit 2, and sysflag with bit one...when they are combined in one register the program quits working properly. Note that SBR & CBR also set various sreg flags (sreg is saved & restored in my interrupts). I went and checked to see if that might have an effect when the flags are combined into one register. From the rest of my code, it does not appear it would have any effect "down the line"

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can't you just step the code in the simulator and watch for when things don't work as expected?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it uses interlocked timers and an external signal, so stepping it is out of the question---it would have no hope of working, even when its working

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1) What do you mean "doesn't work"?
2) Explain again why you cannot take your "doesn't work" code fragment as shown and pre-load with various combinations and run it in the simulator?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FOUND IT--
as noted, the SBR & CBR also set various flags, not just the bits...turned out when I added more flag bits, the flag register now NEVER becoame zero and the following (improper) began to "fail"

	cbr sysflags, (1<<flag_phase1) ;show phase0		
			sei  ;begin phase0						
			rjmp get_syncd	

note the following code is in the beginning of the ISR which is enabled (SEI) immediately after clearing a flag bit in sysflags:

	sbrc sysflags, flag_phase1
			breq phase1
;================================
phase0:		push fullcycles ;save for restoration

in the above, the SBRC is really not doing anything, since the breq is looking at sreg!!...it just happened to "work"...until more bits were added to sysflag...... the breq should have been rjmp all along:

		
			sbrc sysflags, flag_phase1
			rjmp phase1
;================================
phase0:		push fullcycles ;save for restoration

...the needle in the haystack

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!