Re: [Usbpicprog-technical] PIC16F73 memory offset.

[Adly A. <ad...@ge...>]

It's every 0x18 bytes. I jury rigged the programming setup on a 
breadboard that I'm now using for another project. So I'm not inclined 
to tear that down to do the file write/read test to see the difference 
between the hex files. I know I have a spare breadboard here somewhere. 
I'll see what I can do over the weekend.

thank you

-- Adly

Oh, BTW, the link to the Ubuntu installer script on the usbpicprog main 
site is broken. I found the script by browsing sourceforge. Thought you 
should know.

On 12/10/2010 04:37 PM, Frans Schreuder wrote:
> Dear Adly Abdullah,
>
> I am sorry that you experience problems with usbpicprog.
> I don't think the actual problem here is reading the firmware, there
> must be a problem while writing since writing is a protocol that occurs
> with 4 bytes at a time for this PIC.
> I guess you are using the latest version (0.4.1) of the software /
> firmware since you have recently purchased it.
> Could you tell me if the problem occurs every 4 bytes, or only every
> 0x18 bytes? That is very important for me to know, because it tells me
> where to look.
> It would also help if you send me the hex file you are trying to
> program, and also the saved hex file which you have read back from the
> 16F73.
>
> I have never heard of any problems with the 16F73, but I guess this is
> not a very popular device that many people have been using.
> I will for now put an X on writing program memory in the supported
> devices section of usbpicprog.
>
> Kind regards,
>
> Frans Schreuder
>
> On 12/09/2010 04:46 PM, Adly Abdullah wrote:
>    
>> This is an issue with PIC16F73
>>
>> I'm not sure if the issue is simply with reading the memory or if it is
>> with programming the PIC but whatever I program into the PIC gets an
>> offset of 4 bytes when read back. For example, say I'm trying to program
>> "8A 11 11 28 ..." it fails verification and when I try to read it back I
>> get "FF 3F FF 3F 8A 11 11 28 ...".
>>
>> Actually, the entire left column is shifted by 4 bytes (which is why I
>> suspect it may simply be a bug in reading the chip) as in it shifts
>> everything at 0x000000 by 4 bytes and everything at 0x001800 by 4 bytes
>> and everything at 0x003000 etc..
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Usbpicprog-technical mailing list
>> Usb...@li...
>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>      
>
>    
>
>
> ------------------------------------------------------------------------------
>    
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>