On Sat, Jun 12, 2004 at 10:20:08PM -0300, Octavio Nogueira wrote: > >On Sat, 12 Jun 2004 17:06:12 -0400, Byron A Jeff wrote: > > > 2) There's no erase sequence. I noted that the 18F loader did do an erase. > > It's not difficult to do and only requires one extra bit set (FREE) over an > > ordinary write. It should be simple enough. I am unclear if it is required > > though. > > Reading the 16F819 datasheet I can see a note saying you have to erase > the memory prior to writing to it and this is done by setting the FREE bit, > but when you do so it erases a block of 32 words, not only a single word > like 16F87xA. I finally see where you are talking about. It's a note in the Writing Program Memory section 3.7. That's the problem. The 16F87XA doesn't require a separate erase. So the bootloaders that are designed for that part will not translate to the 16F81X or 16F8X without some modification. > > > > My friend, when money is exchanging hands, location doesn't matter. > > > > > Yes, I know but I'm sure a user in USA can effort much more money than a > > > user in Brazil. > > > > Don't be so sure. We all have different circumstances. > > You are right, sorry to mention that. No worries. > > > Also I'd probably continue to battle with Tiny if for no other reason than > > the fact that it's tiny, so there are a very limited number of things that > > can go wrong with it. > > I will and if I success I will share the code with the list. OK now I can help. We need a chip erase routine. Now that the write sequence is going to be shared, we need to separate it from the write loop. Here's the current code: ------------------------- Current Tiny writeloop --------------------- writeloop ; write 2 bytes = 1 instruction clrwdt movf INDF,w movwf EEDATA incf FSR movf INDF,w movwf EEDATH incf FSR BANK3_ ;bank 2->3 bcf EECON1,EEPGD btfss flag,6 ;is eeprom (or flash) bsf EECON1,EEPGD bsf EECON1,WREN movlw 0x55 movwf EECON2 movlw 0xaa movwf EECON2 bsf EECON1,WR nop nop waitwre btfsc EECON1,WR ;for eeprom writes (wait to finish write) goto waitwre bcf EECON1,WREN BANK2_ ;bank2 incf EEADR ;does not cross zones btfss flag,6 ; if writing to EEPROM, skip first counter dec. decf contor decfsz contor goto writeloop goto MainLoop ------------------------------------------------------------------------ OK there are a couple of problems with it. First is that the write sequence is integrated into the loop. The second is that it integrates Program Memory writes with Data memory writes (flag is a copy of the high address. If bit 6 is set, then a write is done to the data EEPROM memory). Let's handle the second problem first. While I'm sure that there are those who have programming data EEPROM memory as a critical resource, it complicates the issue because now since an erase preceeds the write, a hex file that only loads the data EEPROM would in fact erase the program memory! So as a first pass I'm going to temporarily drop data EEPROM write support which will clean up the code a bit. The first problem is pretty simple everything between the BANK3_ and the incf EEADR should be its own write routine. So a simple rearrange: ------------------ Modified/Separated writeloop/write routine --------------- writeloop ; write 2 bytes = 1 instruction clrwdt movf INDF,w movwf EEDATA incf FSR movf INDF,w movwf EEDATH incf FSR call do_write BANK2_ ;bank2 incf EEADR ;does not cross zones ; BAJ pulled the increment back here. erase won't need it decf contor decfsz contor goto writeloop goto MainLoop do_write BANK3_ ;bank 2->3 bcf EECON1,EEPGD bsf EECON1,WREN movlw 0x55 movwf EECON2 movlw 0xaa movwf EECON2 bsf EECON1,WR nop nop waitwre btfsc EECON1,WR ;for eeprom writes (wait to finish write) goto waitwre bcf EECON1,WREN return ------------------------------------------------------------------------ So that was simple enough. Note that the back select for bank2 occurs 3 lines above the writeloop routine. Personally I would have it as the first line of the routine even though it's an extra instruction to execute. Now all that's required is an erase loop routine that'll erase the program memory. Pull it right from the data sheet except use the do_write route above since it's already there. Out of sheer laziness I'll rearrange the erase order a bit. ;-------------------------- erase_mem BANK3_ bsf EECON1,FREE BANK2_ clrf EEADR ; Start at row 0 eloop1 ; bank mem clrf EEADRH ; Count up high address eloop2 call do_write ; All set. Erase a row BANK2_ ; Back to bank2 incf EEADRH,F ; Move to next page btfss EEADRH,3 ; Top of memory test. SEE NOTE BELOW!!!!!! goto eloop2 ; Loop if not at top of memory. movlw 32 ; Add 32 to get to the next row addwf EEADR,F btfss STATUS,Z ;If wrapped to zero then we're done goto eloop1 ; Do the next set of rows. BANK3_ ; Clear FREE bcf EECON1,FREE return ; All done. ;-------------------------- I just rearranged the loops so that I wouldn't have to keep track of the carry. It sets EEADR to an address an does all 8 pages at that fixed address before moving on. So all 0 rows, then all 32 rows, and so on get erased. BTW, the PIC will happily erase the top page (and the bootloader ;-( ). So instead of the bit test I have above, we probably need to do a xorwf test with 6 leaving the top page untouched. All that's left is to call it. Since the PIC has to send a 'K' to get a packet any time between the receipt of the 0xC1 I want to program code and the sending of the 'K' would be an appropriate spot to erase the program memory. That's about it. It's totally untested code, but should be in the ballpark. Feel free to use it and test it out. Easy to test: Stick the 819 in a regular programmer and fill with any old pattern of junk. Then send a empty hex file (or 1 byte) using the bootloader. Recheck the part, and you should find the entire program memory erased. I taking a closer look at Tiny, I see that the firmware has a total dependance on the PC software not to screw up. There's no overwrite protection for the bootloader and no automagic word 0-4 transfer. So it's the job of the PC side to make sure never to do an erroneous operation, otherwise the bootloader couple become inaccessible. Not too bad a tradeoff, but just something to be aware of. IIRC Wouter's bootloaders trusted Murphy to visit and so protected themselves rather vigorously. BAJ -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.