Firmware won't start after power off/on

asmboy · Joined: 20 Nov 2007 Posts: 2128 Location: albany ny

re hex files

The file should NOT be different than what was programmed.

The "extra " you read back
is simply the WHOLE prog mem dump including unused space at the end
of what your code occupies.

Seeing a whole lot of hex FF in the data fields merely says you are into ERASED, not reprogrammed data areas -

see

http://www.keil.com/support/docs/1584/

for an explanation of how to interpret the file content.

The area you need to focus on is the area that is referenced by the file you programmed from ( as created by the compiler).

lucky 4 U - it comes first in a readback dump too - or OUGHT to

the exception will be the FUSES area

but figuring out wher3 it is in your source file should help locate it
in the readback , as

The FUSES come last in the hex file SOURCE
and make themselves known by
being at a radically different address than the program code.

Look for that address in your read back file.

if ANY of the code in the area demarcated for the program and fuses is CHANGED - thats a major problem.

ALSO

ERASE one of the "bad" chips ( that cant run said prog again)
'but don't reprogram -
instead- do a read back of IT

You BETTER have a lot of FFFF in that readback.

But either way - the PROGRAMMED portion of memory and FUSES
should NOT have changed by running the pic program !!!

With NOLVP set and NO prog volts on MCLR pin
you should not be able to alter prog mem at all!!

wiseacre · Joined: 14 Jun 2012 Posts: 9

The only difference in the program memory area is 3 locations that I didn't use show up at FFFF...not too concerning (unless I'm not understanding correctly). The other difference IS in the FUSES area. I compared the fuses to the file I originally programmed and to my debug version that has #device ICD=TRUE included. It is the same as the debug version...so somehow that is getting switched.

When I erase the chip, all I get is FFFF (which is good at least...)

asmboy · Joined: 20 Nov 2007 Posts: 2128 Location: albany ny

i think a change in the #fuses
might explain what is happening

but the HOW of it puzzles me too.....

asmboy · Joined: 20 Nov 2007 Posts: 2128 Location: albany ny

perhaps you might get RID of all ICD references and USEAGE
and the debugger overhead too

BTW: i am assuming that you DONT do any actual control via MCLR
since the PUT fuse with an internal RC clock - is going to protect from a squishy startup as it is.

then try MY fuses instead, copy paste -
as listed below on a FRESH , never abused PIC

what happens then ??

wiseacre · Joined: 14 Jun 2012 Posts: 9

asmboy · Joined: 20 Nov 2007 Posts: 2128 Location: albany ny

i am puzzled

BTW:

what is this construction expected to actually transmit ?

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

asmboy -
He's adding an index to his pointer, and then casting the sum to a char
ptr, and then fetching the char that it points to. I would not have done
it this way. But that's irrelevant to his problem.

Regarding the problem -
You are getting the DEBUG fuse mysteriously set somehow in your
programmed PIC ?
1. Are you using a bootloader, and didn't tell us ?
2. In MPLAB, there is a very clear choice of how you want to program
the PIC. There is a little drop-down box on the menu bar at the top,
where you select Debug or Release mode. You can also go to either the
Debugger or the Programmer menu to do the same thing. I don't know if
CCSload or whatever you are using has a way to choose "Debug"
or "Standalone" (release) mode. I wonder if you are accidently
programming the PIC in Debug mode.

wiseacre · Joined: 14 Jun 2012 Posts: 9

SHE is adding an index to HER pointer...and actually didn't choose that scheme but was building off code that was handed to her.

Either way, I fixed my problem. No idea how since all I did was create a new project and copy it piece by piece over, checking each time if I could still restart the program after disconnecting and reconnecting the power. I didn't change the code at all. So the reason this was happening may forever remain a mystery, but at least I have a program that can work even after a power outage. Thank you all for you input and help.

asmboy · Joined: 20 Nov 2007 Posts: 2128 Location: albany ny

Very good.
I admit that I would have never thought of your solution,
as all my programing is done by command line compiling
the source code which I edit and maintain using a familiar, C oriented text editor. (MultiEdit, which I have customized to suit myself over time anyway).

After trying MPLAB and CCS project programs - I found I was still much
happier with simpler, LESS focused tools.

AS they say, "taste is a matter of taste".