Programming Problem

[matc]

My guess? You're reading in the wrong hex file.

 

[kchriste]

No, he has the correct HEX file. I can load it into MPLAB SIM and it'll set all bits on PORTB to 0xFF.
2FF9 disassembles as GOTO 0x7F9

:02000000F92FD6
:0E0FF200FF3083120313860083168601FF2F43
:00000001FF

If you scroll down and look at the address 0x7F9 you'll see more data which is the actual program location. C compilers sometimes create strange assembly code.

You should also have pullups on the unused pins or program them as outputs

 

[Nigel Goodwin]

You should also have pullups on the unused pins or program them as outputs

It makes no difference whatsoever, it's a fallacy based on that requirement for CMOS logic gates.

As he doesn't appear to be setting the fuses, it can't ever work - unless he's wanting to use the default fuse settings?.

 

[Pommie]

Try the following,

#include<pic.h>
#include<htc.h>

__CONFIG(0x3f79);

void main()
{ 
    PORTB = 0xFF; 
    TRISB = 0x00;
    while(1);
}

Or,

#include<pic.h>
#include<htc.h>

__CONFIG(0x3f79);

void delay(void);

void main()
{ 
    TRISB = 0x00;
    while(1){
    PORTB = 0xFF;
        delay();
        PORTB = 0x00;
        delay();
    }
}

void delay(void){
int i;
    for(i=0;i<15000;i++);
}

Let us know what it does.

Mike.

 

[eng1]

i have set mine to:
Oscillator = HS
Watchdog timer = off
Power-up timer = on
Brownout detect = off
Low voltage program = disable
Flash program write = write protection off
Data EE code protect = off
Code protect = off
HEX: 3F32

4Mhz crystal with 2 x 22pf capacitors

As pointed out, 4 MHz crytals use 'XT' for oscillator configuration instead of 'HS', or the oscillator might not start (from my experience). Added configuration labels for Hi-Tech PICC with your setup.

#include <htc.h>

__CONFIG ( XT & WDTDIS & PWRTEN & BORDIS & LVPDIS & UNPROTECT ); 


void main(){
    
    PORTB = 0;                    // clear PORTB
    TRISB = 0xFE;                 // RB0 is output
    
    RB0 = 1;                      // set RB0
    
    while(1);                     // loop forever
    
}

The program simply turns the LED on.
Hope this helps.

 

[DMW]

Waw thankyou!!

i tried the code:

#include<pic.h>
#include<htc.h>

__CONFIG(0x3f79);

void delay(void);

void main()
{
TRISB = 0x00;
while(1){
PORTB = 0xFF;
delay();
PORTB = 0x00;
delay();
}
}

void delay(void){
int i;
for(i=0;i<15000;i++);
}

and it worked!, thankyou,

I did try the XT, so im not sure what i was doing wrong, although this time i did use a pull-up resistor and the Masterclear grounded while the chip was inserted.

Anyway thanks for all the help guys this is a great community, i dont think ill try much more before my ZIF socket comes- i think the IC is starting to metal fatigue.

Thanks, superb!



edit:

btw what does
#include<htc.h>
do? that might of been whats missing.

 

[DMW]

ok after abit of testing it turns out the error was the configuration bits, as i dident know how to set them in the code i was setting them via MPLAB and in WINPIC800 under the configuration tab - but apparently that dident work and they had to be coded in, strangely

Thanks for patience and help guys,

 

[eng1]

btw what does
#include<htc.h>
do? that might of been whats missing.

This header makes your code more portable. You don't need to include <pic.h>, because the header file htc.h determines which compiler is running and include the specific header file (pic.h, pic18.h, etc.)

As you've realized, the configuration was the issue. If you use config labels as I did in the above program, your code will be more readable by others.

 

[Nigel Goodwin]

ok after abit of testing it turns out the error was the configuration bits

Like I said in two posts above!.

Once you posted the HEX file it was obvious you weren't setting the config fuses in your source code.

 

[DMW]

im sorry, no one mentioned how to set the bits in the code, untill pommie and eng1, plus you could configure manually the bits in MPLAB and in WINPIC800 - which i was doing correctly - and so assumed than if i changed them in the window they would change in the program - or whats the point in the ability to change them in the window?

Anyway thanks guys, currently wiring up an LCD to test on this

 

[Pommie]

Glad to hear it's working. It's a good moment when that first LED flashes.

I agree with Eng1 in regard to the use of labels in the config. Just copy his config line. I just copied the hex from MPLAB's config window as I was being a bit lazy.

Good luck with the LCD, I assume it's a character LCD and not a graphic one. Keep us posted.

Mike.

 

[DMW]

I cant say how relived i was, never saw a more beautiful LED blink in my life lol

Yes its just a 16x2 character LCD [for now ], just doing the code for it thanks

I was about to look this up, but seeing as im posting here anyway, if i want to set a specific port as an 1 or 0 without changing any of the other ports within a register output, how is it done

example, i want to change B3 from 0 to 1 say without redefining the entire register for B,
can you do it like arrays?
PORTB[3] = 1?
because that's not working for me :S

 

[eng1]

I was about to look this up, but seeing as im posting here anyway, if i want to set a specific port as an 1 or 0 without changing any of the other ports within a register output, how is it done

example, i want to change B3 from 0 to 1 say without redefining the entire register for B,
can you do it like arrays?
PORTB[3] = 1?
because that's not working for me :S

You should be able to figure it out from my example above Be aware that the sintax for clearing/setting bits of a register or port is compiler specific.

 

[Pommie]

I'm afraid I'm not that well versed in HiTech C but I think it is RB#.

I.E.

	RB3 = 0; // set bit 3 of port b low

Mike.

 

[DMW]

Really sorry about that, i did look over, but ive got lot in my head right now

thanks yes RB# works

sorry and thanks

 

[Pommie]

No need to be sorry, that is why this forum is here.

Mike.

 

[kchriste]

You should also have pullups on the unused pins or program them as outputs

It makes no difference whatsoever, it's a fallacy based on that requirement for CMOS logic gates.

You mean the PIC won't draw extra current when all the input pins are floating at around 1/2 Vdd? Always thought that it would. Maybe I'll experiment with this later.

 

[Nigel Goodwin]

You mean the PIC won't draw extra current when all the input pins are floating at around 1/2 Vdd? Always thought that it would. Maybe I'll experiment with this later.

Check the PICList archives - there was an EXTENSIVE thread on this a LONGGGGG time ago

The reason it happens on CMOS gates is that it can bias the chip into an analogue region, which is why you can use some CMOS gates as amplifiers.

 

[kchriste]

I just tried it out on portB of a 18F4620. I set portB to input mode, connected all 8 pins to a pot wired to vary the voltage between 0 & 5V. I first programmed the PIC to just loop doing nothing while using the internal osc at 1Mhz. Idle current was 1.5ma when the pot was at 0 or 5V. When the pot outputted a voltage of around 2V, current peaked at around 3.5ma. With the PIC programmed to just poll portB (Read portB into W and loop) the current would peak at around 4ma. I also tried this at 32Mhz using the PLL. The current increase was about double (19ma idle vs 23ma = 4ma extra for "floating" inputs). So only a 2-4ma punishment for letting all 8 pins on a port float. Nowhere near what you'd see with a standard CMOS gate.
Ok, you've convinced me.

 

[Nigel Goodwin]

I'm pleased to see you put "floating" in quotes, because (as you're obviously aware) the pins weren't 'floating' at all, but being artificially forced to a non-logic state.