PIC18F2539 Chips Can be Bulk Erased to become PIC18F252 types

[martys]

There's a shortage of new parts, can I repurpose 18Fxx39 (18F2539/18F4539 types)to make them PIC18F45x types simply by using a bulk chip erase?

The 18Fxx39 chips are preprogrammed by Microchip with a kernel for induction motor drive which is useless to me.


I can do a bulk erase, but can I completely erase this custom code kernel and then get to use the  18F45x resulting chip in current projects. 

Is this possible?

[SiliconWizard]

Judging from the datasheet, the "motor control kernel" is not in the main code Flash, which is still available to the user.

The PIC18F2539 and PIC18F4539 each have a total of
24 Kbytes, or 12K of single word instructions of FLASH
memory,  from  addresses  0000h  to  5FFFh.  The  next
8 Kbytes beyond this space (from 6000h to 7FFFh) are
reserved  for  the  Motor  Control  kernel;  accessing
locations in this range will return random information.

So I'm pretty sure you can ignore this feature and use the parts as you would any other PIC MCU.
No whether they'd be a direct replacement for PIC18F45x, without any code modification, I do no know. You'll need to read the datasheet.

[martys]

What datasheet?  I've already read carefully the 18Fxx39 and it does mention this chip is otherwise compatible with 18F45x types, but there is no mention that it can be resurrected to become a 18F45X. The 18Fxx39 datasheet does mention that WDT is always hardware turned on, and the CONFIG bits that affect operation for motor control and protected code areas are not to be changed.

[wraper]

The first thing you should decide if differences between the chips have any meaning for you. If those differences are not used by your code/hardware, then you can just use them as drop-in replacements.

[martys]

I have just posted the datasheet differences above as an attachment.

Of course, the difference I am concerned with is whether some ghost induction motor kernel code will always be asserted, even after a bulk erase(Like a read-only PROM). The induction kernel is, of course, read and write protected by CONFIG settings.

Otherwise, the xx39 is a fairly powerful MCU with a lot of older but useful features that make this chip an attractive MCU.

I can buy from a guy at a local HamFest, more than a dozen ea. and new, of both 28-pin and 40-pin xx39 varieties for a nickle a piece.

[amyk]

Preprogrammed variants may be ones that have failed tests of other peripherals/configurations not used by the preprogrammed code, so that is one thing to watch out for.

[DavidAlfa]

Checking the datasheet, it seems the kernel is disabled by default (You need to call ProMPT_Init in your program).
Otherwise, all peripherals and memory should be available to the user.
So if you wipe them, it'll still identify as a 2839, but you could use it pretty much like you want.

[martys]

Many Thanks DavidAlfa, of course this is the answer I hoped to get.

As I understand this, I can just tell my compiler and chip programmer that the chip is really a 18F25x.

That means I can just take a virgin PIC18F2539 and just treat it as it is really a 18F252 and bulk erase, compile and burn hex code into it, always specifying the chip is a 18F252?

[DavidAlfa]

Might work or not, but the programmer will definitely fail if you do so because it'll check the device id.
You cannot change the Pic model by erasing it.
Why do that? Just specify the correct chip.
Using timer1, spi, io ports will be the same.
The code changes will be minimal between them.
You can try loading a 252x hex file and program it, but you must match the Pic model in the programmer settings.
Compare memory mapping anc config words in both datasheets. If the same, it's likely to work.

[Ian.M]

It looks like the motor control kernel is hardware locked code protected as the reserved bits in CONFIG5L, CONFIG6L, & CONFIG7L, are tagged as "Note 1: Unimplemented, but reserved; maintain this bit set", which would normally be unprotected, so even if you hack a programmer device database to erase outside the user program memory and alias the device ID, you wont get a usable normal  PIC18F45x, unless your application expects the top page of FLASH to be fully protected.

I also expect erasing the extra page wont be easy if even possible - fully protected pages can only be erased by whole device bulk erase, and that's done on-chip and is not going to touch the reserved page.

[martys]

As I understand it now, only 24K of the 32K flash code memory is able to be modified. Code memory block 4 is not erased by even a chip bulk erase (although the xx39 programming spec says that the entire chip can be erased by a bulk erase). I can select the programmer to program the chip as a 18F452, for instance, and it would attempt to bulk erase the entire memory space and I have a programmer that can be told to ignore the device id.

But as before mentioned, the induction motor code is inactive unless invoked by software. In that case, I should be able to use the peripherals (such as Timer1 and PWM1 and PWM2) but the compiler programming my code must not try create code to write to the last 8K of program memory.

In other words, the peripherals used by the induction motor kernel would not be controlled by the kernel and this allows me to use them as I wish?

Would it also be  that by default a compiler would start to load my code at the start of program memory, after the boot block, and not touch the top 8K unless I had code >24K?

Of course, by trial and error I can just write code to  use the reserved peripherals and see if it works.

I have examined the enable bytes used for table writes to select each block of flash for bulk erase for the xx39 and x252 and they match, except the x252 has one more byte to enable bulk erase for the top 8k memory block area of the xx39.

[martys]

Solved

By setting my programmer to type '252(with a '2539 inserted) and first erasing block four(the 8k embedded kernel) I was then able to completely Bulk Erase everything. I then made a test that byte-banged 8-bytes into the top of 8K top block four and verified it was there with a memory dump and all other locations were from boot block to top 8K of Pgm Flash were 0xFF.

I then burned a 113K source file of random assorted clips of my code that did absolute nonsense but showed use of PWM, Timers, etc and when compiled including CONFIGs for '252, showed it  used 98% of 32K pgm Flash and it all verified perfectly and even blinked LEDs. Success!

[Ian.M]

After you've done that, do the protection bits for the fourth page work as expected for a PIC18F252?

[Psi]

and now that the secret is out, they're all sold out in ...3 ... 2... 1...

[SiliconWizard]

and now that the secret is out, they're all sold out in ...3 ... 2... 1...

 

[martys]

I've bought them all, after all, at that price, what did I have to loose?

Ian.M: I've not tried to re-protect block 4, but why should it not work, because everything else seems to work perfectly.

The 18Fxx39 seems to be no more than a 18F252 wearing a mask, and for most of my projects, I am not concerned about protecting code.
 
I realize at this moment, I might have overthought the  problem.

I might only have had to bulk erase the 18Fxx39 with the programmer doing a chip erase while set for a18F252.

I haven't tried this, the programmer might prevent a bulk chip erase operation for the entire xx39, or more likely, just allowing the lower 24K area to be valid flash pgm. space, and the compiler would certainly agree to this limitation.

The 18Fxx39 might only need to be bulk erased to accomplish the name change. The induction motor code might be protected from chip erase by rules of use only, that is, the user is told to only to add code without ever doing a total bulk erase, just erasing/burning  flash blocks other than block four.

[DavidAlfa]

Even if you bulk erase it, it will still identify as a xx39 part.
The programmer has a database defining the flash sizes and config words based on the part ID.
So you'll probably need to keep forcing it as a 252.
The final result is the same, though.

[martys]

Thanks DavidAlfa,


Somehow I will have to learn to live with this humiliation.

[amyk]

Even if you bulk erase it, it will still identify as a xx39 part.
The programmer has a database defining the flash sizes and config words based on the part ID.
So you'll probably need to keep forcing it as a 252.
The final result is the same, though.

I would not be surprised if there's a way to change the device ID too... I know that's possible with AVRs and there was some discussion here a while ago about it (undocumented programming commands.)

[DavidAlfa]

Maybe, but you need these commands...