PIC ROM addressing above 1023 Page boundry?

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

Reply to
Bill Bowden
Loading thread data ...

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.

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?

Reply to
IanM

"Bill Bowden" schreef in bericht news: snipped-for-privacy@c36g2000prc.googlegroups.com...

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

Reply to
petrus bitbyter

berichtnews: snipped-for-privacy@c36g2000prc.googlegroups.com...

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

Reply to
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.

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.

Reply to
IanM

If you have the option to run Windows on your machine, you should try some free software first. Ian mentions WinPic, which should work. I also like IC-prog:

formatting link

--
RoRo
Reply to
Robert Roland

On a sunny day (Thu, 18 Dec 2008 10:56:41 +0100) it happened Robert Roland wrote in :

And, in case of Linux, I still have a noppp programmer on the par port of this PC.

formatting link
I rewrote the Linux programmer code so it will do more PICs,

16F628, 16F648A, 12F675 etc. If you want the source let me know. Total cost was zero IIRC (parts from junk box).
Reply to
Jan Panteltje

"Bill Bowden" schreef in bericht news: snipped-for-privacy@w1g2000prk.googlegroups.com...

berichtnews: snipped-for-privacy@c36g2000prc.googlegroups.com...

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

Reply to
petrus bitbyter

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 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.

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.

Reply to
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

Reply to
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.

  1. 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.

  1. 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.

  2. 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.

  1. 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

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 :-)

Reply to
IanM

If you put the updated source code on your website some people would probably appreciate it.

Chris

Reply to
Chris Jones

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

Reply to
Bill Bowden

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

Reply to
Bill Bowden

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.

Reply to
IanM

Table 17-3.

1k minimum, 10k typical.

If you get the A version, you get ten times that.

--
RoRo
Reply to
Robert Roland

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.