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

Issue with programing PIC18F67K22 past memory location 14000

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



Joined: 24 Jun 2005
Posts: 206

View user's profile Send private message Send e-mail

Issue with programing PIC18F67K22 past memory location 14000
PostPosted: Thu Oct 01, 2020 6:57 am     Reply with quote

I am having some issues programing a PIC18F67K22 using a PICKIT3.
I know this is not going to be a issue with CCS (I hope not anyway, but with issues I have had so far with this project anything can happen) but I am not getting anywhere with the microchip forum.

Programing will work fine until the program grows and passes memory location 14000, at which point I will get the following error.

"Address: 14001 Expected Value: b3 Received Value: 0"

Removing a function from the program (can be any function) until the program is smaller the 14000 and it will program fine.

I have tried:

1. MPLABX 5.20, 5.35 and 3.40.

2. PIC at 3.3v and 5V, both from external power and from the PICKIT.

3. 2 Different PICs (Both PIC18F67K22).

Only thing I can't test is a different PICKIT as I only have one.


I am guessing hardware is ok as it will program fine when the program is small.

Nothing else is currently connected to the board.


Is there anything I can try to get around this? What is so special about memory location 14000 anyway. I can't see anything in the datasheet that matches up to this boundary.


Thanks
Ttelmah



Joined: 11 Mar 2010
Posts: 19553

View user's profile Send private message

PostPosted: Thu Oct 01, 2020 10:25 am     Reply with quote

Could be a fault with the programmer code. There have
been quite a few versions of the Pickit3 code that fail like this at different
addresses. You really need to ask on the MPLAB forums.
Markdem



Joined: 24 Jun 2005
Posts: 206

View user's profile Send private message Send e-mail

PostPosted: Thu Oct 01, 2020 4:41 pm     Reply with quote

Thanks Ttelmah,

I am starting to think it is a programmer issue. I can program a DSPIC (uses a diffrent PICKIT3 firmware) to 98% without a issue. It is just the 67K22 that has issues.

Would anyone have a 67K22 with a PICKIT3 on the bench they could program with my HEX?

I was just hoping someone else here had this one before.
temtronic



Joined: 01 Jul 2010
Posts: 9247
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Oct 02, 2020 4:29 am     Reply with quote

off the top of my head, waiting for coffee.....

There is another test that could be done.

Cut code to just specifically put something at that memory location.
Real small program, like org #14000,do while forever loop. or #ROM ?

There might be a hardware issue (bad PIC ?) or maybe the programmer is setup to not burn past 14000 ??
Ttelmah



Joined: 11 Mar 2010
Posts: 19553

View user's profile Send private message

PostPosted: Fri Oct 02, 2020 6:29 am     Reply with quote

The program memory range in MPLAB, is normally set to 'auto'. Possibly this
has the wrong values. Worth trying setting this to manual, and selecting a
larger range and see what happens:

<https://microchipdeveloper.com/pickit3:select-memory-to-program>
Markdem



Joined: 24 Jun 2005
Posts: 206

View user's profile Send private message Send e-mail

PostPosted: Sat Oct 03, 2020 3:10 am     Reply with quote

Just to complete this in case someone run across it in the future.

I borrowed another PICKIT3 and it seemed to fix the issue. I have no idea why the PICKIT would be doing something stupid like this, but judging from the Microchip forums I think something major was changed after MPLABX 3.35. Lots of "odd" issues going on.

Ttelmah - I thought of that too but I restored the programming setting to default that changed the ranges to auto. In addition, programming a PIC24 works fine past 14000. (Different hex file). Two users on the Microchip site used my hex file without an issue so it can't be a code issue.
I also used different computers to test.

This whole project is a disaster.
So far I have had -
Documentation from vendor on a sensor I am using was wrong - wasted 2 days.
The stupid const string issue I posted about.
Ethernet switch that stopped passing traffic on the port the PIC was connected to for no reason. Wasted a day on that one.
Vendor sending wrong part - no way to tell it was the wrong part visually. (Different vendor from the datasheet issue).
And now this.. On the plus side, project is nearly done.

Thanks
Ttelmah



Joined: 11 Mar 2010
Posts: 19553

View user's profile Send private message

PostPosted: Sat Oct 03, 2020 3:26 am     Reply with quote

I'd be checking the firmware revision in the unit you borrowed versus
your own unit. There are a lot of cases where particular chips have issues
with particular firmware versions. Funnily enough, there was one here
recently, with the CCS programmer, and a firmware problem.

I was suggesting setting it to manual, and explicitly over-ridding the auto
setting. The point is that a particular range of addresses working in another
chip, proves nothing about what the code will do with a different chip. There
are several different programming algorithms in the firmware, used for
different chip families and the settings for each chip are also specific to
the chip.
Markdem



Joined: 24 Jun 2005
Posts: 206

View user's profile Send private message Send e-mail

PostPosted: Tue Oct 06, 2020 1:44 am     Reply with quote

Ok, after half a day or trial and error (the bug only shows up now and again) I have found out what is going on.
In case anyone else comes across this one, here is what I have found.

1. PIC fails to program after 14000.
2. Open up Microchip IPE.
3. Erase the chip. I know MPLAB should do this prior to programing, but here we are...
4. Perform a "Blank Check". If it fails, GOTO 3.
5. Programing will now work for a random amount of time. When it fails again, GOTO 2.

I have no idea why this is going on. It happens on both of the PICKIT3 units I have, both with same firmware (also no idea why the borrowed unit worked the first few times, however I might of actually erased the chip prior to testing).

I have found I will normally get about 5-15 programs before it will fail again.

Hopeful this helps someone in the future..
Ttelmah



Joined: 11 Mar 2010
Posts: 19553

View user's profile Send private message

PostPosted: Tue Oct 06, 2020 1:55 am     Reply with quote

Funny thing is when I was searching for your original problem, I can across
a thread where somebody was saying basically the same thing. Typically,
I can't now find it.
Looks as if there is an 'issue' somewhere in the PicKit firmware, so
it is not erasing everything as it should... Sad

Key thing is that when programming, bits can only be set to '0', never
'1'. The only way a bit can get to '1' is by an erase. So it's perfectly
possible to have a code section that will write perfectly OK, if it only sets
bits to '0', compared to what is already there. Sounds as if the code
you tried with the second programmer, must have just happened to not
be trying to set any bit to '1' that time!...
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