Like everyone else, I'm building a 16c84 programmer.
I have a problem with the erase: the uChip documentation says that the
erase sequence will erase all code, data and configuration.
When the device is protected, this seems to be the case.
When the device is not protected however, the code and configuration is
erased, but the data is not.
Is this normal behaviour, or am I doing something wrong?
In message <spam_OUT199801231940.UAA28868TakeThisOuTxs2.xs4all.nl>, wouter van ooijen
>Like everyone else, I'm building a 16c84 programmer.
>I have a problem with the erase: the uChip documentation says that the
>erase sequence will erase all code, data and configuration.
>When the device is protected, this seems to be the case.
>When the device is not protected however, the code and configuration is
>erased, but the data is not.
>Is this normal behaviour, or am I doing something wrong?
I don't know about 'normal', but it's seems to be what usually happens.
To overcome the problem I eventually managed to implement the 'bulk
erase' feature - although the details in the app note don't work. If the
required code (in Pascal/Delphi) is of any help, let me know privately.
> I don't know about 'normal', but it's seems to be what usually happens.
> To overcome the problem I eventually managed to implement the 'bulk
> erase' feature - although the details in the app note don't work. If the
> required code (in Pascal/Delphi) is of any help, let me know privately.
If you can tell me what's wrong in the uChip documentation of the 'erase
data' - it does not seem to work for me!
Or just send the relevant code fragments - i've never read Delphi but I
think I can manage (I use TurboPascal).
The other solution I consider is to set the protection first and then
A bit strange, but it seems to work (that is: to rease code+conf+data)
wouter van ooijen wrote:
> Like everyone else, I'm building a 16c84 programmer.
> I have a problem with the erase: the uChip documentation says that the
> erase sequence will erase all code, data and configuration.
> When the device is protected, this seems to be the case.
> When the device is not protected however, the code and configuration is
> erased, but the data is not.
> Is this normal behaviour, or am I doing something wrong?
Yes, It is normal behavior. I know that my PIC's works in same way, and
I know that other has got same problems. PIX erase the dataarea
spearately, (as far as I know) to avoid that it is unerased. It has been
mensioned in some documentation of PIX, the readme file.
If you are going to make a programmer, then there might be other trix
that you like to know:
You need to disable interrupts when sending a command. To avoid
problems with synchronization, it seems to be such that the PIC16C84
clears it's bit counter (I guess) if there is a delay higher than about
5 to 10ms between the bits. It is no limitations between the commands
(as when programming). There is not anyone that has mensioned it, as far
as I know. But some had problems with very slow computers because of the
low clock speed. There was a lot that has problems with windows too, and
the protection was enabled by fault when an interrupt occeur.
After sending command, should interrupts be enabled again - to allow
multitasking and interrupts and mouse to work proper.
You could try it by adding a delay in sending the command, e.g. 12ms.
I guess that it makes it malfunction. (The programming is very slow when
adding such delay, but it is realistic because of interrupts may
There is no limitations between commands, and there may be as high delay
as you like for programming, typical is 10ms.
Some people says that the codeprotect byte is erased later. This is done
to make sure that it has been erased all code and data before clearing
codeprotect. I have decided to use 20ms for erase time to handle this,
but it should work even if only 10ms is used. (This is done in the
datasheets, and I do beleave that it works. Maybee it is actualy using
20ms because the erase has been done in two commands.)
Microchip says in an erata that the programming of data area is typical
10ms, not max 10ms as they says in their datasheets. The maximum is
20ms. But I don't know if this erata is when programming, or if it is
only when using the dataarea.
If you are making dos software, then it is quite a lot of problems with
making it working from dos-prompt, specialy if using the com-port. It is
not the problems with LPT-ports, but even if using LPT, you might need a
delay (small) between every bit to make sure that the hardware is fast
enough. This delay has only something to say on very fast computers, as
fast 486 or pentium. When using the serial port should about a 85s delay
be used for reducing the maximum speed to about 115Kbaud.
When running from windows, then the dos-prompt is a bit special, and the
bits in the port may not be updated as it should if using a port
It seem to work if the com-port is initialized with all registers.
You may like to see my code, and source if you like. My programmers is
at http://www.ebar.dtu.dk/~c888600/newpic0.htm and the some source is in
pgm84v26.zip. I have tried to make it running from windows dos prompt,
and this may make the code a bit special. The timer that is used, is the
serial chip's boaud rate generator, to avoid windows problems with
shared timers. Shot delays are made with timer 2 (the timer that is
typical used for delays and sound). To make it working from windows, is
it initialized and only used when interrupts are disabled. This allows
multitasking, and PICTEST works when programming more chips at same time
(I used two comports). I do not guarentee windows, because I had a lot
of windows problems, and I never know if there might be some versions
that won't work. I have recieved letters from people that had it working
perfectly on their computer, but then it only worked from dos on the
laptop. I tested PICTEST with windows 3.11, and it seemed to work
Thanks for the elaborate reaction. I now realise that I had already found
your code on the web and studied it (and used it to understand uChips
documentation, which would otherwise have been hard).
My programmer uses a 16c84 to generate the +14V and to handle all timing,
so I won't be hindered by most of the problems you describe. Accidently I
once used the 10mS delay routine for the delay between the bits, but beside
a very slow operation I did not notice any unexpected behaviour from the
pic being programmed.
For the PC-to-programmer communication I use rs232 at a modest 19k2 (that's
the highest speed supported by the w3.11 terminal, which I use for
debugging). To avoid overruns I use a handshake for each character send or
received. So far I have had no problems with doing this under a w95 DOS-box
(I'll try plain DOS, NT3.51 and w3.11 when I have finished the host
program). Using a 16c84 might seem overkill, but it allows some nice
- no host-OS induced timing problems
- multiple programmers on a single rs232 line
- direct comunication with the target using the same serial line
At least, that will be the nice touches when I've finished my little