CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Strange MPSIM for LATB & PORTB with PIC18F26K22 [SOLVED]

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Mike Walne



Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK

View user's profile Send private message

Strange MPSIM for LATB & PORTB with PIC18F26K22 [SOLVED]
PostPosted: Mon Feb 27, 2017 11:55 am     Reply with quote

Is this a known MPLAB SIM problem, or am I missing something?
I'm wanting to drive a stepper motor and started from the CCS example.
When I simulated in MPLAB for a PIC18F26K22 I got rubbish with CCS code.
I've played with the code and still get gibberish with the '26' device.
MPLAB is fine with PIC18F46K22 and PIC18F252 parts.
The real thing behaves as expected.
I've used the code below. On each line I've shown both '26' '46' outputs after the first time round.
I'm showing the states before execution of the instruction, i.e. where the cursor is pointing.

I'm using MPLAB IDE v8.92 and CCS v5.059
The disassembly listing for both '*K22' parts more or less agree.
Code:
// Port B Test

#include <18F26K22.h>
//#include <18F46K22.h>
#fuses ECH,NOWDT,NOPROTECT,NOLVP,NOPLLEN
//#include <18F252.h>
//#fuses HS,NOWDT,NOPROTECT,NOLVP
#use delay(clock=4000000)

main()
{
   while (TRUE)               // PIC18F26K22     PIC18F46k22
   {                          // LATB   PORTB    LATB   PORTB
      output_low(PIN_B3);     // 0b0000 0b0111   0b1000 0b1000
      output_high(PIN_B0);    // 0b0111 0b0000   0b0000 0b0000
      output_low(PIN_B0);     // 0b0000 0b0111   0b0100 0b0100
      output_high(PIN_B1);    // 0b0111 0b0000   0b0000 0b0000
      output_low(PIN_B1);     // 0b0000 0b0111   0b0010 0b0010
      output_high(PIN_B2);    // 0b0111 0b0000   0b0000 0b0000
      output_low(PIN_B2);     // 0b0000 0b0111   0b0001 0b0001
      output_high(PIN_B3);    // 0b0111 0b0000   0b0000 0b0000
   }
}


Disassembly listing looks OK to me.
Code:
1:                 // Port B Test
  0000    EF02     GOTO 0x4
2:                 
3:                 #include <18F26K22.h>
4:                 //#include <18F46K22.h>
5:                 #fuses ECH,NOWDT,NOPROTECT,NOLVP,NOPLLEN
6:                 //#include <18F252.h>
7:                 //#fuses HS,NOWDT,NOPROTECT,NOLVP
8:                 #use delay(clock=4000000)
9:                 
10:                main()
  0004    6AF8     CLRF 0xff8, ACCESS
  0006    9ED0     BCF 0xfd0, 0x7, ACCESS
  0008    010F     MOVLB 0xf
  000A    6B38     CLRF 0x38, BANKED
  000C    6B39     CLRF 0x39, BANKED
  000E    6B3A     CLRF 0x3a, BANKED
  0010    6A77     CLRF 0xf77, ACCESS
  0012    6A78     CLRF 0xf78, ACCESS
  0014    6A79     CLRF 0xf79, ACCESS
11:                {
12:                   while (TRUE)
13:                   {
14:                      output_low(PIN_B3);
  0016    9693     BCF 0xf93, 0x3, ACCESS
  0018    968A     BCF 0xf8a, 0x3, ACCESS
15:                      output_high(PIN_B0);
  001A    9093     BCF 0xf93, 0, ACCESS
  001C    808A     BSF 0xf8a, 0, ACCESS
16:                      output_low(PIN_B0);
  001E    9093     BCF 0xf93, 0, ACCESS
  0020    908A     BCF 0xf8a, 0, ACCESS
17:                      output_high(PIN_B1);
  0022    9293     BCF 0xf93, 0x1, ACCESS
  0024    828A     BSF 0xf8a, 0x1, ACCESS
18:                      output_low(PIN_B1);
  0026    9293     BCF 0xf93, 0x1, ACCESS
  0028    928A     BCF 0xf8a, 0x1, ACCESS
19:                      output_high(PIN_B2);
  002A    9493     BCF 0xf93, 0x2, ACCESS
  002C    848A     BSF 0xf8a, 0x2, ACCESS
20:                      output_low(PIN_B2);
  002E    9493     BCF 0xf93, 0x2, ACCESS
  0030    948A     BCF 0xf8a, 0x2, ACCESS
21:                      output_high(PIN_B3);
  0032    9693     BCF 0xf93, 0x3, ACCESS
  0034    868A     BSF 0xf8a, 0x3, ACCESS
  0036    D7EF     BRA 0x16
22:                   }
23:                }
24:                /*
  0038    0003     SLEEP
Does anyone else get the same as I do?

Last edited by Mike Walne on Tue Feb 28, 2017 3:47 am; edited 2 times in total
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Feb 27, 2017 1:24 pm     Reply with quote

Quote:
When I simulated in MPLAB for a PIC18F26K22 I got rubbish with CCS code.

What exactly is rubbish ? and where are you looking in MPLAB 8.92
when you see it. Give precise instructions on how to duplicate the
problem.
Ttelmah



Joined: 11 Mar 2010
Posts: 19496

View user's profile Send private message

PostPosted: Mon Feb 27, 2017 1:52 pm     Reply with quote

The problem you have is the ECCP.

On the smaller PIC ECCP1 is multiplexed onto the low PortB pins.
The ECCP is designed so that it wakes up driving it's pins, so that a power driver using it, does not have it's inputs floating.
You need to turn off the ECCP so that the pins can be used for normal I/O.
Currently B0, is behaving as the ECCP fault control, so overrides the other pins....
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Feb 27, 2017 2:00 pm     Reply with quote

Thank you Ttelmah. I understand now. I never simulate i/o ports.
I only simulate code. That's why I didn't understand his question.
Ttelmah



Joined: 11 Mar 2010
Posts: 19496

View user's profile Send private message

PostPosted: Mon Feb 27, 2017 2:43 pm     Reply with quote

The great thing is how good the 'team' here is. You'll spot oddities it'd take me ages to see, while I then see other things. Add a few others (Jay etc.), and there is little we don't know about the PIC. Smile
Mike Walne



Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK

View user's profile Send private message

PostPosted: Mon Feb 27, 2017 6:04 pm     Reply with quote

PCM programmer wrote:
Quote:
When I simulated in MPLAB for a PIC18F26K22 I got rubbish with CCS code.

What exactly is rubbish ? and where are you looking in MPLAB 8.92
when you see it. Give precise instructions on how to duplicate the
problem.

I'm looking at LATB and PORTB in a watch window as I single step through either the CCS source code or the disassembly listing.

The values I've added to the source code were copied from the watch window.

What's really throwing me is the fact that the hardware behaves perfectly with all the chips mentioned but the 18K26K22 does not tally with MPLAB SIM.

Thanks for your response.

Mike
Mike Walne



Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK

View user's profile Send private message

PostPosted: Mon Feb 27, 2017 6:18 pm     Reply with quote

Ttelmah wrote:
The problem you have is the ECCP.

On the smaller PIC ECCP1 is multiplexed onto the low PortB pins.
The ECCP is designed so that it wakes up driving it's pins, so that a power driver using it, does not have it's inputs floating.
You need to turn off the ECCP so that the pins can be used for normal I/O.
Currently B0, is behaving as the ECCP fault control, so overrides the other pins....

Thanks Ttelmah. I sort of follow what you're telling me. My code is now
Code:
// Port B Test

#include <18F26K22.h>
#fuses ECH,NOWDT,NOPROTECT,NOLVP,NOPLLEN
#use delay(clock=4000000)

main()
{
   setup_ccp1(CCP_OFF);
   while (TRUE)               // PIC18F26K22     PIC18F46k22
   {                          // LATB   PORTB    LATB   PORTB
      output_low(PIN_B3);     // 0b0000 0b0111   0b1000 0b1000
      output_high(PIN_B0);    // 0b0111 0b0000   0b0000 0b0000
      output_low(PIN_B0);     // 0b0000 0b0111   0b0100 0b0100
      output_high(PIN_B1);    // 0b0111 0b0000   0b0000 0b0000
      output_low(PIN_B1);     // 0b0000 0b0111   0b0010 0b0010
      output_high(PIN_B2);    // 0b0111 0b0000   0b0000 0b0000
      output_low(PIN_B2);     // 0b0000 0b0111   0b0001 0b0001
      output_high(PIN_B3);    // 0b0111 0b0000   0b0000 0b0000
   }
}


I still get the same output as before from MPLAB SIM.
Is there something else I have to do?
What am I missing when the hardware behaves as I expect?

Mike
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Feb 27, 2017 8:36 pm     Reply with quote

There is a bug with MPSIM and the 18F26K22. Read the yellow post by
dan1138 on the Microchip forum:
http://www.microchip.com/forums/m603514.aspx
He says you have to set ADCON1 to 0x0F to fix it. I did that. It works.
Try it.
Code:
// Port B Test
#include <18F26K22.h>
#fuses ECH,NOWDT,NOPROTECT,NOLVP,NOPLLEN
#use delay(clock=4000000)

#byte ADCON1 = getenv("SFR:ADCON1")

void main()
{

ADCON1 = 0x0F;

   while (TRUE)               // PIC18F26K22     PIC18F46k22
   {                          // LATB   PORTB    LATB   PORTB
      output_low(PIN_B3);     // 0b0000 0b0111   0b1000 0b1000
      output_high(PIN_B0);    // 0b0111 0b0000   0b0000 0b0000
      output_low(PIN_B0);     // 0b0000 0b0111   0b0100 0b0100
      output_high(PIN_B1);    // 0b0111 0b0000   0b0000 0b0000
      output_low(PIN_B1);     // 0b0000 0b0111   0b0010 0b0010
      output_high(PIN_B2);    // 0b0111 0b0000   0b0000 0b0000
      output_low(PIN_B2);     // 0b0000 0b0111   0b0001 0b0001
      output_high(PIN_B3);    // 0b0111 0b0000   0b0000 0b0000
   }
}
Mike Walne



Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK

View user's profile Send private message

PostPosted: Tue Feb 28, 2017 3:46 am     Reply with quote

Yes, it works OK for me now.

I've just tried stepping through my original code in the MPLAB debugger. It operates correctly.
I suppose that's because MPLAB is reading the registers in the chip rather than simulating.

I'll add solved to the title, and hope it helps someone else.
I'm relieved to know that I wasn't losing my marbles.

I would probably have never found the fix on my own.
Thank you PCM.

Mike

I'm new to the *K22 chips, and was alerted to the problem when I adapted the CCS stepper motor code.
I was uncertain, for some time, whether the problem was CCS or MPLAB.
It seemed odd that Microchip could get something so basic so badly wrong.
Really pleased to have it solved, as I was wary of continuing to trust MPLAB.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group