16F1829 Problem Reading RA2 Input

[jpanhalt]

Third day looking at this problem. Need a new set of eyes.
MCU=16F1829 (not LF version)
Language=MPASM
Programmer/Debugger=MPLAB ICD3 using hardware debug
Defined SW1 as RA2

Programmer and same chip worked in demo described here: https://www.electro-tech-online.com/threads/driving-stepper-motor-gauges.144733/page-2#post-1226483

Program hangs here:

Program Counter (PC) goes to "goto Debounce" as if SW1 were low. Voltmeter on SW1 shows 4.95V. When SW1 is pressed, voltmeter goes to zero. Pull-up resistor on SW1 = 22K. Pressing SW1 has no on PC.

I am a bit confused about what the Watch window means:

PORTA does not change regardless of whether SW1 is pressed. Why does "RA2" show 8 bits? As the PC goes "btfss" and "goto debounce" RA2 changes from 0xCA to 0xCB (i.e., bit<0> is set and cleared).

I have even gone so far as to use the initialization procedure for Port A in Example 12-1 of the datasheet. Comparators are turned off.

Here is the code:

START
     MOVLB     1              ;Bank1                                       |B1 
     MOVLW     b'01110000'    ;                                            |B1
     MOVWF     OSCCON         ;4xPLL disabled, 8MHz                        |B1
     BTFSS     OSCSTAT,HFIOFR ;HF internal oscillator ready                |B1
     GOTO      $-1            ;                                            |B1
     MOVLW     b'00001100'    ;                                            |B1
     MOVWF     TRISA          ;PORTA 2(SW1) &3(MCLR) inputs                |B1
     CLRF      TRISB          ;all outputs                                 |B1
     CLRF      TRISC          ;all outputs                                 |B1
     BSF       TRISC,5        ;set RC5 to input                            |B1
     CLRF      ADCON0         ;ensure ADC off (necessary?)                 |B1
     CLRF      ADCON1         ;ensure ADC off (necessary?)                 |B1
     BCF       OPTION_REG,7   ;enable WPU by individual latches            |B1
     MOVLB     2              ;APFCON0 bank                                |B2
     BSF       APFCON0,7      ;set RX/DT to RC5                            |B2
     BSF       APFCON0,2      ;set TX/CK to RC4  DEBUG 08/07/15&&&&&&&&&&&&&&&&&&
     BCF       CM1CON0,C1ON   ;turn off comparator 1 08.08.15 debonce still not working
     BCF       CM2CON0,C2ON   ;turn off comparator 2
     CLRF      LATA           ;080915                       |B2
     MOVLB     3              ;Bank3                                       |B3
     CLRF      ANSELA         ;Turn off analog inputs                      |B3
     CLRF      ANSELB         ;NB:comparators are off on reset             |B3
     CLRF      ANSELC         ;                                            |B3
;Receive set-up and baudrate
     BSF       TXSTA, BRGH         ;baud rate setup, 8-bit async           |B3
     BCF       BAUDCON, BRG16      ;set 8-bit baud generator               |B3
     MOVLW     .51                 ;see Table 22-5 datasheet               |B3
     MOVWF     SPBRG               ;set baud 9600 ±0.16%                   |B3
     BSF       RCSTA, SPEN         ;USART receive enable                   |B3
     BCF       TXSTA, SYNC         ;USART config asynchronous, default=0   |B3
     BSF       RCSTA, CREN         ;USART receive circuitry enable         |B3 
;/Receive set-up
     MOVLB     4              ;                                            |B4
     BSF       WPUA,2         ;enable WPUA for SW1                         |B4
     MOVLB     0              ;                                            |B0
     CLRF      PORTA          ;080915                            |B0

Sorry for all the garbage in the code. That is the way it looks after all this time of trying to find the glitch.

John

 

[Joe G]

just out of curiosity, have you made sure what bank you are in? the tris banks are not the same as the port banks. aka=banksel
its been awhile since i've used assembly,.

 

[jpanhalt]

TRIS registers are in Bank1, which is selected as the first instruction after "Start." On the right most column, I try to keep track of the registers, when it is important. MOVLB selects the bank based on the literal.

Just reassigned SW1 to RA5 (pin2) , at least it is being recognized now. I am still confused about what the Watch window means for RA2. The "equivalent" Watch for RA5 shows all zeros, regardless of whether SW1 (now assigned to RA5) is pressed.

John

 

[Ian Rogers]

Just ran it in ISIS and it works as expected.

RA2 is still showing wrong!!

What is the condition of the INLVLA register???

 

[Ian Rogers]

Ok it appears that the SR latch is on!!! The effects of a reset is undetermined...

Also INLVLA needs to be cleared,,

 

[jpanhalt]

Darn it, you are good.

INLVLA on reset is 000100 and that is what it read in the watch window. Added CLRF INLVLA ;|B7 and now the program
works just like it did after I changed SW1 to PortA,5. I still don't understand RA2 in the watch window (with SW1 pressed):

But, at least bit<2> of RA2 (whatever that means) is changed with SW1.

John

Edit: Just saw post #5, which came up while I was working through my reply. Thanks again. Still don't understand what "RA2" means or shows, but at least I can watch PortA and see the change.

Recently starting using the 16F1829. Switched from the 16F1519 and skipped reading every part of the datasheet. The 16F1519 doesn't have that "feature."

 

[Ian Rogers]

I wish Ritesh was as easy to sort out...

I'm using the same processor... I will be looking at this when I get back to work as I have a very weird problem, but I'm sure mine is on PORTB....

 

[jpanhalt]

I am truly flattered to be compared to Koolguy. That is one thing I have never been called.

Anyway, I spoke too soon. First your advice about the ST vs. TTL switch was useful and appreciated. I hadn't read that part, figuring the two chips were very similar except for some peripherals. Second, I made the cardinal mistake of making more than one change at a time. (At my age, can you blamed me for wanting to speed things up when using hardware debug? I don't have many years left.) I had eliminated the "goto Debounce" and short circuited to simply to a goto debounce in the start routine, which worked:

Short story, I can duplicate the problem regardless of which port I use (RA2 or RA5) and the setting of INLVLA. Here is the disassembly code:

Of course, the program code that is accessed by a goto is:

I checked the Disassembly listing on the slim chance that paging had reared it ugly head. It is not a paging issue. When the program goes to Debounce, the PC simply alternates between the lines beginning "btfss" and "goto debounce" regardless of the input signal. This is the watch window. PortA,2 (aka SW1) should be read as set, but it isn't:

Thinking there might be something funny in simulation about reading the first instruction after a goto, I inserted two NOP's and it did not affect anything. It is just not reading that input port and responding as I want it to respond. Voltages on the pin with a voltmeter are correct, high= 4.95; low=0.00. (The delay is commented out,because under hardware simulation, it it interminable.)

John

 

[atferrari]

Hola John,

Isn't that pin involved with another peripheric?

Maybe you recall that some time ago I posted about initializing upfront all SFRs as they should be after RESET (as per the datasheet ). Why not now? Even just those involved in your current problem. Buena suerte.

 

[jpanhalt]

Almost all pins nowadays have more than one function. The problem occurs both with RA2 and RA5. I have disabled all analog and comparator inputs. Most telling, when it is a simple "goto" in the start sequence, it works. It is only when the "goto" comes later in the program, like on exit from receiving serial data, that it doesn't work. Unfortunately, I cannot easily tell what the step before the goto that gets to the hang is. But, I don't see how that can make a difference as Port A is only used for MCLR and this switch function.

None of the functions of any of the PortA pins are utilized in the rest of the program. The rest of the program, which is now a complete cobweb of commented sections as I have tried to find the problem is simply a USART receive and stepper driver (USART receive is PortC and the stepper driver is PortB).

With hardware simulation, you are limited to 3 breakpoints. I suppose I could add a breakpoint at each "goto debounce." That would certainly give me something to do for the rest of the day, but I am not sure how that could explain what I am seeing. I am going to start that process now.

I learned that same lesson with initializing SFR's, but SFR's are not involved in a simple "btfss portA,x" instruction.

John

 

[atferrari]

If I understood this right PORTA IS one of them. Just in case, I always "repeat" what the datasheet says.

BTW, nothing to do with "rmw", no? I forgot that after moving to the 18F family.

 

[Ian Rogers]

When I do the same in MPLAB v8.xx it looks good

 

[jpanhalt]

Hi Ian, It works in MPLab SIM for me too. It is just that simulating the USART with MPLab SIM using a real input is like sledding on a rock pile.

I did find one place that has a goto immediately before the program hangs:

None of the other goto's got to the hang. Of course, this is one of the early (actually earliest) goto, unless it is an error. DataExit is the last step in the USART, which is in-line code, not interrupt driven. I will omit t and see what happens. My guess is that the hang will just occur after the next "goto."

I am perplexed why the "debounce" from a goto is in the start sequence works fine, but when it is called later later it does not work. There is, of course, only one "Debounce" routine.

John

 

[jpanhalt]

Here's another observation:

I have two of these steps in the USART rountine, as I receive two bytes (Hi and Lo) of a 14-bit data. Without the breakpoint at "movf RCREG,w", it hangs at the "btfss PIR1,RCIF ) step -- apparently not seeing the flag. However, when I insert a breakpoint after that step,it sees the flag and moves to the breakpoint. RCREG is also updated with the new byte.

You mentioned using ISIS simulator. I guess that is part of Proteus, and there appears to be a free download of Proteus ISIS. I am assuming the pro version is quite expensive. Have you used the free version?

John

 

[jpanhalt]

If I understood this right PORTA IS one of them. Just in case, I always "repeat" what the datasheet says.

BTW, nothing to do with "rmw", no? I forgot that after moving to the 18F family.

Sorry I didn't respond earlier. For some reason, I got notice of Ian's comment and just received notice of your earlier comment. I do not think it is RMW. ALL of my writes for driving the stepper are to the latches, namely LATB.

I have the simulation hobbling along right now. The trick was to judiciously place a breakpoint in the USART (see post #14) that allows both bytes to be received sequentially without causing a hang up.

USART is working (which I knew from several days ago). The destination bit (bit<7>) on the high bit is getting the bytes properly sorted. Math is working. First I strip the destination bit from the high byte, then divide by 16 to give myself a simple 10-bit value. (It is actually a little more complex than that. I have to create a blank bit<7> in the low byte, then take that into consideration wit the divide routine.)

Now, I am playing with getting the stepper routines so they only look at the difference between previous and new encoder reading and don't over drive. Divide by 16 may not be enough to stop overdriving them.

John

 

[Ian Rogers]

You mentioned using ISIS simulator. I guess that is part of Proteus, and there appears to be a free download of Proteus ISIS. I am assuming the pro version is quite expensive. Have you used the free version?

The free version has no processor models.... I think the cheapest pic model is £150.... I have the full pic complement.. And yes it is over a grand...

 

[jpanhalt]

£150 seems reasonable, if it can do good peripheral simulation of enhanced mid-range PICs. Is it pure simulation or does it actually use the hardware like the MPLab ICD3 tries to do ?

Anything would be better than dealing with a simulator (MPLab ICD3) that can't follow simple instructions like btfss or subwf,f. I am sure there is a reason for that apparent failure. I just haven't found it.

Here's an example: I have a short 16-bit subtraction routine. It works great with MPLab SIM and even gives the right answer! (sarcasm). That is, 0xc05 - 0x301 = 0x904. The same program copy-and-pasted into the thing I am testing with the MPLab ICD3 simulator (i.e., the simulator that caused me to start this thread) gets the wrong answer. I have made several snippets to illustrate the steps and will get them composed into something here. Need to get some sleep and review again with brighter eyes.

The basic problem seems to be that the ICD3 simulator can step through a program but for some reason it may ignore an instruction like btfss or subwf. Looking at the LSB in the above example, 05-o1 = 4 in hex or decimal, but MPLab ICD3 showed 05. In other words, although the cursor moved, the action wasn't performed. Of course, that screws up subsequent parts. Other parts of the program work fine.

I usually use MPLab SIM, and although it is pretty limited in simulating peripherals, it works well within its limitations.

See you in a few hours.

John

 

[Nigel Goodwin]

Why bother with simulations?, just do it for real

 

[Ian Rogers]

£150 seems reasonable, if it can do good peripheral simulation of enhanced mid-range PICs. Is it pure simulation or does it actually use the hardware like the MPLab ICD3 tries to do

John

Nah!! The small £150 gets you pic16f84 , pic16f877a and pic18f452... Which can get most people by!!

It was a good start for me as I used both pic16f877a and pic18f452... I've sinced moved to the newer chips, but as they are ALL supported in the newer package, I'm okay.... They add the newer chips quite frequently

 

[jpanhalt]

Hello,
I saved several snippets earlier today showing the difference between an MPLAB ICD3 (hardware) simulation and the MPLAB SIM software simulation. Suffice it to say, the ICD3 simulation goes through the subtraction steps and doesn't subtract. That is, very much like going through a BTFSS instruction and not being affected by the status of the targeted bit. Here are two composite images of my comparison.

The first is a side-by-side snippet of the two programs. In the SIM program, I had to load the registers, as the data in those registers comes from another PIC via the EUSART peripheral of the 16F1829.


And here are the results from the watch window. The subtraction equation is 0xc05 - 0x301 = 0x904 .With the routine that was used (source = PicList), the result of the subtraction ends up in the same registers as the number from which the subtraction was made, i.e, CountH/L.

It is not a particularly long program, but it does have some math routines to take raw, 14-bit data from an encoder and adjust it to display a change in position. My indicator is a stepper motor with about 600 full-steps per revolution, so I reduced the original data to just 10 bits. Still, I need to check some details of the programs, and that is almost impossible to do with just hardware.

As for why the ICD3 doesn't simulate properly, I could not find any examples of that behavior on the Internet. There are plenty of discussions about difficulties using the simulator, but no examples that I could find of it giving wrong math results once the user has the simulator working.

FWIW: "Temp" is the receiving register for the data. In the example shown 0xB0 becomes SPI_H after removing the address bit (7) and dividing by 16.

John