Jump to content
mytek

Create ICSP Programmer for Embedded Micro Controller Chips

Recommended Posts

 

Update: Yeah, I had the jumpers installed on those points when I went to the backup machine. Still didn't work, was/is weird. However, The JOY2PIC worked fine with the breadboard.

 

Question: Is there any reason this would not work on an 800? I tried tonight (since I was fixing the 800, I figured I would try . . 800 now is peachy, but couldn't get it to flash the chips).

 

Thanks. I now have three verified working JOY2PICS, 3 working TK-XEGS-S, 3 Working TK-XEGS and 3.5 working TK-IIs (waiting on parts for the interface setup. RT Angle shrouded connectors are hard t find apparently.).

 

What am I going to do with them? Dunno. OSH Park makes things in threes so, I made three of each ;-)

 

I see that Jameco no longer carries that shrouded right angle connector I specified (thanks for the heads up). Here's an alternative which looks to be the same, but does require a minimum order of 5 pieces.

 

753619.jpg

Jameco P/N: 753619

 

I'll have to update the BOM.

 

I can't really say why the JOY2PIC doesn't work on your 800 (I don't have one here to test with). It does seem odd, could possibly be something to do with the slightly different OS, but I'm just guessing. I'll have to take a look at the schematics for an 800 to see if the hardware has any significant differences to do with the joystick ports, but I kinda doubt it. Quite the mystery for the time being.

 

 

 

I now have three verified working JOY2PICS, 3 working TK-XEGS-S, 3 Working TK-XEGS and 3.5 working TK-IIs

 

Not bad considering the state of affairs this time last year, when you were desperately looking for a PS/2 to Atari keyboard adapter :grin: .

 

- Michael

Share this post


Link to post
Share on other sites

Typical, I got my JOY2PIC boards from OSH Park in the mail today :)

 

The only difference I can see compared to the boards I got is that D5 is upside down. Am I missing anything else?

 

Yep that is all that was wrong on the original silk screen (all the traces are unchanged). It was a minor issue, but one that would cause the LED not to work if incorrectly inserted. So on the boards you got, just be sure to ignore the led orientation as shown and go by how it looks in the picture I just posted.

 

I would have corrected this earlier, but it wasn't worth the ExpressPCB-to-Gerber conversion fee. But since I have been doing a lot of these conversions lately I forked out the $49 and bought the software so that I could do it myself. The software is called Copper Connection and is extremely easy to use. There are 3 versions (Home, Studio, Ultimate), with the Home Edition being free although it can't produce gerbers files. The Studio Edition is the one that I purchased a license for, and it has all that you need to create production gerber files. I really should have gotten this sooner (would have saved me $50 in conversion fees for all of the boards i've been creating).

 

- Michael

  • Like 2

Share this post


Link to post
Share on other sites

WARNING: Conductive Border on last PCB run

 

I just assembled two boards with neither one working. The problem was a thin conductive border that the D-Sub9 connector would short to. Easy solution is to sand that edge until the border disappears and then check each SMD pad for non-conduction to the adjacent one before assembly.

 

YiDnpzr.jpg

 

 

- Michael

Edited by mytekcontrols
  • Like 3

Share this post


Link to post
Share on other sites

Question: Am trying to program a PIC16F876. This one has both an eeprom and FlashRom. I am trying to find something to program both. Would JOY2PIC be able to handle that?

 

(Yes, I could read the datasheet [and am about to] but thought I would ask people generally more knowledgeable about this than I am as well).

 

-M

Share this post


Link to post
Share on other sites

Question: Am trying to program a PIC16F876. This one has both an eeprom and FlashRom. I am trying to find something to program both. Would JOY2PIC be able to handle that?

 

(Yes, I could read the datasheet [and am about to] but thought I would ask people generally more knowledgeable about this than I am as well).

 

-M

 

Yes with an updated READHEX.COM program, it could create a flashing app to program the FLASH memory in a PIC16F876. But the way its presently coded I don't think it'll burn the EEPROM space (dsmc can answer that better than I).

 

But if those limitations are not a problem, then here is how you can update the readhex.c file which is contained in this download: picprog-20160107.zip

 

First you'll need to have a local version of CC65 running on your PC which is available from: cc65.github.io/cc65/getting-started (there are both Linux and Windows versions).

 

Then edit the readhex.c file, adding the new PIC parameters to the list (see the new PIC16F876 devices I added in the example code below). Also google for the programming specifications for the chip series being added so as to know the memory map parameters. Reference: PIC16F87X Programming Speciifications

 

readhex.c PIC List parameter definitions...

- name : the device name,

- device_id : the device id as HEX, this is from the programming datasheet.

- max_addr : the amount of program memory words in the chip.

- id_addr : the address of the "configuration memory" in the PIC, this is 0x2000 for the old PICs and 0x8000 for the "enhanced midrange" PICs

- last_addr : the last address of configuration memory.

 

For a PIC16F876 the device_id=0x9e0, For a PIC16F876A the device_id=0xe00 (here's a complete list of PIC device_id's: PIC Device IDs.txt).

 

Example Code

// List of PICs
struct pics_data
{
    const char *name;
    unsigned device_id;
    unsigned max_addr;
    unsigned id_addr;
    unsigned last_addr;
} pic_list[] =
{
    { "1: PIC16F690",  0x1400, 0x1000, 0x2000, 0x2008 },
    { "2: PIC12F675",  0x0FC0, 0x0400, 0x2000, 0x2008 },
    { "3: PIC16F1847", 0x1480, 0x2000, 0x8000, 0x8009 },
    { "4: PIC16F1936", 0x2360, 0x2000, 0x8000, 0x8009 },
    { "5: PIC16F876",  0x9e0, 0x2000, 0x2000, 0x2007 },
    { "6: PIC16F876A", 0xe00, 0x2000, 0x2000, 0x2007 },
    { 0, 0, 0, 0, 0 }
};

- Save updated readhex.c file

 

- Compile it with "cl65 -t atari -Osir readhex.c -o readhex.com"

 

- Newly generated READHEX.COM file will now have the PIC16F876 & PIC16F876A chip selections in its menu when run.

 

Just as before, to create a new flashing file app that will run on your A8, first run READHEX.COM and when requested, enter the hex file name of the firmware, and select the PIC from the list. READHEX.COM will now create a unique flashing app for that specific firmware. Then by running that new program on your A8, you will be able to flash your chip using the JOY2PIC hardware attached to joystick port #1.

 

LINK to original information and downloads that were referenced in this posting.

 

Hope that somewhat answers your question, and if I'm off track on any of what I have described maybe dsmc can step in and post a correction.

 

- Michael

 

 

EDIT: If you are planning on using Linux to run CC65, here is some additional info on using the terminal to install the cc65 application on your system (replace 'username' with your own name).

 

cd /home/username

git clone https://github.com/cc65/cc65.git

cd cc65

make

sudo make avail

Edited by mytekcontrols
  • Like 2

Share this post


Link to post
Share on other sites

Excellent! I will get on this and see what I can screw up! ;-)

 

The best way I found to create the final flashing app, is to initially do everything in something like the Atari800 emulator and start with this disk image: picprog.atr

 

Then prior to running this in the emulator, use makeATR to insert the new READHEX.COM program generated by the cc65 compiler (first delete the existing one), and also include your PIC hex firmware file. Then save the image, and run it in the emulator with BASIC disabled. Follow the program prompts and name the new file PICPROG.COM, and a new flashing app with that name will be generated.

 

I then use makeATR to extract PICPROG.COM and insert it into this ATR file: JOY2PIC Flashing App (blank).atr.

 

Save it, rename it if desired, and then run that via SIO2PC and RespeQt with a real A8 attached. and you will automatically be prompted to hit START to program your PIC with the new firmware.

 

In that same ATR file you'll also find a README file that will automatically load before the START prompt appears, feel free to alter this to suit your purposes. I normally edit that file to better describe my project, adding the name of what the firmware will be used in, the version number, the date, and provide a short description of any changes. Minimally you should at least change the PIC chip name to the type you'll be using.

 

I know it's quite a few steps, but the end result is extremely easy to use by the guy who wishes to update PIC firmware on his device, as you've probably already seen in some of the firmware updates I did for TK-II.

 

Cheers :)

 

- Michael

Edited by mytekcontrols
  • Like 1

Share this post


Link to post
Share on other sites

I finally made my JOY2PIC, and it worked first time! (Including the LED, which is a minor miracle considering that the LED I bought had no visible differences between anode and cathode).

 

I've already posted about my TK-II success in the other thread, I just wanted to thank Michael in this thread for the brilliant idea to make an Atari based programmer. I've had little luck connecting PC-based hardware to my Mac, so I'm not sure I would have been able to get the TK-II programmed at all if there hadn't been a native programming solution.

 

I do have a suggestion to anybody else who wants to make one to use on an XEGS: use a 90° header rather than a straight one for the programming connector. The connector doesn't completely clear the XEGS's joystick port overhang, so I had to bend everything a little more than I would have liked.

 

  • Like 2

Share this post


Link to post
Share on other sites

I do have a suggestion to anybody else who wants to make one to use on an XEGS: use a 90° header rather than a straight one for the programming connector. The connector doesn't completely clear the XEGS's joystick port overhang, so I had to bend everything a little more than I would have liked.

 

 

Yep I had to do that on mine as well :thumbsup: Darn Atari engineers :mad:

 

Glad to hear that you had success and like this solution. And even though I have a PICkit3 programmer, I've found myself just using the JOY2PIC instead. Because with the auto-loading firmware flasher, it's just so simple. But most of the credit really needs to go to dsmc for his original circuit design concepts and of course the actual programming software. On this project I acted more as the catalyst, putting the idea out there, and then dsmc grabbed the ball and ran with it. In the end we have an elegant and cheap solution.

 

- Michael

 

 

103271.jpg

Right Angle Break-Away Header 36 Position 2.54mm (makes 6 individual ICSP headers)

$1.05 @ Jameco.com

Edited by mytekcontrols

Share this post


Link to post
Share on other sites

 

But most of the credit really needs to go to dsmc for his original circuit design concepts and of course the actual programming software.

 

 

Opps slight typo, that realy should have been dmsc.

 

- Michael

Share this post


Link to post
Share on other sites

Hi!

 

Yes with an updated READHEX.COM program, it could create a flashing app to program the FLASH memory in a PIC16F876. But the way its presently coded I don't think it'll burn the EEPROM space (dsmc can answer that better than I).

I was away from my home, so just saw this post, thanks for all that really good documentation!

 

I just uploaded all my last sources to github, see https://github.com/dmsc/mkatr. If anybody want to contribute (specially with better documentation), I can merge pull-requests to the repository or add anyone as a collaborator.

 

About programming the on-chip EEPROM, there is not currently implemented in the picprog.asm (the low-level programmer) nor in the readhex.c (the HEX file parser).

 

As the PIC command for EEPROM (DATA MEMORY) writing is different than the standard PROGRAM MEMORY writing, you will need adding a new low-level command to the binary script that the "readhex.c" program writes.

 

Currently the script format is the following:

 

- 1 byte with number of program words to write (LEN).

-- If LEN is greater than 0, then follows 2*LEN bytes with all the words (low byte first).

-- If LEN is 0, there is another byte with a SKIP count, this specifies a number of program words that should be skipped.

-- If SKIP is also 0, then the following commands are for ID memory instead of PROGRAM memory.

 

So, for example, to write a "3FFF" to program word 16 and "107F" to configuration word (at address $2007), the script is:

 

  00, 10,       # Skip 16 program words. (starts at 0)
  01, FF, 3F,   # Program 1 word with $3FFF.
  00, 00,       # Go to ID memory
  00, 07,       # Skip to config word
  01, 7F, 10    # Program 1 word with $107F.
The "readhex.c" program concatenates the "picprog.com" file with the script, generating the programming code.

 

To add support for EEPROM, you could use the command "00 FF" (currently "skip 255 program memory words) to specify "go to DATA MEMORY", and use the same logic as the current script. Also, as the EEPROM address is different for different PIC chips, you will need to add at least one entry to the pics_data struct with the EEPROM address.

 

Well, hope it helps.

  • Like 2

Share this post


Link to post
Share on other sites

OK now that we have a good hardware/software solution, it's time to start thinking about creating a JOY2ICSP PCB. This is where I can add some of my creativity to the project since Daniel has obviously done an excellent job of getting the hardware/software design and development under way. So what I have in mind is to create a very tiny board with an integral D-Sub 9-pin female joystick connector, and an industry standard 6-pin ICSP header. It'll be able to do In Circuit Programming, and/or with the addition of a separate ICSP adapter board, it'll also be able to program a loose unmounted chip.

 

ICSP Adapters

s-l500.jpg

 

I'll present more info as this comes together. Expect to see the PCB boards available from OSH Park in the near future.

 

- Michael

Hi Mike!

Where can I purchase these PCB from?

 

 

Thanks!

Steve

http://www.realdos.net

Share this post


Link to post
Share on other sites

Ok I am attempting to add two new PIC devices to READHEX.COM and I have hit a road block. Since it will likely help others who wish to do the same, I decided let's work through this problem in this forum topic instead of via PM's to the program's creator DMSC. So first of all for reference please look at this LINK where I describe the process of using cc65 to create a new compilation of the source code. This is the procedure that I followed and was able to get a successful re-compile of the readhex.c source into readhex.com. The problem comes when I try to actually program the chip, at which point I get an error message to the effect that there is an invalid device ID. So first let me run everyone through what I did to get to that point.

 

First I modified the readhex.c source code: readhex.c.zip

// List of PICs
struct pics_data
{
    const char *name;
    unsigned device_id;
    unsigned max_addr;
    unsigned id_addr;
    unsigned last_addr;
} pic_list[] =
{
    { "1: PIC12F675",  0x0FC0, 0x0400, 0x2000, 0x2008 },
    { "2: PIC12F1571",  0x3051, 0x0400, 0x8000, 0x8009 },
    { "3: PIC12F1572",  0x3050, 0x0800, 0x8000, 0x8009 },
    { "4: PIC16F690",  0x1400, 0x1000, 0x2000, 0x2008 },
    { "5: PIC16F1847", 0x1480, 0x2000, 0x8000, 0x8009 },
    { "6: PIC16F1936", 0x2360, 0x2000, 0x8000, 0x8009 },
    { 0, 0, 0, 0, 0 }
};

I've added two new PIC chips: 12F1571 and 12F1572.

 

The device ID's I got from this document: PIC12(L)F1571/2 Family Silicon Errata...

The Programming Memory data from here: PIC12(L)F1571/2 Memory Programming Specification

 

- Compiled it with "cl65 -t atari -Osir readhex.c -o readhex.com"

 

- cc65 compile was successful - no errors - and produced new READHEX.COM file.

 

- Inserted this file, and the PIC12F1571 hex file from the V-Gate project in a new ATR: picprog.atr

 

- Ran READHEX.COM, selected VGPROG.HEX, selected PIC device #2, and the process went without a hitch and produced a new file called VGPROG.COM.

 

- Next I ran VGPROG.COM and it executed with the prompt to 'Press START to program PIC'

 

- After pressing START, I immediately got the following message...

ERROR invalid device ID.
Detected $3551, expected $3051
Writing address $0006

Press START to program PIC,
SELECT returns to DOS

I've gone back and double checked my programming specs and device ID. All looks good. So now I'm kinda stuck without some sort of guidance as to what is going wrong. Daniel please help :_(

 

- Michael

 

Share this post


Link to post
Share on other sites

I think there is a typo in that last posting. Where the error is shown as "Detected $3551, expected $3051", I don't believe there was a difference. I'll have to confirm this tomorrow, but I think it was actually "Detected $3551 $3051, expected $3051". Of course that makes it even stranger if it's seeing that as an error. After all that would be a match. Have to wait and see :ponder: .

 

- Michael

Share this post


Link to post
Share on other sites

OK so there was a typo in that response message I showed on yesterday's post. This is what I'm actually seeing...

ERROR invalid device ID.
Detected $3051, expected $3051
Writing address $0006

Press START to program PIC,
SELECT returns to DOS

So this response is very odd indeed. Not sure what the problem is, since what it expected for the PIC device ID matched what it detected. Can't do much better than that :sad:

 

- Michael

Share this post


Link to post
Share on other sites

Detected $3051, expected $3051

 

Is the comma part of the detected or just punctuation

 

I believe it's just punctuation, since I remember way back in this thread having a programmer problem that also threw an ID error with the same format (LINK). Thanks for observing that little detail, because it could have been significant to the problem. I PM'ed DMSC to come visit this topic, so hopefully he'll chime in at some point.

 

- Michael

Share this post


Link to post
Share on other sites

Hi!

 

I believe it's just punctuation, since I remember way back in this thread having a programmer problem that also threw an ID error with the same format (LINK). Thanks for observing that little detail, because it could have been significant to the problem. I PM'ed DMSC to come visit this topic, so hopefully he'll chime in at some point.

 

- Michael

The problem is in my assembly code, here: https://github.com/dmsc/atari-picprog/blob/master/picprog.asm#L132

 

The ID read from the PIC is first AND with $FFE0 and then compared with the value given in the C code.

 

This is because some older PICs that I tried, defined the lower bits as the "revision id", so I needed to mask them to avoid errors.

 

Now, your PIC actually has an "1" in the lowest bit, so after the masking the values don't agree.

 

The simple "solution" is to write the ID as 0x3040 in the C code, so the test will pass. A long term solution will be to add a configurable "mask" value to the programming algorithm, and specify it in the C code.

  • Like 1

Share this post


Link to post
Share on other sites

Hi!

 

 

The problem is in my assembly code, here: https://github.com/dmsc/atari-picprog/blob/master/picprog.asm#L132

 

The ID read from the PIC is first AND with $FFE0 and then compared with the value given in the C code.

 

This is because some older PICs that I tried, defined the lower bits as the "revision id", so I needed to mask them to avoid errors.

 

Now, your PIC actually has an "1" in the lowest bit, so after the masking the values don't agree.

 

The simple "solution" is to write the ID as 0x3040 in the C code, so the test will pass. A long term solution will be to add a configurable "mask" value to the programming algorithm, and specify it in the C code.

 

Hi back to you :)

 

Ok I get how the lower bit masking is causing the problem, and the reasons why you did it that way. But I don't follow what you mean by "The simple "solution" is to write the ID as 0x3040 in the C code, so the test will pass.". How does that work, and where in the C code would that exactly go? Are you talking about doing that in the readhex.c code, and if so where exactly?

 

At least it sounds like with a bit of fiddling this can be made to work, which is fantastic!

 

- Michael

 

EDIT: I need this to work to enable programming of the PIC chip that's to be used in my V-Gate project.

Edited by mytekcontrols

Share this post


Link to post
Share on other sites

Hi!

 

Hi back to you :)

 

Ok I get how the lower bit masking is causing the problem, and the reasons why you did it that way. But I don't follow what you mean by "The simple "solution" is to write the ID as 0x3040 in the C code, so the test will pass.". How does that work, and where in the C code would that exactly go? Are you talking about doing that in the readhex.c code, and if so where exactly?

 

At least it sounds like with a bit of fiddling this can be made to work, which is fantastic!

 

- Michael

Simply replace your code:

    { "2: PIC12F1571",  0x3051, 0x0400, 0x8000, 0x8009 },
    { "3: PIC12F1572",  0x3050, 0x0800, 0x8000, 0x8009 },
with:

    { "2: PIC12F1571",  0x3051 & 0xFFE0, 0x0400, 0x8000, 0x8009 }, // Update once picprog.asm is fixed
    { "3: PIC12F1572",  0x3050 & 0xFFE0, 0x0800, 0x8000, 0x8009 },
That should do the trick.

 

Daniel.

  • Like 1

Share this post


Link to post
Share on other sites

Hi!

 

Simply replace your code:

    { "2: PIC12F1571",  0x3051, 0x0400, 0x8000, 0x8009 },
    { "3: PIC12F1572",  0x3050, 0x0800, 0x8000, 0x8009 },
with:

    { "2: PIC12F1571",  0x3051 & 0xFFE0, 0x0400, 0x8000, 0x8009 }, // Update once picprog.asm is fixed
    { "3: PIC12F1572",  0x3050 & 0xFFE0, 0x0800, 0x8000, 0x8009 },
That should do the trick.

 

Daniel.

 

 

----

Modified -- recompiled -- and created new programming file -- used JOY2PIC to successfully flash PIC12F1571 :thumbsup:

 

Download modified readhex.c source: readhex_modified_11-4-2016.zip

(also includes ATR containing new READHEX.COM file)

 

Thanks a bunch Daniel :)

Edited by mytekcontrols
  • Like 1

Share this post


Link to post
Share on other sites

Hi!

 

----

Modified -- recompiled -- and created new programming file -- used JOY2PIC to successfully flash PIC12F1571 :thumbsup:

 

Download modified readhex.c source: attachicon.gifreadhex_modified_11-4-2016.zip

(also includes ATR containing new READHEX.COM file)

 

Thanks a bunch Daniel :)

Good to hear it worked :)

 

If you are a GIT user, you can do a pull-request to my repo at https://github.com/dmsc/atari-picprogwith the modified readhex.c, so the changes are added with proper attribution.

 

Thanks!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. 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...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...