PIC ROM addressing above 1023 Page boundry?

[Bill Bowden]

I'm not understanding the PCLATH function to set the ROM memory space
for a PIC16F628 (2K) to some 256 byte boundary.

I have various data tables located in various sections of the ROM
memory space and can access the tables in the lower four 256 byte
pages. But problems arises when I try to access a table located above
the 1024 byte ROM boundry. I am setting the desired page with a hard
number loaded into the PCLATH register which seems to work fine with
lower boundaries of 0-1024. In other words, I load PCLATH with 0 for
address space 0-256 and 1 for space 256-512 and 2 for address space
512-768 and 3 for addresses 768 to 1023. But it doesn't seem to work
for page 4 which is 1024 to 1280.

However, stepping the program with MPLAB seems to work and everything
appears to work well until I load the program into the PIC which then
crashes when the call is made to the far address above 1023.

I suspect some of the higher bits of PCLATH need to be set, to call
far addresses above 1023 but I can't find the exact descriptions from
the data sheet.

It's still strange MPLAB would indicate things working right when the
result is something else.

-Bill

 

[IanM]

I'm not understanding the PCLATH function to set the ROM memory space
for a PIC16F628 (2K) to some 256 byte boundary.

I have various data tables located in various sections of the ROM
memory space and can access the tables in the lower four 256 byte
pages. But problems arises when I try to access a table located above
the 1024 byte ROM boundry. I am setting the desired page with a hard
number loaded into the PCLATH register which seems to work fine with
lower boundaries of 0-1024. In other words, I load PCLATH with 0 for
address space 0-256 and 1 for space 256-512 and 2 for address space
512-768 and 3 for addresses 768 to 1023. But it doesn't seem to work
for page 4 which is 1024 to 1280.

However, stepping the program with MPLAB seems to work and everything
appears to work well until I load the program into the PIC which then
crashes when the call is made to the far address above 1023.

I suspect some of the higher bits of PCLATH need to be set, to call
far addresses above 1023 but I can't find the exact descriptions from
the data sheet.

It's still strange MPLAB would indicate things working right when the
result is something else.

-Bill

Call and Goto use high bits and ignore the low bits but for 2K program
space, they have enough bits in the instruction so the high bits are
left zeroed. You seem to have a handle on the low order bits and
computed gotos.

<http://ww1.microchip.com/downloads/en/AppNotes/00556e.pdf> should be
helpful.

MPLAB will behave oddly if the directive:
LIST P=PIC16F628
in your code (or the PROCESSOR directive), is set to a different chip to
the one selected in the MPLAB IDE (Configure>Device...) or its different
to the include file you have used or the physical chip. DONT mix and
match, all should be exactly the same and PIC16F628 is NOT the same as
PIC16F628A. Your programmer *must* be set to the same chip. Are you
sure you haven't got a 627 chip set somewhere?

 

[petrus bitbyter]

I'm not understanding the PCLATH function to set the ROM memory space
for a PIC16F628 (2K) to some 256 byte boundary.

I have various data tables located in various sections of the ROM
memory space and can access the tables in the lower four 256 byte
pages. But problems arises when I try to access a table located above
the 1024 byte ROM boundry. I am setting the desired page with a hard
number loaded into the PCLATH register which seems to work fine with
lower boundaries of 0-1024. In other words, I load PCLATH with 0 for
address space 0-256 and 1 for space 256-512 and 2 for address space
512-768 and 3 for addresses 768 to 1023. But it doesn't seem to work
for page 4 which is 1024 to 1280.

However, stepping the program with MPLAB seems to work and everything
appears to work well until I load the program into the PIC which then
crashes when the call is made to the far address above 1023.

I suspect some of the higher bits of PCLATH need to be set, to call
far addresses above 1023 but I can't find the exact descriptions from
the data sheet.

It's still strange MPLAB would indicate things working right when the
result is something else.

-Bill

Strange to me too as I have no problem with a PIC16F628(A) that has tables
in the upper part of the memory. You may look into AN556 that covers the
tables, CALLs and GOTOs in more detail. Main issue is that ordinary CALLs
and GOTOs do not use PCLATH at all. Not in a 628 that is. But PCLATH should
be set correctly before executing an 'addwf PCL,f' or similar instruction.
Valid values are in the range 0-7.

petrus bitbyter

 

[Bill Bowden]

"Bill Bowden" <[email protected]> schreef in bericht








Strange to me too as I have no problem with a PIC16F628(A) that has tables
in the upper part of the memory. You may look into AN556 that covers the
tables, CALLs and GOTOs in more detail. Main issue is that ordinary CALLs
and GOTOs do not use PCLATH at all. Not in a 628 that is. But PCLATH should
be set correctly before executing an 'addwf PCL,f' or similar instruction.
Valid values are in the range 0-7.

petrus bitbyter

Yes, the code looks ok, but I think I see a possible problem. I'm
using David Tait's homemade programmer and DOS software to install the
code which was designed around the F84 (1K) version of the PIC and
possibly doesn't recoginize addresses above 1K. It works fine for code
less than 1K size.

Can anyone confirm that?

So, I might have to invest in a newer programmer and software.

-Bill

 

[IanM]

On Dec 17, 7:58 am, "petrus bitbyter" wrote:

Yes, the code looks ok, but I think I see a possible problem. I'm
using David Tait's homemade programmer and DOS software to install the
code which was designed around the F84 (1K) version of the PIC and
possibly doesn't recoginize addresses above 1K. It works fine for code
less than 1K size.

Can anyone confirm that?

So, I might have to invest in a newer programmer and software.

-Bill

I've hacked about with D. Tait's F84 code, attempting to get support for
newer PICs added but I gave up when I found DL4YHF's WinPic.

<http://freenet-homepage.de/dl4yhf/winpicpr.html>

Runs on anything from Win95 to XP, configurable for all sorts of
programmers including *all* Tait varients and unless you did something
stupid like caps on /MCLR or big caps on the PIC VCC, will handle all
sorts of modern PICS up to PIC18Fxxx series and dsPICs.

It even drives monstrosities like my hacked 7407/PNP parallel Tait with
software program/run switching with no problems.

Download it and your problems should be over.

 

[petrus bitbyter]

Yes, the code looks ok, but I think I see a possible problem. I'm
using David Tait's homemade programmer and DOS software to install the
code which was designed around the F84 (1K) version of the PIC and
possibly doesn't recoginize addresses above 1K. It works fine for code
less than 1K size.

Can anyone confirm that?

So, I might have to invest in a newer programmer and software.

-Bill

Still, the times they are a changing. Tait's DOS stuff, though great at the
time, is obsolete now. And sure, you can bet you can't program 2k devices
with software that's only aware of 1k.

I used (and still use) several programmers. A cheap one that works good for
me is the COM84. I mean the new one by DL4YHF. The old one is much less
reliable. You can find it by following the link below the "? Help on COM84"
button which in turn is at the "interface" tab in WINPIC.

Generally speaking, when programming PICs, you can better make sure that the
programmer settings matches device to be programmed. Small differences in
the programming specifications may have unpredictable effects on the parts.
The difference between PIC16F628 and the PIC16F628A for instance, is told to
cause troubles.

petrus bitbyter

 

[IanM]

Still, the times they are a changing. Tait's DOS stuff, though great at the
time, is obsolete now. And sure, you can bet you can't program 2k devices
with software that's only aware of 1k.

Exactly, but thats only the Tait C programmer and utility software. The
Tait paralell hardware is still one of the most reliable cheap DIY
programmers around, provided you still have a real parallel port.

I used (and still use) several programmers. A cheap one that works good for
me is the COM84. I mean the new one by DL4YHF. The old one is much less
reliable. You can find it by following the link below the "? Help on COM84"
button which in turn is at the "interface" tab in WINPIC.

I have had varying results with serial port programmers. Even good ones
like DL4YHF's one don't usually buffer the programming clock and data
lines so are unreliable for ICSP use. The ones that hope the serial port
can drive MCLR high enough or worse try to power the PIC off the serial
port are unusable with laptops that often provide 9V or less signal
levels on their serial ports. The 'Classic' parallel Tait is robust,
does ICSP well and also protects the port pretty well against mishaps at
low cost as long as you socket the 7407 for easy replacement.

Generally speaking, when programming PICs, you can better make sure that the
programmer settings matches device to be programmed. Small differences in
the programming specifications may have unpredictable effects on the parts.
The difference between PIC16F628 and the PIC16F628A for instance, is told to
cause troubles.

Even when Tait's software was current, the PIC version differences
screwed things up. There was that config bit inverted from C84 to F84
and IIRC the F84A needed a slightly different algorithm (or rather a
stricter algorithm that still worked for the F84). Near enough is
NOWHERE near good enough with PICS and programmers.

 

[Bill Bowden]

I've hacked about with D. Tait's F84 code, attempting to get support for
newer PICs added but I gave up when I found DL4YHF's WinPic.

<http://freenet-homepage.de/dl4yhf/winpicpr.html>

Runs on anything from Win95 to XP, configurable for all sorts of
programmers including *all* Tait varients and unless you did something
stupid like caps on /MCLR or big caps on the PIC VCC, will handle all
sorts of modern PICS up to PIC18Fxxx series and dsPICs.

It even drives monstrosities like my hacked 7407/PNP parallel Tait with
software program/run switching with no problems.

Download it and your problems should be over.

Yes, that looks promising. I installed WinPic and have it running on a
xP machine, but haven't connected the programmer yet. I plan to use
another machine running Win98.

My HEX files are from MPLAB and include the configuration word, so I
guess I should disable the settings in the "Device config" window? I
selected the "Tait 7406 PNP" option in the interface window which
matches the hardware on LPT1.

Any other trickey things I should setup?

Thanks,

-Bill

 

[IanM]

Yes, that looks promising. I installed WinPic and have it running on
a xP machine, but haven't connected the programmer yet. I plan to use
another machine running Win98.

My HEX files are from MPLAB and include the configuration word, so I
guess I should disable the settings in the "Device config" window? I
selected the "Tait 7406 PNP" option in the interface window which
matches the hardware on LPT1.

Any other trickey things I should setup?

Thanks,

-Bill

I run it under Win98se so can probably give specific advice.

1. Its best run on its own printer port. I have a second parallel card
installed so no other parallel device drivers have any excuse to mess
with it. If not practical to do so, then UNINSTALL any third party
drivers that *READ* the printer port, e.g. ANY printer driver that
reports ink levels or has a printer status panel, parallel scanners,
IOMEGA parallel zip drives etc. Set all printers on that port using
Microsoft drivers(from win98 CD) offline in the print manager.

After you have tested the WinPic/interface combo and burnt some PICS
successfully it may be possible to reinstall third party printer drivers
but you will probably need to direct them to a file or network virtual
LPT port before starting Winpic. If there is an option to turn OFF the
tray icon for their printer monitoring software, do so. Retest WinPic
after every reinstall.

2. I have no problems running the faster Porttalk port access method
(options tab). YMMV. Whichever you select, first time, TEST the
interface with no PIC inserted, using the panel on the test tab, a
multimeter and a jumper wire to ground the data pin to check WinPic
reads it OK. Depending on your programmer circuit and the precise
location you returned pullup resistors to, tests made on other pins
without turning on VDD may well be meaningless so test that line first
and leave it ticked while testing the rest. To test Data In, tick Data
(to PIC), and check you get a 1, then ground the pin and check its
reported as 0.

3. if MPLAB is installed, set the DEV file directory on the options tab
to point to the correct folder for better reporting of config bits etc.
You dont need to do anything in the device config tab except select the
correct PIC type to program as the settings are picked up from the Hex
file if you are using MPLAB correctly or from the PIC itself when
reading one. You can override the MPLAB settings *after* loading the
Hex, before you program the PIC.

4. if you want the programmer reset when windows boots put a shortcut
with a command line of:
"C:\Program Files\WinPic\WinPic.exe" /nodelay /q
in your startup group.

5. MPLAB is *buggy* and fairly unstable under Windows 98. This is
complicated by memory leaks in many PDF viewers. If your developing on
a Win98 box, I STRONGLY recommend using RAMBOOSTER
<http://www.sci.fi/~borg/rambooster/index.htm>
to reduce the number of crashes you get and the need to reboot after a
crash. The version of MPLAB I am using (v 8.01) crashes on
startup WHILE LOADING THE WORKSPACE FILE if I left *any* subwindow in
the IDE docked to the edge of the screen when I last closed it. If you
get this bug, *ALWAYS* keep a clean copy of the workspace file for your
project and get back in by starting MPLAB with the workspace file on the
command line. Docked windows are too convenient not to use when
debugging so I set up two saved window sets (on the window menu), one
with all the windows docked the way I like them, and the other with
*every* window I might have open UNDOCKED.

Any problems, feel free to ask. I'll watch this thread for a day or
two, after that, you'd do best to start a new one with a more specific
title e.g. 'PIC16F628A, WinPic and Tait programmer problems' if you want
to catch my attention AND get the valuable input of the other posters in
this thread. I don't mind going to email if you like, although I believe
the 'peer review' one gets here to be pretty important. (Obviously one
of us would need to post instructions for getting a valid email address,
I can if asked)

It would be nice to hear a little about the project you are working on
even if it falls in the 'just fiddling' category. Feedback is always
good, makes contributors here feel valued and more likely to help in the
future

 

[Bill Bowden]

I run it under Win98se so can probably give specific advice.

1. Its best run on its own printer port. I have a second parallel card
installed so no other parallel device drivers have any excuse to mess
with it. If not practical to do so, then UNINSTALL any third party
drivers that *READ* the printer port, e.g. ANY printer driver that
reports ink levels or has a printer status panel, parallel scanners,
IOMEGA parallel zip drives etc. Set all printers on that port using
Microsoft drivers(from win98 CD) offline in the print manager.

After you have tested the WinPic/interface combo and burnt some PICS
successfully it may be possible to reinstall third party printer drivers
but you will probably need to direct them to a file or network virtual
LPT port before starting Winpic. If there is an option to turn OFF the
tray icon for their printer monitoring software, do so. Retest WinPic
after every reinstall.

2. I have no problems running the faster Porttalk port access method
(options tab). YMMV. Whichever you select, first time, TEST the
interface with no PIC inserted, using the panel on the test tab, a
multimeter and a jumper wire to ground the data pin to check WinPic
reads it OK. Depending on your programmer circuit and the precise
location you returned pullup resistors to, tests made on other pins
without turning on VDD may well be meaningless so test that line first
and leave it ticked while testing the rest. To test Data In, tick Data
(to PIC), and check you get a 1, then ground the pin and check its
reported as 0.

3. if MPLAB is installed, set the DEV file directory on the options tab
to point to the correct folder for better reporting of config bits etc.
You dont need to do anything in the device config tab except select the
correct PIC type to program as the settings are picked up from the Hex
file if you are using MPLAB correctly or from the PIC itself when
reading one. You can override the MPLAB settings *after* loading the
Hex, before you program the PIC.

4. if you want the programmer reset when windows boots put a shortcut
with a command line of:
"C:\Program Files\WinPic\WinPic.exe" /nodelay /q
in your startup group.

5. MPLAB is *buggy* and fairly unstable under Windows 98. This is
complicated by memory leaks in many PDF viewers. If your developing on
a Win98 box, I STRONGLY recommend using RAMBOOSTER
<http://www.sci.fi/~borg/rambooster/index.htm>
to reduce the number of crashes you get and the need to reboot after a
crash. The version of MPLAB I am using (v 8.01) crashes on
startup WHILE LOADING THE WORKSPACE FILE if I left *any* subwindow in
the IDE docked to the edge of the screen when I last closed it. If you
get this bug, *ALWAYS* keep a clean copy of the workspace file for your
project and get back in by starting MPLAB with the workspace file on the
command line. Docked windows are too convenient not to use when
debugging so I set up two saved window sets (on the window menu), one
with all the windows docked the way I like them, and the other with
*every* window I might have open UNDOCKED.

Any problems, feel free to ask. I'll watch this thread for a day or
two, after that, you'd do best to start a new one with a more specific
title e.g. 'PIC16F628A, WinPic and Tait programmer problems' if you want
to catch my attention AND get the valuable input of the other posters in
this thread. I don't mind going to email if you like, although I believe
the 'peer review' one gets here to be pretty important. (Obviously one
of us would need to post instructions for getting a valid email address,
I can if asked)

It would be nice to hear a little about the project you are working on
even if it falls in the 'just fiddling' category. Feedback is always
good, makes contributors here feel valued and more likely to help in the
future

Tried using WinPic today but had a couple problems using Win98se.

I connected the Tait programmer, installed the SMPORT.VXD driver in
the WinPic directory and ran the initialization test which produced a
couple errors of "Failed readback of DATA line (LOW) and "Windows
fooled aound with the LPT port bits"

I booted the machine with the programmer connected and the programmer
lights (+5) and (+12) came on and off indicating some activity, so the
hardware connection seems to be correct.

However, trying to send data from a hex file to a uninstalled PIC
doesn't produce any activity on the port data lines and generates more
errors.

There are no third party printer drivers in the system, the only
printer driver installed is from the windows CD "MX 80"

Any ideas?

The project is just experimental controlling 24 LEDs using a PICF628
and a couple serial shift registers (74HC164). I'm just trying to
learn how to access the upper 1K of ROM.

-Bill

 

[Bill Bowden]

I run it under Win98se so can probably give specific advice.

1. Its best run on its own printer port. I have a second parallel card
installed so no other parallel device drivers have any excuse to mess
with it. If not practical to do so, then UNINSTALL any third party
drivers that *READ* the printer port, e.g. ANY printer driver that
reports ink levels or has a printer status panel, parallel scanners,
IOMEGA parallel zip drives etc. Set all printers on that port using
Microsoft drivers(from win98 CD) offline in the print manager.

After you have tested the WinPic/interface combo and burnt some PICS
successfully it may be possible to reinstall third party printer drivers
but you will probably need to direct them to a file or network virtual
LPT port before starting Winpic. If there is an option to turn OFF the
tray icon for their printer monitoring software, do so. Retest WinPic
after every reinstall.

2. I have no problems running the faster Porttalk port access method
(options tab). YMMV. Whichever you select, first time, TEST the
interface with no PIC inserted, using the panel on the test tab, a
multimeter and a jumper wire to ground the data pin to check WinPic
reads it OK. Depending on your programmer circuit and the precise
location you returned pullup resistors to, tests made on other pins
without turning on VDD may well be meaningless so test that line first
and leave it ticked while testing the rest. To test Data In, tick Data
(to PIC), and check you get a 1, then ground the pin and check its
reported as 0.

3. if MPLAB is installed, set the DEV file directory on the options tab
to point to the correct folder for better reporting of config bits etc.
You dont need to do anything in the device config tab except select the
correct PIC type to program as the settings are picked up from the Hex
file if you are using MPLAB correctly or from the PIC itself when
reading one. You can override the MPLAB settings *after* loading the
Hex, before you program the PIC.

4. if you want the programmer reset when windows boots put a shortcut
with a command line of:
"C:\Program Files\WinPic\WinPic.exe" /nodelay /q
in your startup group.

5. MPLAB is *buggy* and fairly unstable under Windows 98. This is
complicated by memory leaks in many PDF viewers. If your developing on
a Win98 box, I STRONGLY recommend using RAMBOOSTER
<http://www.sci.fi/~borg/rambooster/index.htm>
to reduce the number of crashes you get and the need to reboot after a
crash. The version of MPLAB I am using (v 8.01) crashes on
startup WHILE LOADING THE WORKSPACE FILE if I left *any* subwindow in
the IDE docked to the edge of the screen when I last closed it. If you
get this bug, *ALWAYS* keep a clean copy of the workspace file for your
project and get back in by starting MPLAB with the workspace file on the
command line. Docked windows are too convenient not to use when
debugging so I set up two saved window sets (on the window menu), one
with all the windows docked the way I like them, and the other with
*every* window I might have open UNDOCKED.

Any problems, feel free to ask. I'll watch this thread for a day or
two, after that, you'd do best to start a new one with a more specific
title e.g. 'PIC16F628A, WinPic and Tait programmer problems' if you want
to catch my attention AND get the valuable input of the other posters in
this thread. I don't mind going to email if you like, although I believe
the 'peer review' one gets here to be pretty important. (Obviously one
of us would need to post instructions for getting a valid email address,
I can if asked)

It would be nice to hear a little about the project you are working on
even if it falls in the 'just fiddling' category. Feedback is always
good, makes contributors here feel valued and more likely to help in the
future

Well, I had a little more sucess today and managed to program a
PIC16F628 using WinPic.

One problem was using SMPORT which wouldn't communicate with LPT1, so
I tried the faster PortTalk driver with better results. Another
problem was a bad PIC that must have been burned too many times, a
fresh chip worked better. I thought these things would burn 100 times
or more, and I didn't do that many.

Anyway, the setup works well now, haven't tried using the upper ROM
yet, but it should work.

Thanks for the help,

-Bill

 

[IanM]

Well, I had a little more sucess today and managed to program a
PIC16F628 using WinPic.

One problem was using SMPORT which wouldn't communicate with LPT1, so
I tried the faster PortTalk driver with better results. Another
problem was a bad PIC that must have been burned too many times, a
fresh chip worked better. I thought these things would burn 100 times
or more, and I didn't do that many.

Anyway, the setup works well now, haven't tried using the upper ROM
yet, but it should work.

Thanks for the help,

-Bill

Glad you are getting there. I'm toying with the idea of treating myself
to a PICkit 2 for in circuit debugging capabilities. Most of the cheap
DIL PICs don't have ICD support though and I cant justify buying the
debug bondout chip modules so I'd have to make do with getting some
16F87 chips and being *very* careful with my includes and that I'm
writing portable code with no hard coded registers or bit masks.


If your bad chip had been programmed with the Tait software using the
old F84 algorithm, it could well be prematurely damaged. 16F87s are
supposed to be good for 100000 erase/write cycles of the program memory.
I suspect the pins would wear out first in development use.
Oddly, I couldn't find the number of cycles a 16F628 is good for in its
datasheet.

Your port problems were down to windows messing with its print spooler.
I mentioned I have the programmer on a separate port with no printers
drivers installed on it. However if you have a reliable setup now with
PortTalk, leave well enough alone.