Menu
▾
▴
usbpicprog-technical
|
From: Mark J. <hel...@gm...> - 2010-03-12 20:16:56
|
Hello friends, I've been having some difficulty using the UPP in Windows 7 32-bit. The software and drivers appear to install and run correctly, and the UPP firmware can be updated and verified successfully, but I can not read or write to a target 18LF2553, 16F628, or 16F84A. I'd be happy to test and debug what I can, but admittedly, C++ is not my forté. What happens is, when writing a device, programming always stops near the end of the code block. The hardware freezes with the green and red LEDs lit, and after about four seconds, the following error is displayed: http://img101.imageshack.us/img101/6571/usberror.png At this point, the UPP must be unplugged, the software "Disconnected", the UPP reconnected, and the software "Connected" to re-establish communication. Oddly, "Autodetect" was able to determine every connected PIC. For a read example, this is what happens when I tried reading a working 16F84A. The target "coffee machine" circuit is fully functional and can be ICSP-updated using my old programmer, a PICALL from www.picallw.com. UPP correctly identifies the 16F84A and gives no error reading it, yet returns the following .hex file: :020000040000FA :10000000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F00 :10001000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FF0 :10002000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FE0 ... many more lines following this pattern ... :1001F000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F0F :10020000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FFE :10021000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FEE :1002200000000000000000000000000000000000CE :1002300000000000000000000000000000000000BE :1002400000000000000000000000000000000000AE ... many more lines, etc ... :1003100000000000000000000000000000000000DD :1003200000000000000000000000000000000000CD :1003300000000000000000000000000000000000BD :100340000000000000000030003FFF3FFF3FFF3F84 :10035000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FAD :10036000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F9D :10037000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F8D ... etc ... :1006D000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F2A :1006E000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F1A :1006F000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F0A :1007000000000000000000000000000000000000E9 :1007100000000000000000000000000000000000D9 :1007200000000000000000000000000000000000C9 ... etc ... :1007D0000000000000000000000000000000000019 :1007E0000000000000000000000000000000000009 :1007F00000000000000000000000000000000000F9 :020000040000FA :1042000048004F005400200043004F004600460085 :1042100045004500200048004500520045002100AF :10422000000020004F006E006C007900200031007B :1042300035002000430065006E007400730020000C :1042400020000000200020004600520045005300DE :10425000480020004200520045005700450044003D :104260002000200000002000200049006E007300A4 :10427000650072007400200043006F0069006E004A :020000040000FA :02400E000F00A1 :00000001FF Note that the EEDATA was read correctly! "HOT COFFEE HERE!,0" etc. Below is part of the original .hex file for comparison: :020000040000FA ... legitimate code here ... :0407E000AE20E32B39 :02400E00F93F78 :1042000048004F005400200043004F004600460085 :1042100045004500200048004500520045002100AF :10422000000020004F006E006C007900200031007B :1042300035002000430065006E007400730020000C :1042400020000000200020004600520045005300DE :10425000480020004200520045005700450044003D :104260002000200000002000200049006E007300A4 :10427000650072007400200043006F0069006E004A :00000001FF Any ideas? This is using an ICSP cable about 2cm long, and a quality shielded USB2.0 cable about 2m long. Thanks! Regards, Mark |
|
From: Mark J. <hel...@gm...> - 2010-03-25 19:32:28
|
> Hi Mark, > 2010/3/12 Mark Jones <heliosstudios@...: > > Hello friends, I've been having some difficulty using the UPP in > > Windows 7 32-bit... > > can you retest against latest revision of the trunk? I think r864 > should have fixed the programming problems... > > Francesco Hi Francesco and Frans, yes indeed that helped quite a bit! UPP is now able to read/write/verify/erase the 16F84A, 16F628, and 18LF2553. The erase feature silently does nothing on the 16F628 (expected) and the 18LF2553 (PDIP) can be programmed and read successfully, however its configuration bits behave oddly. This could be my fault as I used a 1m ICSP cable (and it works... amazing.) I will check into this further when I have more time. I am still planning on setting up a build environment, which looks like it will be MSVC. Hopefully once everything is in place, I can help test and verify UPP on several Windows platforms. Regards, Mark |
|
From: Francesco <f18...@ya...> - 2010-03-18 19:24:15
|
Hi Mark, 2010/3/12 Mark Jones <hel...@gm...>: > Hello friends, I've been having some difficulty using the UPP in > Windows 7 32-bit. The software and drivers appear to install and run > correctly, and the UPP firmware can be updated and verified > successfully, but I can not read or write to a target 18LF2553, > 16F628, or 16F84A. I'd be happy to test and debug what I can, but > admittedly, C++ is not my forté. >.... can you retest against latest revision of the trunk? I think r864 should have fixed the programming problems... Francesco |
|
From: Mark J. <hel...@gm...> - 2010-03-24 02:28:59
|
>2010/3/12 Mark Jones <hel...@gm...>: >> Hello friends, I've been having some difficulty using the UPP in >> Windows 7 32-bit. The software and drivers appear to install and run >> correctly, and the UPP firmware can be updated and verified >> successfully, but I can not read or write to a target 18LF2553, >> 16F628, or 16F84A. I'd be happy to test and debug what I can. >>.... > > Hi Mark, > Can you retest against latest revision of the trunk? I think r864 > should have fixed the programming problems... > > Francesco Hi Francesco, today is as good as any to learn some C++ eh? : ) I decided to try setting up a build environment for UsbPicProg. I installed wxDev-C++ v7.3.1.3 on Win7 32-bit (thinking it would be better-suited to developing wxWidgets-based applications), installed TortoiseSVN v1.6.7, retrieved the trunk from SVN, updated the paths to libusb.h, but then got stuck on the wxWidgets dependency. I know it needs the wxWidgets-2.9.0 "libraries" but what exactly needs to go where? The folder tree is rather complex, and wxWidgets can be compiled in an alarming number of ways. Even tried doing "configure" under MSYS. I'll keep plugging away at it, but any additional hints would be very helpful. I can also "build" wxWidgets-2.9.0 according to http://wxdsgn.sourceforge.net/?q=node/9 but I have not tried installing this as a DevPak in wxDev-C++ (and really doubt it would work anyways.) Mark |
|
From: Francesco <f18...@ya...> - 2010-03-24 20:45:34
|
Hi Mark, 2010/3/24 Mark Jones <hel...@gm...>: >>2010/3/12 Mark Jones <hel...@gm...>: > Hi Francesco, today is as good as any to learn some C++ eh? : ) ehm, sorry, I didn't even think that you may not have the full C++ development environment ready for use :) I've updated the installers at: http://usbpicprog.org/downloads/ (look for *r877-release* packages). > I decided to try setting up a build environment for UsbPicProg. I > installed wxDev-C++ v7.3.1.3 on Win7 32-bit (thinking it would be > better-suited to developing wxWidgets-based applications), installed > TortoiseSVN v1.6.7, retrieved the trunk from SVN, updated the paths to > libusb.h, but then got stuck on the wxWidgets dependency. I know it > needs the wxWidgets-2.9.0 "libraries" but what exactly needs to go > where? The folder tree is rather complex, and wxWidgets can be > compiled in an alarming number of ways. Even tried doing "configure" > under MSYS. I'll keep plugging away at it, but any additional hints > would be very helpful. well, if you have wxDevCpp you should have mingw installed. Then you may compile wx just going to wxWidgets\build\msw and typing mingw32-make -f makefile.gcc BUILD=release then you could run exactly the same command from upp_wx\build\win. Anyway I'd suggest you to use MSVC++ 2008 Express instead (specially if you want to compile C++ code often :)). Francesco |
|
From: Frans S. <fra...@gm...> - 2010-03-24 07:47:25
|
Hi Mark, I also used to build usbpicprog with wxDev-C++, but since we switched over to libusb-1.0, it is also better to build the application using Microsoft Visual Studio 2008. (A free version is available). There is an issue with libusb-1.0 and the mingw compiler (I believe especially for the 64 bit version) that made us switch over to MSVC. To build wxWidgets for msvc, you need to do these steps: -download and extract wxWidgets-2.9.0 -download and install MS visual studio 2008 -edit wxWidgets-2.9.0\build\msw\config.vc and change the line "MONOLITHIC = 1" (it used to be 0) -start the "ms Visual Studio 2008 command prompt" which is in fact just cmd.exe with some environment variables set -cd wxWidgets\build\msw -nmake -f makefile.vc -set an environment variable WXWIN with the value c:\wxWidgets-2.9.0 (or wherever you have compiled it) and don't forget to reboot afterwards -now open the right usbpicprog project (usbpicprog\trunk\upp_wx\build\win\upp_wx_vc2008.vcproj) -you might have to set some include directories, or move around with some files if it doesn't compile right away, but in fact it should compile now! Good luck! Frans On 3/24/2010 3:28, Mark Jones wrote: >> 2010/3/12 Mark Jones<hel...@gm...>: >> >>> Hello friends, I've been having some difficulty using the UPP in >>> Windows 7 32-bit. The software and drivers appear to install and run >>> correctly, and the UPP firmware can be updated and verified >>> successfully, but I can not read or write to a target 18LF2553, >>> 16F628, or 16F84A. I'd be happy to test and debug what I can. >>> .... >>> >> Hi Mark, >> Can you retest against latest revision of the trunk? I think r864 >> should have fixed the programming problems... >> >> Francesco >> > Hi Francesco, today is as good as any to learn some C++ eh? : ) I > decided to try setting up a build environment for UsbPicProg. I > installed wxDev-C++ v7.3.1.3 on Win7 32-bit (thinking it would be > better-suited to developing wxWidgets-based applications), installed > TortoiseSVN v1.6.7, retrieved the trunk from SVN, updated the paths to > libusb.h, but then got stuck on the wxWidgets dependency. I know it > needs the wxWidgets-2.9.0 "libraries" but what exactly needs to go > where? The folder tree is rather complex, and wxWidgets can be > compiled in an alarming number of ways. Even tried doing "configure" > under MSYS. I'll keep plugging away at it, but any additional hints > would be very helpful. > > I can also "build" wxWidgets-2.9.0 according to > http://wxdsgn.sourceforge.net/?q=node/9 but I have not tried > installing this as a DevPak in wxDev-C++ (and really doubt it would > work anyways.) > > Mark > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > |
|
From: Frans S. <fra...@gm...> - 2010-03-24 08:59:35
|
Hi Mark, Oops... Francesco has changed something in the .vcproj file, you have to build wxWidgets using MONOLITHIC = 0 now. Frans On 3/24/2010 8:47, Frans Schreuder wrote: > Hi Mark, > > I also used to build usbpicprog with wxDev-C++, but since we switched > over to libusb-1.0, it is also better to build the application using > Microsoft Visual Studio 2008. (A free version is available). > There is an issue with libusb-1.0 and the mingw compiler (I believe > especially for the 64 bit version) that made us switch over to MSVC. > > To build wxWidgets for msvc, you need to do these steps: > -download and extract wxWidgets-2.9.0 > -download and install MS visual studio 2008 > -edit wxWidgets-2.9.0\build\msw\config.vc and change the line > "MONOLITHIC = 1" (it used to be 0) > -start the "ms Visual Studio 2008 command prompt" which is in fact > just cmd.exe with some environment variables set > -cd wxWidgets\build\msw > -nmake -f makefile.vc > -set an environment variable WXWIN with the value c:\wxWidgets-2.9.0 > (or wherever you have compiled it) and don't forget to reboot afterwards > -now open the right usbpicprog project > (usbpicprog\trunk\upp_wx\build\win\upp_wx_vc2008.vcproj) > -you might have to set some include directories, or move around with > some files if it doesn't compile right away, but in fact it should > compile now! > > Good luck! > > Frans > > > On 3/24/2010 3:28, Mark Jones wrote: >>> 2010/3/12 Mark Jones<hel...@gm...>: >>>> Hello friends, I've been having some difficulty using the UPP in >>>> Windows 7 32-bit. The software and drivers appear to install and run >>>> correctly, and the UPP firmware can be updated and verified >>>> successfully, but I can not read or write to a target 18LF2553, >>>> 16F628, or 16F84A. I'd be happy to test and debug what I can. >>>> .... >>> Hi Mark, >>> Can you retest against latest revision of the trunk? I think r864 >>> should have fixed the programming problems... >>> >>> Francesco >> Hi Francesco, today is as good as any to learn some C++ eh? : ) I >> decided to try setting up a build environment for UsbPicProg. I >> installed wxDev-C++ v7.3.1.3 on Win7 32-bit (thinking it would be >> better-suited to developing wxWidgets-based applications), installed >> TortoiseSVN v1.6.7, retrieved the trunk from SVN, updated the paths to >> libusb.h, but then got stuck on the wxWidgets dependency. I know it >> needs the wxWidgets-2.9.0 "libraries" but what exactly needs to go >> where? The folder tree is rather complex, and wxWidgets can be >> compiled in an alarming number of ways. Even tried doing "configure" >> under MSYS. I'll keep plugging away at it, but any additional hints >> would be very helpful. >> >> I can also "build" wxWidgets-2.9.0 according to >> http://wxdsgn.sourceforge.net/?q=node/9 but I have not tried >> installing this as a DevPak in wxDev-C++ (and really doubt it would >> work anyways.) >> >> Mark >> >> ------------------------------------------------------------------------------ >> >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Usbpicprog-technical mailing list >> Usb...@li... >> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical |
|
From: Francesco <f18...@ya...> - 2010-03-24 20:48:33
|
Hi Frans, 2010/3/24 Frans Schreuder <fra...@gm...>: > Oops... Francesco has changed something in the .vcproj file, you have to > build wxWidgets using MONOLITHIC = 0 now. right. Monolithic builds were only introduced for some wxMac-related hacks (I think related to framework building) which are no longer necessary and are "deprecated" in wx2.9... is wxDevCpp distributing a monolithic build of wx? Multilib is the default because it's a lot better (the linker can easily throw away tons of unused features of wx and make a smaller and thus faster executable)... Francesco |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X