You Cannot Post That I Already Read About How Dare You Post It Again
fanievwyk
Starting Member
- Total Posts : 34
- Reward points : 0
- Joined: 2007/01/17 15:52:11
- Location: 0
- Status: offline
Microchip`s 12F675 Bugger Up
I have used hundreds and hundreds of 12F675's in the past. The total count would be in the thousands of these.
Now when you program these you get a message 'You cannot program the 12F675 if the internal osc and the int MCLR is selected'. Please don't comment on this, the argument has been discussed before with some moronic reasons given, I don't want to hear them again.
To now it was only a message.
I tried to program these pics today in two new app's and it programs the first time, then the second time it says it does not see a target device. It did the same with all these 12F675's. Each time I had to replace the 12F675 and put a new one in or it will not program.
This is a function of MPLAB - these pics program repeatedly with the previous versions of MPLab. So if you use MPLab 8.5 then some of your pics are now OTP's.
Take note !
I have a hundred or so of these on the shelf, I'll be returning them to the supplier. I refuse to work like we did in 15 years ago's technology. The part number says it's a flash device and it can be reprogrammed - this is misleading, the devices also does not clear with MPLab 8.5. I've also complained about the nagging popups before but the authors of MPLab for some reason does not feel it is an irritating enough feature.
The 12F675 is off my list of usable components.
Personally I think it's a pathetic way to tell your customers to stop using a component :-(
Regards
Fanie
FAZE
Stick to Pic !
P Lameijn
Super Member
- Total Posts : 2003
- Reward points : 0
- Joined: 2004/01/22 18:30:23
- Location: The Netherlands
- Status: offline
RE: Microchip`s 12F675 Bugger Up 2010/06/08 09:38:38 (permalink)
If you ignore the given warnings, you'll have to bear the consequenses.
You cannot blame the chip for that...
The chips can easily be 'reborn' with PicKit2...
fanievwyk
Starting Member
- Total Posts : 34
- Reward points : 0
- Joined: 2007/01/17 15:52:11
- Location: 0
- Status: offline
RE: Microchip`s 12F675 Bugger Up 2010/06/09 08:32:18 (permalink)
If you ignore the given warnings, you'll have to bear the consequenses.
You mean I had to bear the consequences in all the years and years I've been using them ?
You cannot blame the chip for that...
Read my post again. It is not the pic that is the problem, it is MPLab ! The pics are great, they work fine, they are not the problem.
The chips can easily be 'reborn' with PicKit2...
You mean I should downgrade for the pic to work ? I have two pickit2's. The ICD's I have can program any and all pics why should I downgrade ?
The problem is NOT the pics or the programmer(s). The problem is with MPLab. MPLab has always had a bad streak in trying to force users into using pics they way they 'see fit', and not what the pics can do and what they are actually designed for.
The data sheets, which has been accurate for as far as I can tell doesn't say anywhere you cannot use the pics that way, the thousands I programmed before is living proof. If the authors of MPLab get their programming procedure right there would be a lot less problems, instead they insist on sitting on their high selfrightious horse. The Vpp should go high AFTER the V+ is applied, not before.
Look through the thread and you will see how many people have the same problem. I myself have been complaining about the same issue for how many years already. For me to be able to use these pics again I have to instal an earlier version of MPLab, then if I want to work with any of the new pics I have to reinstall the later version.
How much more stupid do you want ?
post edited by fanievwyk - 2010/06/09 10:58:00
Regards
Fanie
FAZE
Stick to Pic !
Antipodean
Super Member
- Total Posts : 2340
- Reward points : 0
- Joined: 2008/12/09 10:19:08
- Location: Didcot, United Kingdom
- Status: offline
RE: Microchip`s 12F675 Bugger Up 2010/06/09 08:48:07 (permalink)
ORIGINAL: fanievwykIf you ignore the given warnings, you'll have to bear the consequenses.
You mean I had to bear the consequences in all the years and years I've been using them ?You cannot blame the chip for that...
Read my post again. It is not the pic that is the problem, it is MPLab ! The pics are great, they work fine, they are not the problem.The chips can easily be 'reborn' with PicKit2...
You mean I should downgrade for the pic to work ? I have two pickit2's. The ICD's I have can program any and all pics why should I downgrade ?The problem is NOT the pics or the programmer(s). The problem is with MPLab. MPLab has always had a bad streak in trying to force users into using pics they way they 'see fit', and not what the pics can do and what they are actually designed for.
The data sheets, which has been accurate for as far as I can tell doesn't say anywhere you cannot use the pics that way, the thousands I programmed before is living proof. If the authors of MPLab get their programming procedure right there would be a lot less problems, instead they insist on sitting on their high selfrightious horse. The Vpp should go high AFTER the V+ is applied, not before.
Look through the thread and you will see how many people have the same problem. I myself have been complaining about the same issue for how many years already. For me to be able to use these pics again I have to instal an earlier version of MPLab, then if I want to work with any of the new pics I have to reinstall the later version.
How much more stupid do you want ?
So why are you grumbling here?
Have you started a support ticket over this issue?
In view of the various problems that have been noted in this forum with MPLAB 8.50 why don't you regress to a version that does program them properly?
Do not use my alias in your message body when replying, your message will disappear ...
Alan
fanievwyk
Starting Member
- Total Posts : 34
- Reward points : 0
- Joined: 2007/01/17 15:52:11
- Location: 0
- Status: offline
RE: Microchip`s 12F675 Bugger Up 2010/06/09 09:27:22 (permalink)
So why are you grumbling here?
I'm hoping that someone that actually uses pics can see there is a problem and correct it. If no one speaks out then every one assumes there is not a problem. Half of the problem lies exactly in comments like this - So why are you grumbling here ? - Any use in keeping problems quiet ?
Have you started a support ticket over this issue?
Yes, numerous times, and I'm tired of hearing the same lame excuses. You can compare to the 24/7 support that is available from Mon to Fri during business hours... Seems I'm getting a similar response here now.
In view of the various problems that have been noted in this forum with MPLAB 8.50 why don't you regress to a version that does program them properly?
If you were just for a second thinking here, you would realize that the older versions of MPLab does not support the newer pics. If it wasn't to support the newe devices then a newer version of MPLab would not be published.
Come on you guys, you act like I'm attacking YOU ! I'm not. I'm simply trying to correct a long overdue issue. There is a problem, so make the MPLab authors attend to it and once it's no longer an issue then every one will benefit from it, not just me.
Another thing that would be ab so lutely wonderfull is if you click a pop up nag box's 'do not show this message again' and it actually does not pop up again. Clicking it agrivates it and brings about a host more pop ups. Come on, childish spite or what. How dare you click that.
It is a minor change to do in MPLab. Any one capable of writing such advanced software can cure the issue easily. Fix MPLab so one can program the baby pics without the restriction and the nags - please.
Regards
Fanie
FAZE
Stick to Pic !
Ian.M
Super Member
- Total Posts : 13274
- Reward points : 0
- Joined: 2009/07/23 07:02:40
- Location: UK
- Status: offline
RE: Microchip`s 12F675 Bugger Up 2010/06/09 10:10:14 (permalink)
It is widely known that MPLAB 8.50 has *MANY* issues. My MPLAB 8.40 here lists the PIC12F675 as supported so downgrading to a MPLAB 8.4x version as is usually recomended here in case of problems should be the first thing you try. Instead of returning perfectly good PIC chips, that can easily be recovered by a PICkit 2 or any other programmer that supports VPP first programming, raise a support ticket that MPLAB 8.50 is *BROKEN*, and if you got it on CD, return *THAT*.
I wont explain why you need to use VPP first programming and a programmer with that facility as you have explicitly asked us not to, but it is obvious to anyone with ANY practical experiance of digital electronics *WHY* Microchip had to add the VPP first mode. Most of us can accept the limitations of the PIC in front of us and use the well publicised workarounds instead of screaming the sky is falling . . . .
fanievwyk
Starting Member
- Total Posts : 34
- Reward points : 0
- Joined: 2007/01/17 15:52:11
- Location: 0
- Status: offline
RE: Microchip`s 12F675 Bugger Up 2010/06/09 10:47:06 (permalink)
Hi Ian, I'm not using MPLab for anything else other than programming the pics with.
I have never heard of any reason why the Vpp pin should be made high before V+ is applied, because if this is true, then you cannot do ICSP where the power is already applied before the programming probe comes near the pic. Never had a problem before, never heard that the Vpp should go high first, and I'm using it like that all the time !
Also, with only an external supply to the ICD to program with and no power to the board, if I press the programming probe on the board then power is applied right away, some of the apps that has been programmed before starts to run. It only programs when I press the program button on the PC. Or should I say is supposed to.
If you have a pic sitting there happily working, then if you rise the Vpp pin above V+ the pic goes into programming mode. That is why the Vpp pin can only be an input.
The Vpp pin first is utter nonsense. I don't know who comes up with these far fetched ideas, but it's defenately not the hardware designers.
If Vpp is aplied to the pic before the V+ then it means the programming can starts before the pic is stable to clock the program data in correctly.
What is the workaround for the pics not programming ? Can't we just have MPLab fixed up, I know a lot of guys out there can sit and fiddle with one thing for days and still get paid. Around here it means something else.
I have no problem installing a previous version of MPLab, but it becomes annoying when you have to sit and install and uninstall the program all the time. How can we ask the MPLab authors to sort the mentioned issue out ? The nagging pop up's has been going on since who knows when and it has never been fixed. Maybe now is a good time eh.
Regards
Fanie
FAZE
Stick to Pic !
leon_heller
Super Member
- Total Posts : 6413
- Reward points : 0
- Joined: 2004/08/17 13:19:45
- Location: St. Leonards-on-Sea, E. Sussex, UK.
- Status: offline
RE: Microchip`s 12F675 Bugger Up 2010/06/09 11:00:11 (permalink)
I've been given a development version of MPLAB to try, because of a problem I had debugging the 16F88. It'll probably be released quite soon. I would think that it includes fixes for other problems.
fanievwyk
Starting Member
- Total Posts : 34
- Reward points : 0
- Joined: 2007/01/17 15:52:11
- Location: 0
- Status: offline
RE: Microchip`s 12F675 Bugger Up 2010/06/09 11:27:46 (permalink)
Thank you very much Leon !
Regards
Fanie
FAZE
Stick to Pic !
fanievwyk
Starting Member
- Total Posts : 34
- Reward points : 0
- Joined: 2007/01/17 15:52:11
- Location: 0
- Status: offline
RE: Microchip`s 12F675 Bugger Up 2010/06/09 16:12:17 (permalink)
On *all* modern (flash) PICs. Vpp current consumption is negligable as it is only used to signal 'programming mode'. If Vpp is applied slightly before Vdd it ensures that the PIC goes directly to programming mode without executing any instructions first. If it is allowed to go through run mode, there are three potential problems: if it execute any instructions, the program counter will be incremented, and as the same address counter is used for programming and some types of PIC fail to reset it when programming mode is entered, your hex can be programmed at the wrong address (a problem dating back to the PIC16C84); or the PGC and PGD lines may be set as outputs which your programmer may not be able to drive hard enough to override them, or they may be set as oscillator pins in the config. Obviously if external /MCLR is active it is possible to go from reset directly to programming moide and avoid all these problems.
The moment that Vpp rises over V+ the pic is put into program mode. This means the pic's built in hardware takes over and forces the following - eprom program counter is set to zero and PGC and PGD pins are made inputs.
It is a hardware function built into the pics and has nothing to do with the int clk, int reset or if the pic pins were in or outputs or if the pic has been running for a second or an hour or how many instructions it executed or where in the program memory the pointer is. It does not matter what was or is defined inside the pic, the pic is put directly into program mode - counter is at zero and PGC and PGD pins are forced to inputs.
If there are pics that is so old that they require a different programming sequence, then that should be corrected in the operating firmware for that pic. That is what the firmware is for and that is why an opperating system is downloaded to the programmer for the different pics.
None of the internal hardware or peripherals plays any role or has any function when the pic is programmed, except for the program memory and the programming circuit. All that happens in program mode is the 1's and 0's are clocked into the program memory and or the eeprom memory depending what is selected.
The only time there can be a problem during programming is if the clock pin (PGC) is not held by the programmer initially, ie it is allowed to float then interference or possibly induction can cause the program counter to step on.
If the programmer's timing is done properly then a problem cannot happen, unless of course an external design error is made where Vpp is not allowed to rise to the correct level or when the impedence on PGC or PGD is too low for the programmer to drive.
Even if the correct programming sequence cause a sight delay of a few micro seconds, nobody will even notice it. Just killing the popups all the time takes longer than programming the pics.
Regards
Fanie
FAZE
Stick to Pic !
fanievwyk
Starting Member
- Total Posts : 34
- Reward points : 0
- Joined: 2007/01/17 15:52:11
- Location: 0
- Status: offline
RE: Microchip`s 12F675 Bugger Up 2010/06/09 16:15:42 (permalink)
If the programming is done properly then no workarounds would be required.
Regards
Fanie
FAZE
Stick to Pic !
newfound
Super Member
- Total Posts : 1851
- Reward points : 0
- Joined: 2003/11/07 12:35:49
- Status: offline
RE: Microchip`s 12F675 Bugger Up 2010/06/09 19:26:50 (permalink)
ORIGINAL: fanievwykOn *all* modern (flash) PICs. Vpp current consumption is negligable as it is only used to signal 'programming mode'. If Vpp is applied slightly before Vdd it ensures that the PIC goes directly to programming mode without executing any instructions first. If it is allowed to go through run mode, there are three potential problems: if it execute any instructions, the program counter will be incremented, and as the same address counter is used for programming and some types of PIC fail to reset it when programming mode is entered, your hex can be programmed at the wrong address (a problem dating back to the PIC16C84); or the PGC and PGD lines may be set as outputs which your programmer may not be able to drive hard enough to override them, or they may be set as oscillator pins in the config. Obviously if external /MCLR is active it is possible to go from reset directly to programming moide and avoid all these problems.The moment that Vpp rises over V+ the pic is put into program mode. This means the pic's built in hardware takes over and forces the following - eprom program counter is set to zero and PGC and PGD pins are made inputs.
It is a hardware function built into the pics and has nothing to do with the int clk, int reset or if the pic pins were in or outputs or if the pic has been running for a second or an hour or how many instructions it executed or where in the program memory the pointer is. It does not matter what was or is defined inside the pic, the pic is put directly into program mode - counter is at zero and PGC and PGD pins are forced to inputs.
If there are pics that is so old that they require a different programming sequence, then that should be corrected in the operating firmware for that pic. That is what the firmware is for and that is why an opperating system is downloaded to the programmer for the different pics.
None of the internal hardware or peripherals plays any role or has any function when the pic is programmed, except for the program memory and the programming circuit. All that happens in program mode is the 1's and 0's are clocked into the program memory and or the eeprom memory depending what is selected.
The only time there can be a problem during programming is if the clock pin (PGC) is not held by the programmer initially, ie it is allowed to float then interference or possibly induction can cause the program counter to step on.
If the programmer's timing is done properly then a problem cannot happen, unless of course an external design error is made where Vpp is not allowed to rise to the correct level or when the impedence on PGC or PGD is too low for the programmer to drive.
Even if the correct programming sequence cause a sight delay of a few micro seconds, nobody will even notice it. Just killing the popups all the time takes longer than programming the pics.
Ok, you go on believing you are right and those who really know are wrong. Heads-up for everyone else, this quote is substantially correct, as "moronic" at it seems.
On *all* modern (flash) PICs. Vpp current consumption is negligable as it is only used to signal 'programming mode'. If Vpp is applied slightly before Vdd it ensures that the PIC goes directly to programming mode without executing any instructions first. If it is allowed to go through run mode, there are three potential problems: if it execute any instructions, the program counter will be incremented, and as the same address counter is used for programming and some types of PIC fail to reset it when programming mode is entered, your hex can be programmed at the wrong address (a problem dating back to the PIC16C84); or the PGC and PGD lines may be set as outputs which your programmer may not be able to drive hard enough to override them, or they may be set as oscillator pins in the config. Obviously if external /MCLR is active it is possible to go from reset directly to programming moide and avoid all these problems.
Never the less, why microchip do not fix the MPLAB -ICD issue so that it complies with there own programming specs is something to be critical about. This has been a long standing problem.
Source: https://www.microchip.com/forums/m505180.aspx
0 Response to "You Cannot Post That I Already Read About How Dare You Post It Again"
Post a Comment