usbpicprog-technical Mailing List for usbpicprog: Simple USB PIC programmer (Page 9)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi

I have program the bootloader, but no bootloder or programmer found ? Any idea

On Sun, 2010-07-04 at 15:17 +0300, Frans Schreuder wrote:
> Dear James,
> 
> Please let me know whether you succeeded to compile it.
> 
> Kind regards,
> 
> Frans Schreuder

I did get it to compile in the end.

Thanks,

--James.

Dear James,

Please let me know whether you succeeded to compile it.

Kind regards,

Frans Schreuder

2010/6/30 James Goode <ja...@jg...>

> On Wed, 2010-06-30 at 14:04 +0300, Frans Schreuder wrote:
> > Dear James,
> >
> > You need to install libusb 1.0 dev from the repository.
> > Good luck!
> >
> > Frans Schreuder
> >
> >
> I'm using a netbook, and the window is too tall for the screen.  I'm
> trying to adjust it.
>
> --James.
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>

That worked just great, at least with the 18F4550, I'll try with the
18F1220 later on.
Thanks

GC

-----------------------------
This 4k7 to VPP is the problem, because usbpicprog has a 2k2 from the
generator to the output.
Please connect a diode + this 4k7 in stead:

VDD -----|>|-----|||||-----VPP_target

Cheers,

Frans

On 06/21/2010 10:50 AM, Goncalo Costa wrote:
> Hi Frans,
>
> I've tried with a 18F4550 ( this one I'm sure is working fine ), same problem.
> The only thing I have connected to the PIC is a 4K7 from vdd to mclr.
> I've also remade all the solder joints.
> By the way, I'm using latest firmware and software.
>
> Thanks
>

On Wed, 2010-06-30 at 14:04 +0300, Frans Schreuder wrote:
> Dear James,
>  
> You need to install libusb 1.0 dev from the repository.
> Good luck!
>  
> Frans Schreuder
> 
>  
I'm using a netbook, and the window is too tall for the screen.  I'm
trying to adjust it.

--James.

Dear James,

You need to install libusb 1.0 dev from the repository.
Good luck!

Frans Schreuder

2010/6/26, James Goode <ja...@jg...>:
>
> Hi,
>
> I am trying to compile Usbpicprog on Ubuntu 10.04, and I get the
> message:
> main.cpp:32:27: error: libusb.h: No such file or directory
>
> Is libusb.h provided by an Ubuntu package?
>
> Thanks,
>
> --James.
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>

On Sun, 2010-06-27 at 13:59 +0200, Matthijs Kooijman wrote:
> > > libusb-1.0-0-dev libusb-dev
> > I already have both of them installed.
> > 
> > I tried a file search for libusb.h, returned no results.
> On Debian, libusb.h is in libusb-1.0-0-dev. It seems this is also the case for
> Ubuntu (lucid):
> 
> http://packages.ubuntu.com/search?searchon=contents&keywords=libusb.h&mode=exactfilename&suite=lucid&arch=any
> 
> You might need to rerun ./configure after installing libusb.h. 
> 
> If it still does not work, you should probably post your config.log file.
> 
> Gr.
> 
> Matthijs

I didn't run ./configure again...

Thanks,

--James.

> > libusb-1.0-0-dev libusb-dev
> I already have both of them installed.
> 
> I tried a file search for libusb.h, returned no results.
On Debian, libusb.h is in libusb-1.0-0-dev. It seems this is also the case for
Ubuntu (lucid):

http://packages.ubuntu.com/search?searchon=contents&keywords=libusb.h&mode=exactfilename&suite=lucid&arch=any

You might need to rerun ./configure after installing libusb.h. 

If it still does not work, you should probably post your config.log file.

Gr.

Matthijs

On Sat, 2010-06-26 at 18:08 +0100, Jasper Wallace wrote:
> On Sat, 26 Jun 2010, James Goode wrote:
> 
> > Hi,
> > 
> > I am trying to compile Usbpicprog on Ubuntu 10.04, and I get the
> > message:
> > main.cpp:32:27: error: libusb.h: No such file or directory
> > 
> > Is libusb.h provided by an Ubuntu package?
> 
> I'm not sure which one upp will want, so try:
> 
> libusb-1.0-0-dev libusb-dev
> 
> 
I already have both of them installed.

I tried a file search for libusb.h, returned no results.

On Sat, 26 Jun 2010, James Goode wrote:

> Hi,
> 
> I am trying to compile Usbpicprog on Ubuntu 10.04, and I get the
> message:
> main.cpp:32:27: error: libusb.h: No such file or directory
> 
> Is libusb.h provided by an Ubuntu package?

I'm not sure which one upp will want, so try:

libusb-1.0-0-dev libusb-dev

-- 
[http://pointless.net/]                                   [0x2ECA0975]

Hi,

I am trying to compile Usbpicprog on Ubuntu 10.04, and I get the
message:
main.cpp:32:27: error: libusb.h: No such file or directory

Is libusb.h provided by an Ubuntu package?

Thanks,

--James.

This 4k7 to VPP is the problem, because usbpicprog has a 2k2 from the
generator to the output.
Please connect a diode + this 4k7 in stead:

VDD -----|>|-----|||||-----VPP_target

Cheers,

Frans

On 06/21/2010 10:50 AM, Goncalo Costa wrote:
> Hi Frans,
>
> I've tried with a 18F4550 ( this one I'm sure is working fine ), same problem.
> The only thing I have connected to the PIC is a 4K7 from vdd to mclr.
> I've also remade all the solder joints.
> By the way, I'm using latest firmware and software.
>
> Thanks
>   

Hi Frans,

I've tried with a 18F4550 ( this one I'm sure is working fine ), same problem.
The only thing I have connected to the PIC is a 4K7 from vdd to mclr.
I've also remade all the solder joints.
By the way, I'm using latest firmware and software.

Thanks

Dear Vytautas Mackonis,

Your first question is completely normal behaviour, as the bits that
change in your configuration word (bit 9 to 11) are unimplemented on the
12F675 and should read as zero (refer to the 12F675 datasheet on page
54, those bits are marked as "U-0"
The second question should of course not occur, but I would like to have
some more information about it, but I don't think it can be the VPP
voltage as this is not dependent on the operating system.
Could you tell me which version of the software and firmware you are
running? The firmware as well as the software should be upgraded to 0.4.0.

Kind regards,

Frans Schreuder

On 06/21/2010 08:18 AM, Vytautas Mackonis wrote:
> Name: Vytautas Mackonis
>
> Email: vm...@gm...
>
> Subject: Help with programmer
>
> Message: Hello Frans,
>
> i have some problems with usbpicprog, which i purchased few moth ago.
> Now i'm trying program PIC12F675, but with some strange results as
> below:
> 1. Under MAC OS X Leopard 10.6.4 PIC can be programmed without errors,
> but after reading it back i'm getting different configuration word
> (0FA4->01A4). 
> 2. Under Windows XP PIC can be erased or readed, but can't be
> programmed.
> I'm suspecting problem with VPP voltage - are here some solutions?
> Please help me!
>
>
>
>   

Dear Goncalo,

Well, it is difficult to say anything useful about this. Of course VPP
shouldn't go to 8V, but there can be many causes.
First of all, have you tried other target processors, and do they get
the normal ~12V VPP?
If others do work, you have ruled out the circuitry on the usbpicprog
hardware. If not, there might be a wrong soldered connection on the
usbpicprog hardware, or a connection with a higher resistance. But I
don't think that is the case if the voltage does go to 12V with an open
circuit.

Secondly, I would like to know how you connected the 18F1220. Did you
only connect usbpicprog, or is there any other circuit on the target board?

A last option might be a faulty 18F1220, have you tried a second one?

Kind regards,

Frans Schreuder

On 06/20/2010 11:45 PM, Goncalo Costa wrote:
> Hi,
>
> I'm trying to program a PIC18F1220, but when I connect the programmer
> to the PIC, VPP goes 8V.
> When I leave VPP open it goes 12.
> Any sugestions?
> Ideas?
>
> Thanks
>
> Goncalo
>
>   

Hi,

I'm trying to program a PIC18F1220, but when I connect the programmer
to the PIC, VPP goes 8V.
When I leave VPP open it goes 12.
Any sugestions?
Ideas?

Thanks

Goncalo

On 31-5-2010 10:02, Matthijs Kooijman wrote:
> On Mon, May 31, 2010 at 08:50:46AM +0200, Frans Schreuder wrote:
>   
>> Hi Matthijs,
>>
>> The timeout used to be on 5000, but I recently changed it to 1000 due to
>> a bug in the Libusb-1.0 library for Windows. This bug caused the
>> connection to the bootloader to timeout on a re-connect, so I just
>> skipped its error message and reduced the timeout.
>>     
> So the connect to bootloader code simply retries after a timeout or something?
>   
Yep, that's the dirty fix. But maybe if we give the delay as an argument
to readString, we can have a shorter timeout on connect.
>   
>> If this is causing problems, I will put it back on 3000.  btw, I have tested
>> it on Linux Windows and Mac, but never got an error with 1000ms. Probably
>> there is some difference in the hardware.
>>     
> I've just discovered another program that doesn't work with 3000, but does
> work with 5000. Perhaps put it back to 5000?
>
> It also seems the long timeout is only needed for the last block, earlier
> blocks get the reply within 1000ms. In fact, the time until a reply is
> received seems to increase when the last block is shorter (e.g., when there
> are more 0xff's for padding). This seems counter-intuitive: If there is less
> data, it takes longer.
>
> What is the timeout for, exactly? I presume that's the time to wait for the
> pic to finish programming the board and sending an USB reply message? Does it
> also include the time to send the data to the board in the first place, or is
> libusb / writeString synchronous for that? Is there something special the
> firmware does after the last block?
>
>
> Perhaps the timeout should be a parameter to readString, so it can be
> increased for the last block only (or reduced for the bootloader connection
> only, perhaps?) 
>
> Gr.
>
> Matthijs
>   
>
>
> ------------------------------------------------------------------------------
>
>   
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>   

On Mon, May 31, 2010 at 08:50:46AM +0200, Frans Schreuder wrote:
> Hi Matthijs,
> 
> The timeout used to be on 5000, but I recently changed it to 1000 due to
> a bug in the Libusb-1.0 library for Windows. This bug caused the
> connection to the bootloader to timeout on a re-connect, so I just
> skipped its error message and reduced the timeout.
So the connect to bootloader code simply retries after a timeout or something?

> If this is causing problems, I will put it back on 3000.  btw, I have tested
> it on Linux Windows and Mac, but never got an error with 1000ms. Probably
> there is some difference in the hardware.
I've just discovered another program that doesn't work with 3000, but does
work with 5000. Perhaps put it back to 5000?

It also seems the long timeout is only needed for the last block, earlier
blocks get the reply within 1000ms. In fact, the time until a reply is
received seems to increase when the last block is shorter (e.g., when there
are more 0xff's for padding). This seems counter-intuitive: If there is less
data, it takes longer.

What is the timeout for, exactly? I presume that's the time to wait for the
pic to finish programming the board and sending an USB reply message? Does it
also include the time to send the data to the board in the first place, or is
libusb / writeString synchronous for that? Is there something special the
firmware does after the last block?

Perhaps the timeout should be a parameter to readString, so it can be
increased for the last block only (or reduced for the bootloader connection
only, perhaps?) 

Gr.

Matthijs

Dear Matt,

The 12F50X (as well as 16F50x) has a similar algorithm to the 10F
devices. I must admit that I have never seen this device working with
usbpicprog, I have to put some more time in it.
I will put all those devices on "Not working" in stead of unknown on the
supported devices list.
The code to program those devices is also quite different from all the
others, and I am currently also out of 10F devices. I will order some in
the near future (as well as 16F87 which is also causing some problems)
in order to be able to test it myself.

When these bugs have been fixed, I will release 0.4.1 soon.

Kind regards,

Frans Schreuder

On 29-5-2010 2:42, Matt Hirsch wrote:
> I built pcb-0.3.1, (through hole version) and have tested it as working 
> with a couple of different devices (16f84a, 18f2550). I'd like to be 
> able to program the 16f506, which from looking at the programming specs, 
> is very similar to the 12f508/9.
>
> 12f508/509:
> http://ww1.microchip.com/downloads/en/DeviceDoc/41227E.pdf
>
> 16f506
> http://ww1.microchip.com/downloads/en/DeviceDoc/41258C.pdf
>
> I modified index.xml to include the 16F506 under the P12F508 family, and 
> src/hardware.cpp to backup the oscillator calibration bits. I noticed 
> there was already a 16F506.xml under xml_data, which seems to agree with 
> the data sheets.
>
> After recompiling, when I try to read from the 16F506 I get all 0's. 
> Writing to the device gives a "verify error". When I hook a scope up to 
> the PGC and PGD lines I see activity there. The supported devices list 
> says that the 12f508 is not tested, so perhaps the code to program this 
> part isn't working for these chips either?
>
> Can someone recommend a direction to start debugging?
>
> I'm going to try to get a hold of a 12f508/9 to see if that part works, 
> but it could take awhile.
>
> Thanks,
> Matt
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>   

Dear Jasper Wallace,

After writing code or data, the target processor should be reset
completely (VPP goes low)
Unfortunately I don't have a 16F87/88 PIC right now. I will order one
when I have to order other components in order to test it myself.

Frans

On 29-5-2010 18:46, Jasper Wallace wrote:
> On Fri, 28 May 2010, Frans Schreuder wrote:
>
>   
>> > Dear Jasper Wallace,
>> > 
>> > Have you tested the latest build?
>>     
> Still not sure whats going on, but:
>
> If i have all the boxes under Preferences ticked, writing and verifying 
> the config registers fails (writing the data and code works, and can be 
> verified if 'Verify config memory' is unticked).
>
> If i just have 'Write config memory' and 'Verify after programming' ticked 
> it writes the config words ok.
>
> So i guess there is something subtle wrong with the way changing from 
> writing code to writing config is handled or something.
>   

Hi Matthijs,

The timeout used to be on 5000, but I recently changed it to 1000 due to
a bug in the Libusb-1.0 library for Windows. This bug caused the
connection to the bootloader to timeout on a re-connect, so I just
skipped its error message and reduced the timeout. If this is causing
problems, I will put it back on 3000.
btw, I have tested it on Linux Windows and Mac, but never got an error
with 1000ms. Probably there is some difference in the hardware.

Thanks for your message!

Frans

On 30-5-2010 19:26, Matthijs Kooijman wrote:
> Hi,
>
>   
>> > when creating a few initial testing programs, I've been suffering from the
>> > "Hardware should say OK" error message. After some investigation, it seemed as
>> > if some hex files would consistently trigger this message, while others would
>> > consistently work. Some more investigation shows that is the case that the
>> > working programs work _most_ of the time, but not always.
>>     
> I've mucked around in the PC application sources a bit, and it seems the error
> is caused by an USB timeout in readString (which I gathered from adding a
> cout line, since the wxLogError call that is in readString didn't show up
> anywhere for me).
>
> As a hack I tried increasing the USB timeout (USB_OPERATION_TIMEOUT) from
> 1000ms to 3000ms, which magically solved all my problems, including the
> erasure problems (though I've only tested a handful times on the Linux PC, not
> the Windows one).
>
> Could it be that the USB controller is causing this? Both machines I've tested
> on are laptops with very similar hardware.
>
> Gr.
>
> Matthijs
>   

Hi,

> when creating a few initial testing programs, I've been suffering from the
> "Hardware should say OK" error message. After some investigation, it seemed as
> if some hex files would consistently trigger this message, while others would
> consistently work. Some more investigation shows that is the case that the
> working programs work _most_ of the time, but not always.

I've mucked around in the PC application sources a bit, and it seems the error
is caused by an USB timeout in readString (which I gathered from adding a
cout line, since the wxLogError call that is in readString didn't show up
anywhere for me).

As a hack I tried increasing the USB timeout (USB_OPERATION_TIMEOUT) from
1000ms to 3000ms, which magically solved all my problems, including the
erasure problems (though I've only tested a handful times on the Linux PC, not
the Windows one).

Could it be that the USB controller is causing this? Both machines I've tested
on are laptops with very similar hardware.

Gr.

Matthijs

Hi,

when reading the code, I found the following snippet in Hardware::write:

                if(picType->Name.IsSameAs("18F2450")||
                    picType->Name.IsSameAs("18F4450")) blockSizeHW=BLOCKSIZE_CODE_PIC18F2450;
                else if(picType->Name.IsSameAs("18F2221")||
                    picType->Name.IsSameAs("18F2321")||
                    picType->Name.IsSameAs("18F4221")||
                    picType->Name.IsSameAs("18F4321")) blockSizeHW=BLOCKSIZE_CODE_PIC18F2221;
                switch(picType->bitsPerWord())
                {   
                    case 24:
                        blockSizeHW=BLOCKSIZE_CODE_DSPIC;
                        break;
                    default:
                        blockSizeHW=BLOCKSIZE_CODE;
                        break;
                }

AFAICS, the first if/else statement is useless here, since the switch
statement will alwys set blockSizeHW, overriding any value set for those
specific pic types. It seems an "else" is missing here?

Gr.

Matthijs

On Fri, 28 May 2010, Frans Schreuder wrote:

> Dear Jasper Wallace,
> 
> Have you tested the latest build?

Still not sure whats going on, but:

If i have all the boxes under Preferences ticked, writing and verifying 
the config registers fails (writing the data and code works, and can be 
verified if 'Verify config memory' is unticked).

If i just have 'Write config memory' and 'Verify after programming' ticked 
it writes the config words ok.

So i guess there is something subtle wrong with the way changing from 
writing code to writing config is handled or something.

-- 
[http://pointless.net/]                                   [0x2ECA0975]

Hi,

when creating a few initial testing programs, I've been suffering from the
"Hardware should say OK" error message. After some investigation, it seemed as
if some hex files would consistently trigger this message, while others would
consistently work. Some more investigation shows that is the case that the
working programs work _most_ of the time, but not always.

I've attached two examples of a program that works most of the time (around
one in 10 tries failed so far) and another that failed on every try so far.
This was on a 16f876, using a Windows system with usbpicprog 0.4 and brand new
usbpicprog hardware. When the programming fails, I have to replug the
programmer and restart the usbpicprog application.

On a Linux system, both of the attached programs fail every time (while a
blinking led example does work).

The examples include a hex file, together with the .mbas (MikroBasic) file and
(intermediate) assembly file that they were generated from.

On a related note, I'm also seeing errors when erasing every now and then on
the Windows system. On the linux system, these have occured every time so far
(until I disabled "Erase before programming" to make things work). Not sure if
this is related, but I think it is.

Can someone try if these programs are ok or broken for them? It seems that
something in the actual hex code that somehow triggers a (timing) bug in the
usbpicprog firmware. From these examples, you might suspect the length of the
program is relevant (the breaking program is slightly shorter), but I've also
seen breaking programs that are way longer.

I've also tried to use a shorter USB cable, but that didn't seem to matter
much (initially, the problem seemed to increase, but that evened out later
on).

Any suggestions on how to debug this problem?

Gr.

Matthijs

2008	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (2)	Oct (13)	Nov (27)	Dec (23)
2009	Jan	Feb (13)	Mar (24)	Apr (4)	May (11)	Jun (1)	Jul (4)	Aug (1)	Sep	Oct (6)	Nov (5)	Dec (2)
2010	Jan (1)	Feb (22)	Mar (52)	Apr (7)	May (19)	Jun (12)	Jul (9)	Aug (8)	Sep (7)	Oct	Nov (8)	Dec (7)
2011	Jan (12)	Feb (7)	Mar (10)	Apr (14)	May	Jun (1)	Jul	Aug (11)	Sep (5)	Oct (1)	Nov	Dec
2012	Jan (5)	Feb (2)	Mar (6)	Apr (12)	May	Jun (2)	Jul	Aug	Sep	Oct (17)	Nov	Dec
2013	Jan (7)	Feb (6)	Mar (6)	Apr (21)	May (7)	Jun (3)	Jul (2)	Aug	Sep	Oct (1)	Nov	Dec
2014	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (4)	Oct	Nov	Dec
2019	Jan	Feb (3)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2020	Jan	Feb	Mar (5)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec