View previous topic :: View next topic |
Author |
Message |
Markdem
Joined: 24 Jun 2005 Posts: 206
|
Issue with programing PIC18F67K22 past memory location 14000 |
Posted: Thu Oct 01, 2020 6:57 am |
|
|
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: 19510
|
|
Posted: Thu Oct 01, 2020 10:25 am |
|
|
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
|
|
Posted: Thu Oct 01, 2020 4:41 pm |
|
|
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: 9226 Location: Greensville,Ontario
|
|
Posted: Fri Oct 02, 2020 4:29 am |
|
|
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: 19510
|
|
Posted: Fri Oct 02, 2020 6:29 am |
|
|
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
|
|
Posted: Sat Oct 03, 2020 3:10 am |
|
|
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: 19510
|
|
Posted: Sat Oct 03, 2020 3:26 am |
|
|
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
|
|
Posted: Tue Oct 06, 2020 1:44 am |
|
|
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: 19510
|
|
Posted: Tue Oct 06, 2020 1:55 am |
|
|
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...
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!... |
|
|
|