Pic ID's veranderen met wisp628

Ik heb hetzelfde probleem met mijn PicAxe programmer. In de source code staat dit:

;   Set User ID Memory
	__idlocs	0x3F80

De hex file ziet er zo uit:

:020000040000FA
:020000001F28B7
:080008000528FC000308FE00BE
:100010000408FD000A08FF00831203130C181920BE
:100020007D0884007F088A007E088300FC0E7C0E19
:100030000900831203138F170C1079140800831220
:1000400003138501203084008001840A841F242842
:100050000630831603139F0020308500831203139C
:1000600080308F008E010F309000A001A10183121B
:10007000031386018C01831603130C140B178B17C3
:100080008312031379184520402883120313791033
:0A009000A00A20080F3985000800BF

:0840000003000F00080000009E

:02400E00F83F79
:00000001FF

In de regel die begint met :84 staat die 3F80, elke keer met 000 ertussen. (Ik gebruik de 16F819) Echter als je dat terug leest krijg je 3F FX, met X de digit. En daar gaat bij mij de verify de mist in. De ID begint op regel 2000, en eindigt op regel 2003.

Op 8 maart 2006 09:23:38 schreef Manvsmachine:
Ik wil graag weten of het mogelijk is de pic id velden te veranderen met de wisp628.

Ik heb dat ooit wel eens getest en toen werkte het volgens mij wel, maar het wordt zo weining gebruikt dat ik er nooit veel aandacht aan heb besteed.

Probeer het eens met xwisp, als dat niet werkt stuur me dan de .hex file (en noem de chip die je gebruikt).

Op 8 maart 2006 12:41:05 schreef Wouter van Ooijen:
[...]

Ik heb dat ooit wel eens getest en toen werkte het volgens mij wel, maar het wordt zo weining gebruikt dat ik er nooit veel aandacht aan heb besteed.

Probeer het eens met xwisp, als dat niet werkt stuur me dan de .hex file (en noem de chip die je gebruikt).

Ik zal het straks thuis even testen met Xwisp. als het daarna nog niet klopt zal ik je even de hex file sturen. De gebruikte PIC is een 18f452

De hex file is hier te downloaden.
http://www.ucapps.de/mios/mios_bootstrap_picstart_workaround_v1.zip
de andere hexfile genoemd in main.asm is hier te vinden:
http://www.ucapps.de/mios/mios_bootstrap_loader_v1_1b.zip

[Bericht gewijzigd door Manvsmachine op woensdag 8 maart 2006 13:41:03 ]

@Wouter van Ooijen: De hex file heb ik eerder al gegeven, ik heb uw programmer wel gebouwd, maar nog niet getest. Ik vermoed dat u dezelfde problemen gaat krijgen, omdat in de hex file er op adres 2000 tot 2003 de hoogste 7 bits altijd logisch 1 zijn gevolgd door 3 logische 0 en dan de ID nibble, en in de hex file er een altijd een 0 op de hoogste 7 bit wordt geschreven. De PIC die ik in gebruik heb is de 16F819

Op 8 maart 2006 13:36:02 schreef Manvsmachine:
De hex file is hier te downloaden.

Klopt het dat die ID bytes alleemaal 0 zijn? Zo ja dan wordt het volgens mij goed geprogrammeerd - getest met een 18F458, maar dat is vrijwel hetzelfde.

>@Wouter van Ooijen: De hex file heb ik eerder al gegeven

dat helpt niet, ik krijg zoveel hex files dus ik gooi ze ook weer weg (of ik weet niet meer wat wat is)

> in de hex file er op adres 2000 tot 2003 (snip) is de 16F819

Ik herinner me dat IDs programmeren met een paar PIC types niet lukte, maar ik heb geen idee meer welke dat waren. Deze discussie gaat over een 18F452.

Op 8 maart 2006 13:48:22 schreef Wouter van Ooijen:
[...]

Klopt het dat die ID bytes alleemaal 0 zijn? Zo ja dan wordt het volgens mij goed geprogrammeerd - getest met een 18F458, maar dat is vrijwel hetzelfde.

het klopt dat ze allemaal 0 zijn. Heb je het met Xwisp getest? want dan zal de fout bij bumblebee zitten waarschijnlijk. De verify functie in bumblebee geeft namelijk ook altijd errors. bij welke pic ik ook gebruik. maarja dat is niet jou programma.

[Bericht gewijzigd door Manvsmachine op woensdag 8 maart 2006 13:55:52 ]

Snap ik, ik bedoelde de hex file eerder in dit topic. Maar ik kan in het datasheet even kijken of de 18F452 dezelfde methode gebruikt. Voor de rest leek het mij een goede achtergrond info, ik denk dat Microchip een beetje heeft zitten slapen op dit punt met de assembler en de 16F818/819

Op 8 maart 2006 13:54:43 schreef LaStei:
Maar ik kan in het datasheet even kijken of de 18F452 dezelfde methode gebruikt.

nee, dat staat in de programming specifications. En die zijn nogal verschillend voor 16F's en 18F's.

Op 8 maart 2006 13:53:44 schreef Manvsmachine:
Heb je het met Xwisp getest?

natuurlijk, andere programma's ken ik niet

Op 8 maart 2006 13:56:40 schreef Wouter van Ooijen:
[...]

natuurlijk, andere programma's ken ik niet

ok ik zal het straks thuis testen. Als de communicatie via midi dan nog niet goed verloopt smijt ik mijn midi interface weg

Mee eens, even in de programming spec opgezocht:

5.0 CONFIGURATION WORD

The PIC18FXX2/XX8 has several configuration words.
These bits can be set or cleared to select various
device configurations. All other memory areas should
be programmed and verified prior to setting configuration
words. These bits may be read out normally, even
after read or code protected.
5.1 ID Locations
A user may store identification information (ID) in eight
ID locations mapped in 200000h:200007h. It is
recommended that the most significant nibble of each
ID be 0Fh. In doing so, if the user code inadvertently
tries to execute from the ID space, the ID data will
execute as NOP.
5.2 Device ID Word
The device ID word for the PIC18FXX2/XX8 is located
at 3FFFFEh:3FFFFFh. These bits may be used by the
programmer to identify what device type is being programmed
and read out normally, even after code or
read protected.

Hier staat nergens in vermeld hoe precies het intern wordt opgslagen. Als dit project waar ik nu aan werk uit de weg is, zal ik eens proberen met de XWISP de 819 met ID te testen, ik houd u op de hoogte.