Jump to content
Sign in to follow this  
NoFuture

Write Protection Enabled On My Behalf!

Recommended Posts

I don't really know precisely what happened but now, I cant reprogram my three PIC16F628A chips.

 

I think it has something to do with SourceBoost (or me :( ) because all 3 became write/read protected right after I programmed them using the .HEX file Sourceboost produced. They were working correctly when I was using .HEX files from MPLab or MikroC.

 

I am using a JDM (serial) programmer and ic-prog and I am sure that the CP fuse was not enabled because I always check all fuses in ic-prog just to make sure. The only problem is that it took me a while to figure out where the fuses were in the Sourceboost IDE, so they were not set to my specifications (but CP is always OFF anyways) at the time of build. I was not a big deal to me because ic-prog would let me set the fuses anyway. I even tried on other computers and with Winpic...

 

Anybody knows why ??

Is there a way to erase the whole chip ???

 

Thanks

Share this post


Link to post
Share on other sites
I don't really know precisely what happened but now, I cant reprogram my three PIC16F628A chips.

 

I think it has something to do with SourceBoost (or me :( ) because all 3 became write/read protected right after I programmed them using the .HEX file Sourceboost produced. They were working correctly when I was using .HEX files from MPLab or MikroC.

 

I am using a JDM (serial) programmer and ic-prog and I am sure that the CP fuse was not enabled because I always check all fuses in ic-prog just to make sure. The only problem is that it took me a while to figure out where the fuses were in the Sourceboost IDE, so they were not set to my specifications (but CP is always OFF anyways) at the time of build. I was not a big deal to me because ic-prog would let me set the fuses anyway. I even tried on other computers and with Winpic...

 

Anybody knows why ??

Is there a way to erase the whole chip ???

 

Thanks

 

 

All of the PICs have a bulk erase or chip erase, you have to find out how your particullar programmer impliments this.

 

Try a config erase first.

Share this post


Link to post
Share on other sites

I tried bulk erasing the chip but it did not work.

I think I will juste blame it on my cheap programmer (15USD on ebay) and build myself another one when I get the time and money. In the meantime, I will just wait for my other chips to arrive.

 

Thanks anyway

Share this post


Link to post
Share on other sites
I tried bulk erasing the chip but it did not work.

I think I will juste blame it on my cheap programmer (15USD on ebay) and build myself another one when I get the time and money. In the meantime, I will just wait for my other chips to arrive.

 

Thanks anyway

 

 

mhh could be that your programmer only supports low voltage programming mode(better referred to as single supply programming in PIC18 speak)

in which case if the LVP bit in config gets overwritten (cant remember offhand if set or clear) then you cant do much without a 12.5 volt programming. NB PIC18 only allow LVP to be overwriten in 12.5V mode.

 

If you have a friend with a different programmer try to get them to bulk erase for you OR try and get 12.5V to the mclr/Vpp pin during programming

Share this post


Link to post
Share on other sites

I checked the Mclr pin with a multimeter and it goes up to 13v.

Still can't figure out what the problem is. I'm starting to think that I got a bad batch of chips. I one week I'll be able to try with another programmer so we will see.

Share this post


Link to post
Share on other sites
I checked the Mclr pin with a multimeter and it goes up to 13v.

Still can't figure out what the problem is. I'm starting to think that I got a bad batch of chips. I one week I'll be able to try with another programmer so we will see.

 

First what compiler do you use? SourceBoost includes several compilers and you didn't specify which one you use. Than you need to check if the .HEX file you used to program your targets has the configuration word coded and if it does what value is used.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

I used BoostC. ic-prog told me that there was no configuration word and then offered me to set my own within the program. The programming worked and then, I tried the chip on the beadboard and it did what it was supposed to do. When I tried to reprogram it with a corrected version of the program i'm working on, ic-prog (and other programming software) would act like there was no chip plugged in the programmer.

 

Anyway, I'm starting to think I'm the one who screwed up by taking for granted that the program would do everything for me.

Share this post


Link to post
Share on other sites
I used BoostC. ic-prog told me that there was no configuration word and then offered me to set my own within the program. The programming worked and then, I tried the chip on the beadboard and it did what it was supposed to do. When I tried to reprogram it with a corrected version of the program i'm working on, ic-prog (and other programming software) would act like there was no chip plugged in the programmer.

 

Anyway, I'm starting to think I'm the one who screwed up by taking for granted that the program would do everything for me.

 

If you use BoostC you can specify configuration word in your code using pragma DATA. This will ensure that you use the desired configuration in all post-compile steps. Here is a sample configuration that shows how to use pragma DATA:

 

#pragma DATA 0x2007, _HS_OSC & _WDT_OFF

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Here it is...

 

#pragma DATA _CONFIG, _PWRTE_ON & _WDT_OFF & _CP_OFF

 

I see that you are supposed to have hex code right after the DATA, is it possible that BoostC thought the "_CONFIG_" was the config word ????

 

If DATA is for the config word, then why do you add _WDT_OFF and stuff after ???

Share this post


Link to post
Share on other sites

Finally figured it out...

 

The culprit was my JDM programmer. With new pics with internal oscillators. The programmer would raise VDD and VPP at the same time, starting the program that was just encoded in the chip, the program counter would increase, rendering programming impossible. All that was needed was to modify the circuit so that the programmer would have control when to raise VDD or VPP.

 

Here is the solution:

 

http://users.tpg.com.au/btkelly/jdm_b.htm

 

Very simple and cheap...

 

Thanks for your help guys...

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...