| 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: 19966
 
 
 
			    
 
 | 
			
				|  |  
				|  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: 9589
 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: 19966
 
 
 
			    
 
 | 
			
				|  |  
				|  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: 19966
 
 
 
			    
 
 | 
			
				|  |  
				|  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: 19966
 
 
 
			    
 
 | 
			
				|  |  
				|  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!...
 |  | 
	
		|  | 
	
		|  |