Searching \ for '[PIC] Table writes past 0x3FFF' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=table
Search entire site for: 'Table writes past 0x3FFF'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Table writes past 0x3FFF'
2007\10\08@034420 by Jinx

face picon face
Can anyone suggest why this table write is successful in MPLAB
but not in the real chip ?

I have several Flash read/write routines for the 18F4550, and I
can't see any address restrictions in the data sheet

An almost identical routine to the one below writes a short-hand
4-digit code number at an indexed address in the $3900 - $3A00
page. At a similarly indexed address from $4400 is meant to be a
text explanation of that code number. For example, if the code
number were written at $3930 ($3900 + 12 * 4), the text would be
written at $44C0 ($4400 + 12 * 16)

This passes all the tests in MPLAB, and any index writes the code
number and text at the correct addresses. If the target address for
text is made eg $3A00, a h/w write is successful. If it's put back to
what I really want, $4400, the text is nowhere to be found in the
chip (I thought it may have been written down at $0400)

Any suggestions ?

TIA

=====================

long_name  set     0x4400

er642    mov      upper(long_name),tblptru ;long name table
        mov      high(long_name),tblptrh
        movfw    prodh
        addwf    tblptrh
        movff    prodl,tblptrl

        bsf      eecon1,eepgd    ;erase 64 bytes
        bcf      eecon1,cfgs
        bsf      eecon1,wren
        bsf      eecon1,free
        bcf      intcon,gie
        mov      0x55,eecon2
        mov      0xaa,eecon2
        bsf      eecon1,wr
        tblrd*-

        mov      .8,temp1         ;outside loop counter
        lfsr     fsr1,scratch+.16 ;RAM buffer
wr_usr2  mov      .8,temp2         ;inside loop counter
ld_buff2 movff    postinc1,tablat  ;copy 8 bytes to write buffer
        tblwt+*
        decfsz   temp2
        bra      ld_buff2

        bsf      eecon1,eepgd     ;write buffer to Flash
        bcf      eecon1,cfgs
        bsf      eecon1,wren
        bcf      intcon,gie
        mov      0x55,eecon2
        mov      0xaa,eecon2
        bsf      eecon1,wr

        decfsz   temp1            ;bump outside counter
        bra      wr_usr2
        bcf      eecon1,wren

ln_end   bra      ln_end


===============================================
If you aren't part of the solution, you're part of the precipitate

2007\10\08@060528 by Hector Martin

flavicon
face
Jinx wrote:
> Any suggestions ?

Sounds to me like $4000-$5FFF is code protected, read protected, or
both. Doublecheck your config fuses. Heck, make sure that the bits that
wind up on the hex file (and chip) really are what you think you are -
programming software might be messing around with them. Also, do a bulk
erase on the chip, since otherwise you won't be able to reset the bits.


--
Hector Martin (spam_OUThectorTakeThisOuTspammarcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

2007\10\08@064220 by Jinx

face picon face
> Sounds to me like $4000-$5FFF is code protected, read protected, or
> both. Doublecheck your config fuses

Look OK

CONFIG  CP0 = OFF, CP1 = OFF, CP2 = OFF, CP3 = OFF
CONFIG  EBTR0 = OFF, EBTR1 = OFF, EBTR2 = OFF, EBTR3 = OFF

and a read from the chip shows all Code and Table protection disabled

2007\10\08@081531 by Alan B. Pearce

face picon face
>Look OK
>
>CONFIG  CP0 = OFF, CP1 = OFF, CP2 = OFF, CP3 = OFF
>CONFIG  EBTR0 = OFF, EBTR1 = OFF, EBTR2 = OFF, EBTR3 = OFF
>
>and a read from the chip shows all Code and Table protection disabled

Checked chip errata sheets ?? No experience with these chips, but ...

2007\10\08@175750 by Jinx

face picon face

> Checked chip errata sheets ??

Yup, no mention.  Oh ..... fairy cakes ;-(

I can't imagine something so sigh-inducing being in the errata
though. It must be me, but not yet seeing what I'm not seeing

For the time being this has nuisance value only and I have to
pretty much ignore it and carry on with more important parts
of the coding. It will eventually impact on the Master Plan and
have to be figured out

I'll ask Microchip and post the resolution

Unless some clever person here spots the problem first

2007\10\08@192121 by Heinz Czychun

flavicon
face
Hi Jinx,

       I'm starting back with PICs after a long hiatus. And have chosen the  
18Fxxxx parts because of the USB capability.

       Before you call uChip, consider. From checking the data sheets,  
although the part, 18F4550, has 32768 Bytes of Program memory, but  
since these a "16bit" parts, then each word is coded into 2 bytes.  
Therefore there are 16384 Words, or 16384 memory locations. 16384 =  
0x4000 which is just the boundary at which your having trouble. Is  
this a possibility?

       The simulator works is probably, because it's not coded for the  
proper memory limit. That would be a uChip bug.

Regards,
Heinz

On 8-Oct-07, at 5:59 PM, Jinx wrote:

>
>> Checked chip errata sheets ??
>
> Yup, no mention.  Oh ..... fairy cakes ;-(
>
> I can't imagine something so sigh-inducing being in the errata
> though. It must be me, but not yet seeing what I'm not seeing
>

2007\10\08@200853 by Jinx

face picon face
Hi Heinz

> although the part, 18F4550, has 32768 Bytes of Program memory,
> but since these a "16bit" parts, then each word is coded into 2 bytes.
> Therefore there are 16384 Words, or 16384 memory locations.
> 16384 = 0x4000 which is just the boundary at which your having
> trouble. Is this a possibility?

I understand what you're suggesting, but that can't be the cause. There
would be other 'can't dos' and manifestations of words vs bytes. Word
width is certainly a consideration for some operations, but not access

For example, hard-coding with org directives past $4000 is, and always
has been, fine

org 0x44c0

data "text"

2007\10\08@225645 by Xiaofan Chen

face picon face
On 10/8/07, Jinx <.....joecolquittKILLspamspam@spam@clear.net.nz> wrote:
{Quote hidden}

I did not read your codes in too much detail but it seems not so
correct.

You might want to read the following C18 codes from PICDEM
FS USB bootloader.

void ReadProgMem(void) //TESTED: Passed
{
   for (counter = 0; counter < dataPacket.len; counter++)
   {
       //2 separate inst prevents compiler from using RAM stack
       byteTemp = *((dataPacket.ADR.pAdr)+counter);
       dataPacket.data[counter] = byteTemp;
   }//end for

   TBLPTRU = 0x00;         // forces upper byte back to 0x00
                           // optional fix is to set large code model
}//end ReadProgMem

void WriteProgMem(void) //TESTED: Passed
{
   /*
    * The write holding register for the 18F4550 family is
    * actually 32-byte. The code below only tries to write
    * 16-byte because the GUI program only sends out 16-byte
    * at a time.
    * This limitation will be fixed in the future version.
    */
   dataPacket.ADR.low &= 0b11110000;  //Force 16-byte boundary
   EECON1 = 0b10000100;        //Setup writes: EEPGD=1,WREN=1

   //LEN = # of byte to write

   for (counter = 0; counter < (dataPacket.len); counter++)
   {
       *((dataPacket.ADR.pAdr)+counter) = \
       dataPacket.data[counter];
       if ((counter & 0b00001111) == 0b00001111)
       {
           StartWrite();
       }//end if
   }//end for
}//end WriteProgMem

void EraseProgMem(void) //TESTED: Passed
{
   //The most significant 16 bits of the address pointer points to the block
   //being erased. Bits5:0 are ignored. (In hardware).

   //LEN = # of 64-byte block to erase
   EECON1 = 0b10010100;     //Setup writes: EEPGD=1,FREE=1,WREN=1
   for(counter=0; counter < dataPacket.len; counter++)
   {
       *(dataPacket.ADR.pAdr+(((int)counter) << 6));  //Load TBLPTR
       StartWrite();
   }//end for
   TBLPTRU = 0;            // forces upper byte back to 0x00
                           // optional fix is to set large code model
                           // (for USER ID 0x20 0x00 0x00)
}//end EraseProgMem

Regards,
Xiaofan

2007\10\08@225903 by Xiaofan Chen

face picon face
On 10/8/07, Jinx <joecolquittspamKILLspamclear.net.nz> wrote:
> Can anyone suggest why this table write is successful in MPLAB
> but not in the real chip ?
>
> I have several Flash read/write routines for the 18F4550, and I
> can't see any address restrictions in the data sheet


The datasheet says the following.

The sequence of events for programming an internal
program memory location should be:
1. Read 64 bytes into RAM.
2. Update data values in RAM as necessary.
3. Load Table Pointer register with address being
erased.
4. Execute the Row Erase procedure.
5. Load Table Pointer register with address of first
byte being written.
6. Write 32 bytes into the holding registers with
auto-increment.
7. Set the EECON1 register for the write operation:
• set EEPGD bit to point to program memory;
• clear the CFGS bit to access program memory;
• set WREN to enable byte writes.
8. Disable interrupts.
9. Write 55h to EECON2.
10. Write 0AAh to EECON2.
11. Set the WR bit. This will begin the write cycle.
12. The CPU will stall for duration of the write (about
2 ms using internal timer).
13. Re-enable interrupts.
14. Repeat steps 6 through 14 once more to write
64 bytes.
15. Verify the memory (table read).
This procedure will require about 8 ms to update one
row of 64 bytes of memory. An example of the required
code is given in Example 6-3.

It seems to me that you do not following all the steps,
specifically step 6.

Xiaofan

2007\10\09@013208 by Jinx

face picon face
> It seems to me that you do not following all the steps,
> specifically step 6

Hi Xiaofan, I can tell you that the routine does actually work. It's
one of several, that differ only in the data and address

Here's the problem I found this afternoon. F*%#ing MPLAB

If you don't specifically clear Program Memory before reading
the chip, anything past $3FFF is not refreshed. Leading you to
the conclusion that the data was not written. And that's why I
believed the write routine for that address range wasn't working

The routine that the write is part of has not been finished, so I was
relying on MPLAB to do the verification for me, via a Read. Now
that I've put some checks in place (primarily using an LCD to display
what's at the write location), I can see that the routine is fine. As I
thought it should be

I shall pass that finding about MPLAB on to Microchip. (Politely)

2007\10\09@015158 by Xiaofan Chen

face picon face
On 10/9/07, Jinx <.....joecolquittKILLspamspam.....clear.net.nz> wrote:

> Here's the problem I found this afternoon. F*%#ing MPLAB
>
> If you don't specifically clear Program Memory before reading
> the chip, anything past $3FFF is not refreshed. Leading you to
> the conclusion that the data was not written. And that's why I
> believed the write routine for that address range wasn't working

Strange. Which version of MPLAR are you using?

> The routine that the write is part of has not been finished, so I was
> relying on MPLAB to do the verification for me, via a Read. Now
> that I've put some checks in place (primarily using an LCD to display
> what's at the write location), I can see that the routine is fine. As I
> thought it should be
>
> I shall pass that finding about MPLAB on to Microchip. (Politely)

Just wondering which programmer are you using?

Xiaofan

2007\10\09@022536 by Jinx

face picon face
> Strange

Yes. Frustrating too

> Which version of MPLAB are you using?

7.50.00.00

> Just wondering which programmer are you using?

PICStart Plus

2007\10\09@022801 by Jinx

face picon face
> Strange

BTW, I believe what I posted is the cause at this stage. Now I can
carry on with the coding. If anything significant emerges from that I'll
let you know

2007\10\09@050016 by Jinx

face picon face
I submitted a Microchip ticket and they helpfully regurgitated
the manual to me. And, as they usually do, completely ignore
the question

I'm happy I found the solution, not them, so I'll sigh, not grrrr

2007\10\09@092233 by Xiaofan Chen

face picon face
On 10/9/07, Jinx <EraseMEjoecolquittspam_OUTspamTakeThisOuTclear.net.nz> wrote:
> I submitted a Microchip ticket and they helpfully regurgitated
> the manual to me. And, as they usually do, completely ignore
> the question
>
> I'm happy I found the solution, not them, so I'll sigh, not grrrr
>

Could you try MPLAB 7.60a or 7.62? Maybe it is a bug with
MPLAB 7.50.

By the way, I think PS+ is not much actively developed by
Microchip. So maybe you want to switch to PICKit 2 instead.

My opionion:
http://forum.microchip.com/tm.aspx?m=287336
http://forum.microchip.com/tm.aspx?m=287314

Xiaofan

2007\10\09@111809 by Howard Winter

face
flavicon
picon face
Xiaofan,

On Tue, 9 Oct 2007 21:21:50 +0800, Xiaofan Chen wrote:

> By the way, I think PS+ is not much actively developed by
> Microchip. So maybe you want to switch to PICKit 2 instead.

I know you're a great fan of the PICkit2 - have you tried the clone version?  I have one, and it seems to be a good clone except that it won't vary the Vdd output
voltage - it sits at the level supplied by the USB port (4.75V in the case I tested) regardless of the setting in the software.  I don't know if this is a fault with this
particular unit, or a design economy!

I do have proper PICkit2s as well, but I liked the idea of the multiple ZIF sockets with just a simple ribbon cable connection - faster than patch-plugging the
Microchip ZIF adaptor, and no chance of getting it wrong and destroying the PIC!  :-)

Cheers,


Howard Winter
St.Albans, England


2007\10\09@170657 by Jinx

face picon face

> Could you try MPLAB 7.60a or 7.62? Maybe it is a bug with
> MPLAB 7.50.

Generally happy with 7.50. Just cheesed off that "it" wasted a lot
of my time yesterday on this one thing. I think there is a functional
bug, because you see something similar with File Registers. They
do update, but you need to scroll up and down to refresh the
window and see the new red characters. Now that I know about
it, may just stick with 7.50 until I take a break

> By the way, I think PS+ is not much actively developed by
> Microchip. So maybe you want to switch to PICKit 2 instead

I have a ProProg too. Never had a problem with the PS+, since
the F84, but it is very slow. Would probably look at adding one
more tool. One other reason being that some projects have two
or more PIC types and it's convenient to have a programmer per
PC per PIC, rather than keep closing/opening Projects on just
one PC


2007\10\09@173322 by Robin Abbott

flavicon
face
I have used this chip with the USB boot loader which obviously works fine
with the other memory locations - although this isn't helpful with your code
which looks fine have you tried the Microchip boot loader ?


Robin Abbott
Forest Electronics - Home of WIZ-C ANSI C Compiler for PIC's with RAD Front
end
robin.abbottspamspam_OUTfored.co.uk
http://www.fored.co.uk


{Original Message removed}

2007\10\09@191315 by Xiaofan Chen

face picon face
On 10/9/07, Howard Winter <@spam@HDRWKILLspamspamh2org.demon.co.uk> wrote:

> On Tue, 9 Oct 2007 21:21:50 +0800, Xiaofan Chen wrote:
>
> > By the way, I think PS+ is not much actively developed by
> > Microchip. So maybe you want to switch to PICKit 2 instead.
>
> I know you're a great fan of the PICkit2 - have you tried the clone version?
> I have one, and it seems to be a good clone except that it won't vary the
> Vdd output voltage - it sits at the level supplied by the USB port
> (4.75V in the case I tested) regardless of the setting in the software.
> I don't know if this is a fault with this particular unit, or a design economy!
>
> I do have proper PICkit2s as well, but I liked the idea of the multiple ZIF
> sockets with just a simple ribbon cable connection - faster than patch-plugging
> the Microchip ZIF adaptor, and no chance of getting it wrong and destroying the PIC!  :-)
>

I do not have a PICkit 2 clone since I have two original PICkit 2 units.

I have a universal programming adapter. It is from a friend who bought an
ICD2 clone. The adapter came free with the ICD2 clone. The Chinses
vendor is selling the adapter at a price of less than US$7.
http://forum.microchip.com/tm.aspx?m=264400

Xiaofan

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...