odd behavior PTB2/PTB3 on 908jk3

[eeetee]

hi:

this is driving me nuts! i had problems programming and attributed it to other changes i had made, not so! i have simplified the code and can create the problem on demand. the two lines below ;hardware init cause the programmer (usbmultilink) to do some unusual things. if i reverse the lines so that PTB3 is cleared before PTB2 is set everything works as expected. if i program the chip with the lines in te current order i get no error messages, however {F5} reports that the processor is running and the green led does not light. if i disconnect the multilink and run from a power supply the green led does not light either. swapping the two lines works great on either the in circuit debugger or the stand alone. has this been identified before?

main:
_Startup:  
        mov  #%00000001,CONFIG1  ;disable the cop
           rsp

;hardware init
           bset  2,PTB                 ;ensure red is off
           bclr  3,PTB                 ;start with a green light

           mov   #%11111111, DDRA      ;porta is not bonded set as outputs
           mov   #%00001100, DDRB      ;portb d7..d4 analog, d3=redled d2 grnled, d1,d0 mono8 interface
           mov   #%00110011, DDRD      ;portd d7,d6 undefined digital inputs, d5,d4 injector drv, d3,d2 analog current monitors d1,d0 unbonded
           bra   *

best regards,

ed

[tonyp]

If it makes you feel any better, about a year and a half ago I reported to Freescale a very similar odd behavior with a QY4 chip.  I quote a part of that message:

"I have noticed the following behavior in a batch of QY4 chips, marked as Freescale with mask revision RMDD0447:

After reset, writing a value to PORTA and then setting the DDRA to outputs does not work, i.e., pins do not change to the expected state.  If I set the DDRA to outputs first, then write the value to PORTA it works OK."

This happened for only a certain mask I had in stock.  They said they will investigate it but they never replied if they could verify this.

[rocco]

Believe it or not, this is expected behavior.

The reason that this is what you should expect is that you a using BSET and BCLR instructions when the port is still configured as an input. BSET and BCLR are read/modify/write instructions, but what is written is not what will later be read by the BSET/BCLR if the pins are configured as inputs. In other words, setting one bit with BSET would corrupt other bits in that byte, and the same is true with BCLR.

Either of the following will solve the problem:
1) Set the pins as outputs before using BSET or BCLR on them. or
2) Use a STA instruction to write the port instead of a BSET or BCLR

I hope that was understandable . . .

[tonyp]

Nice catch!  They tell you to set the pin state before making it an output (to avoid possible unwanted pulses) and that can get you, if not careful.

[I'd better check if my problem was due to such an oversight, also (although I normally use STA for initializing variables, ports, etc) if I can remember which program it was!]

[eeetee]

hi:

thanks guys! i thought i may have some oddball hardware issue or an errant firing synapse.

regards,

ed