Menu

Using a Northern Software 'Chip' as an External Programmer

mkstevo
2018-11-06
2018-12-12
1 2 3 > >> (Page 1 of 3)
  • mkstevo

    mkstevo - 2018-11-06

    Hello.
    I've been experimenting with the Northern Software system as an external programmer, with the intention to replace MpLab IPE and PICkit2 that I'm currently using. The Northern Software 'programmer' write the .hex file to the PIC so much quicker that it seems unreal, PICkit2 flashes a file in 25-30 seconds, NSDSP in 0.8 seconds.

    I have designed a small PCB which has the NSDSP 'programmer' chip on it, along with a micro USB to interface with the computer, a HVP (High Voltage Programming) interface with four lithium coin cells as a source of the HV and a fully configurable ZIF socket for the target PIC. This all seems to work as a prototype, so the finished PCBs are on order.

    So far, very happy.

    The problem (such as it exists) is that I'd quite like to be able to integrate the Compile and Flash operation into my GCB installation I have on my iMac (at work and at home). I have been able to initiate the command line interface from NSDSP (nsprog) by modifying the 'makehex.sh' script, adding the following line to the script:

    $installdir/nsprog p -h -d "PIC16F1829" -i "$out_name"
    

    This indeed flashes the compiled .hex file using the name that the script generates during compilation: 'out_file'. My confusion is how to parse the name of the chip from the source code #Chip directive, to enter the correct chip name for the '-d' [full device name] parameter of the command.

    Does anyone know of a way of parsing the input file, extracting the #Chip directive to give the device name, finally adding the "PIC" portion of the device name, so that #Chip 16F1829, 32 is translated into PIC16F1829? Simply using "16F1829" doesn't work, the NSDSP system does require the full name. This would make the script file more universal than having the device name hard coded into the script.

    The notes for nsprog do state that the device name could be specified as a comment in the .hex file, but if GCB does include the device name, it doesn't seem to be formatted as nsprog would like as it wasn't found when I tried it.

    The device name may be specified within HEX file with a special
    line starting with semicolon and containing the full device name.
    
     

    Last edit: mkstevo 2018-11-06
  • Anobium

    Anobium - 2018-11-06

    If you use the same parameters as the windows compile option - the parameters will be exposed.

    So, use USEINI "{FileName}" where you then extract and emulate USEINI.BAT .. all will be good.

     
  • mkstevo

    mkstevo - 2018-11-06

    I don't have a Windows installation here so I'll look at that when I get home.

    If I understand you correctly, in my IDE, for my 'Compile HEX and Flash [NSDSP]' entry that I have created in Geany, I can alter the command:

    Users/MkStevo/GCB_Mac/GCB/Compiler/makehex_flash.sh "%f"
    

    Replacing the makehex_flash.sh (which points to my modified makehex.sh script) with USEINI?

    Users/MkStevo/GCB_Mac/GCB/Compiler/USEINI "%f"
    

    Assuming I have copied USEINI into the correct location.

     
  • Moto Geek

    Moto Geek - 2018-11-07

    @mkstevo, are you using the HV circuit described on the northern software website that uses the transistor to switch the HV? Which NS chip are you using in your project?

     
    • mkstevo

      mkstevo - 2018-11-20

      Hello. I'm not using the 'transistor' method as outlined on the Northern Software website. I decided that a simpler way to acheive what I wanted was to use an opto coupler, this give me the flexibility to select either LVP or HVP. I'm using the 14 pin DIP version of the NSDSP 'chip'. Once I get my design working as it should (assuming I do!) I was planning on posting the design files for anyone to use should they wish. I've just returned from a work convention in the US which is why it has taken a while for me to reply, but when I'm back at work I'm going to look at this with serious intent.

       
      • Moto Geek

        Moto Geek - 2018-11-21

        Optocoupler... good idea! I look forward to your design. When I purchased the NS programmer, I added a couple of the 3.3v and 5v chips to play with, so implementing one as a HV programmer would be interesting (and fun). Thanks for your efforts.

         

        Last edit: Moto Geek 2018-11-21
        • mkstevo

          mkstevo - 2018-11-21

          I had some time at work today and managed to build two of the boards, fortunately both worked. I will try to upload the design files (to a new thread) in the next few days.

           
  • George Towler

    George Towler - 2018-11-12

    I'd like to second the above, it's a super fast programmer and the limitation of loosing the PGM pin for LVP is now moot as modern devices do not have that pin and use an alternate methos to enter LVP.

     

    Last edit: George Towler 2018-11-12
    • mkstevo

      mkstevo - 2018-11-20

      Losing a pin is a big deal for me! I'm always short of pins on my designs, especially when driving an LCD display, a few switches, some outputs and a scattering of buttons on a 20 pin device. So for me, HVP is definitely the way forward.

       
  • mkstevo

    mkstevo - 2018-11-21

    Design files and notes uploaded:

    Design files

     

    Last edit: mkstevo 2018-11-21
    • Moto Geek

      Moto Geek - 2018-11-23

      Very nice mkstevo, I will now have to try this. I like the opto idea too! Makes for a nice little additional programmer for the arsenal....

       
  • stan cartwright

    stan cartwright - 2018-11-22

    I have the 14 pin dip version in the post. The chip was £5 but with postage and vat. £12.50, so it's not That cheap.
    I got a 40pin zif that plugs into pickit2/3 but prefer isp. Unless you put the pic in a turned pin dil socket, the pins snap off after pluggin and out a few times.
    I don't think the pics I use, 18f25k22, have lvp so I dug out a chip that boosts 5V to 12V.
    Another toy to play with (:
    edit I got two 16f1454 arrived with PIC18F47K42 Evaluation board They have lvp. Let you know when it arrives.

     

    Last edit: stan cartwright 2018-11-22
    • mkstevo

      mkstevo - 2018-11-22

      I have been using a PicKit2 since starting to work with (native) PIC devices and I have a separate 40pin ZIF socket adapter for the PicKit2. I decided to make two small programmers based on the NSDSP chip. One provides a simple LVP ICSP type interface, the other has the HVP option on it. As the HVP version needed some space for the HVP supply I chose to make it large enough to have the ZIF socket included. I decided on a battery based supply as the majority of the devices I program are from the 16F1825/1829 range (which have a maximum HVP of 9V) and some legacy 16F57 (that have a HVP requirement of 12V). Using four 3V batteries allows simple selection between the two voltage requirements.

      My 'standalone' programmer can easily be used for either programming the bare PIC in the ZIF socket or ICSP, along with the options of LVP, 9V HVP or 12V HVP for either programming method, all optionally powered from the USB interface. The smaller version offers LVP only, though I made an adapter to test the HVP design before committing the circuit to a PCB.

      Not having to faff around with a separate ZIF adapter alone will save my sanity! Never mind the vast speed increase, and once I get it integrated with the IDE I use on my Mac so that I can compile a program and burn it to a device automagically with a simple click of the mouse from within the IDE I won't need to go near MPLabIPE again.

      I thought I paid around £25 for 5 x 14 pin, 5V devices from NSDSP?

       
      • stan cartwright

        stan cartwright - 2018-11-22

        "I thought I paid around £25 for 5 x 14 pin, 5V devices from NSDSP?"
        seems right with discounts, but one chip for £12.50 or a board for £24 is not cheap as made out..but I didn't have to by one.
        When the chip arrives I'll think about ordering several after appraisal.
        The fact that this chip programs everything is not mentioned.
        ps thanks for the circuits and shared enthusiasm.

         

        Last edit: stan cartwright 2018-11-22
  • stan cartwright

    stan cartwright - 2018-11-27

    Hi. The chip arrived so built a board from the circuits in the images.
    Plugged into usb and win7 installed a driver then said driver ready.
    I connected a pic18f25k22 in a zif socket to a pickit2 and erased it. This is supposed to set LVP bit.
    I plugged the pic in a zif into my northern software board and tried to program a hex file but
    got the message..."The device is not talking back, check icsp connection".
    I did and all seems ok. Any ideas what's wrong? Any advice appreciated.

     

    Last edit: stan cartwright 2018-11-27
  • Trev

    Trev - 2018-11-27

    This is supposed to set LVP bit.

    Did you check? It's easy enugh to do so with the PICkit2/+ software.

     
  • stan cartwright

    stan cartwright - 2018-11-27

    Thanks Trev...is it?...does erasing set lvp bit, whatever that is. Microchip data for 18f25k22 doesn't mention lvp, other pics it makes a point of stating has lvp.
    I'll try the pic used by the progammer, I got 2 for the usb and they have lvp. I'll have to write a program for them though first.
    edit - ran pickit2+ and used tools-lvp and erased but ns programmer gives same error.
    I tried a new 16f1454 but got same "not talking" error.
    The win usb must be working and there's not much of a circuit to check.
    I didn't connect rx,tx. Don't know what they're for.

     

    Last edit: stan cartwright 2018-11-28
    • mkstevo

      mkstevo - 2018-11-28

      That is pretty much the circuit for my 'first' programmer, without the HVP option. The Rx and Tx connections are optional, they provide a USB/Serial interface for debugging purposes. On my small programmer, I left them out.

      Testing the LVP version, with the NSDSP software configured for LVP, using an already programmed 16F1829 the NSDSP programmer gives this same error. Looking at the config section of memory in MPLabIPE shows the LVP bit set to off.

      A 'virgin' 16F1829 is listed in MPLabIPE as having the LVP bit set to enable LVP and this can be programmed using the NSDSP software and LVP programmer.

      So.
      Check that your device is set to enable LVP by reading the contents of memory in MPLabIPE and checking the Config area of memory.
      If it is set to allow LVP, check your connections on your programmer, particularly the MCLR pin.
      Check that your programmer is passing the power correctly to the device.
      Check that the NSDSP software is not configured to use HVP.
      Finally check for wiring errors on your programmer.

      The 16F1454 has it's programming pins in a different location to some of the other devices, the pin out for the device shows some optional ICSP connections in the same locations as the 16F1829/1825 devices, but these are not available until the device has been programmed and configured in code to utilise these pins. That has caught me out before!

      With a brand new 16F1829, the NSDSP programmer should be fully capable of programming the device.

       

      Last edit: mkstevo 2018-11-28
      • stan cartwright

        stan cartwright - 2018-11-28

        Thanks for replying.
        I've never used mplab and not trying now.
        I read that the pic18f25k22 can use LVP ie the lvp bit is set when it's erased with pickit2. Microchip don't say that in the data sheet or mention lvp for 18f25k22.
        There's a box in pk2 with about 10 hex numbers in but I don't know what they represent.
        I'll try other pics and see what happens. Is it worth contacting Northern Software?

         
        • Anobium

          Anobium - 2018-11-28

          the simple way to ensure the NS programmer works with respect to resetting the LVP... erase with PICKitPlus

           
        • mkstevo

          mkstevo - 2018-11-28

          I don't use MPLab, but I do use MPLab IPE. It is a standalone version of the programming interface supplied by MicroChip as an optional install with MPLab. It is possible (as I have done) to install MPLab IPE, without installing MPLab.

          And, if you have a Windows installation then the program developed by Anobium, PICKitPlus should offer a second option, as stated by Anobium above.

           
  • stan cartwright

    stan cartwright - 2018-11-28

    Hi again. After a very frustrating afternoon I give up.
    Pickit + and pickit3+ could not see a pic16f1454..same as use for ns programmer.
    I tried using manual pic select in pickit+ and in tools select lvp then erasing but ns programmer said not talking.
    The usb is working and the ns software sees the chip. I think it should work.
    I think I'll post it to Anobium for research.
    As I said, I only use pics because I have some. I prefer arduino board clones, they seem more plug and play with gcb...which is the whole point of gcb I thought, making programming easier.
    I don't have to bother with data sheetsand config bits with arduino, I just get on with writing a program, not an afternoon and none the wiser.
    This is not about ns, it's a rant about pics.

     
    • Anobium

      Anobium - 2018-11-28

      Oh Stan,

      You have picked the 16f1454.. and the pinout is different from the typical Pic. Dont give up.

      Do you want the pinout to hook up any Pic programmer?

       
      • stan cartwright

        stan cartwright - 2018-11-28

        Life's short.
        Image pk2+ is auto detect device on start...it does.
        Image pk2+manselect is manual device selected as lvp needs manual device to work but says can't see device when I've typed it in.
        If I thought I'd spend so much time on this I would have 3d printed something.

         

        Last edit: stan cartwright 2018-11-28
        • mkstevo

          mkstevo - 2018-11-29

          I have just tested this with a 16F1459 (I don't have the 14 pin 1454).

          The first device I tested must have been programmed before as it initially showed LVP as being set off. I then erased the device using my PicKit3 (I think I referred to it being a PicKit2 earlier, it is actually a PicKit3) and re- read the device and the config showed as having LVP set to off.

          Connected this to my NSDSP programmer (with it set for LVP) and it certainly connected to the device, and read it's content correctly.

          The interface of MPLab IPE seems much clearer than that of Stan's PicKit 2+ programming interface?

           

          Last edit: mkstevo 2018-11-29
1 2 3 > >> (Page 1 of 3)

Log in to post a comment.