[SOLVED] Error in Programming PIC18F4550 with the K150 PIC programmer

Status
Not open for further replies.

jbrathod88

Junior Member level 3
Joined
Oct 14, 2010
Messages
31
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Location
Ahmedabad, India
Visit site
Activity points
1,556
Hello everyone,

I got K150 PIC programmer. The programmer successfully programs PIC16F877A microcontroller.
But when comes to PIC18F4520 and PIC18F4550 controller, it gives error in verifying the flash at 0x0000 location.

The programmer is supposed to support these two controllers and I follows every steps which are written in its user manual. But till I cannot program any of F4520 or F4550 controller.

Now I wonder if K150 can program "PIC18F" series or not?

Please help me out of this.

Seek for the solution of this.

Thanking you all.
 

Now I wonder if K150 can program "PIC18F" series or not?

According to the Kitsrus site, not many.


Reference: Pic and Atmel Programmers and Microcontrollers Kits

Neither the PIC18F4520 nor PIC18F4550 appear to be listed.


BigDog
 

Do a search for "DIYPack25ep" or "micropro26" to see if you can find them.

Acting on the tip from Brian, thanks Brian, I managed to find the following company's website which seems to have taken over upgrades and support for many of the Kitsrus kits, including the K150. They have the DIYPack25ep update package which includes a firmware upgrade for the K150 and their own programming application which also supports the K150 and both the PIC18F4520 and PIC18F4550.

Micropro Windows software for PIC programmers K128 and K149F

While I was unable to run their app within Windows 7, no matter the compatibility settings, I was able to run the app under a Windows XP VM and confirm its support for the K150, PIC18F4520 and PIC18F4550. You may want to review the included README and their website for any required hardware mods for the K150.

BigDog
 

I'm not sure what the issue with Win7 might be, on my computer with Windows I stuck to XP, it's expensive upgrading to stand still :|. There is a 'gotcha' with the new Micropro software, it only allows COM ports up to COM9 and it has a cap on the number of __CONFIG words it can handle. The device (.cid) file is easy to edit to add new devices but it isn't possible to expand to allow more __CONFIG words, if you add them they are ignored. It limits it's ability to ISCP later devices but the 'EP' version of the file is certainly better than the original one. I tend to use it for 10F and 12F devices and use Pickits for everything else.

Brian.
 

I suspect the compatibility issue is directly related to the method the application is accessing the serial port, as these methods varied widely from one programming language platform to another under Windows XP and many stretched bounds of acceptable practices, with little regard for other applications or the OS.

I'm not sure what the issue with Win7 might be, on my computer with Windows I stuck to XP, it's expensive upgrading to stand still :|.

To the contrary, clinging to outdated equipment with very limited use and having to rely on its legacy application is certainly not moving forward, but standing still. :grin:

Not all us of can run the required applications on a system with a Pentium 90, 512MB of RAM and a 1GB hard drive, these applications require a system which exceeds the 3.5GB of RAM and the two processor limitations of Windows XP Pro, and a more stable OS.

I'm running a Dell T7500 with Dual QuadCore 3.47Ghz Xeons, 48GB of 1333MHz DDR3 ECC RAM, SCA RAID 5 drive system, therefore installing Windows XP so a few legacy apps can be ran in the host OS rather than a Windows XP VM, is really not an option. One of the system's main tasks is to run simulations which can easily consume more than a few gigabytes of memory. Besides, the legacy apps run just fine in a Windows XP VM and I have enough legacy systems laying around to run legacy apps if the need should arise.


BigDog
 

Thanks Brian and BigDog.

Actually I am running the latest version of microbrn software in my PC because I bought this programmer in 2011 and the last update of its software made at 2007 so I just need to re-flash 16F628 controller in programmer with latest hex file and try again.
But as of now, I don't have the new PIC16F628 controller so I cannot upgrade the hex file.
But I will upgrade it and let both of you know.

jaydeep
 

I have a room full of computers, dedicated to various tasks but all normally run Linux. Some are dual boot to XP for 'legacy' applications, I use Windows so little it isn't worth my while 'upgrading'. The system I use for programming isn't quite up to your standard, a 3.4GHz i7 with 6Gb of 1333MHz RAM and SSD for storage but it plods along quite nicely!
I find "Crossover" lets me run most Windows apps in Linux if necessary. The 3.5Gb RAM limit in 32-bit XP doesn't cause any problems with the kind of programs I use but it's nice to know it's all there when running the 64-bit Linux.

Back to the original issue - the COM9 limit seems to be built into the Micropro software. I have an alternative "made in China" board that looks almost identical to the K150 but is USB powered and has it's own VPP generator circuit. It IS compatible with higher COM port numbers but the software isn't compatible with Micropro and is horrendous to operate. The instructions and some of the screen text is in Mandarin!

Brian.
 

Hey :-D

The problem is resolved by upgrading the hex file.

Thank you very much guys. I am now capable to Program both of that controllers by upgrading the hex file of 16F628A controller on the board.

Thanks for guiding me to the right way. I can now proceed further in PIC18F devices.

Jaydeep
 

Status
Not open for further replies.

Similar threads

Cookies are required to use this site. You must accept them to continue using the site. Learn more…