Strange WRITECODE behaviour

Dear Sirs,
I'm facing a strange behaviour using the WRITECODE statement.
Basically I've done a bootloader that starts at $17680 (using PBP) and when it detect it is time for a firmware upgrade it does, copying the new firmware from a FRAM to the chip's memory address from $0000 to $1767F.

At bootloader side, I've set the proper type of variables for using with ERASECODE/WRITECODE (Long for address and Word for the argument).
I'm respecting the rule of the 64 bytes.
Everything looks as it's working perfectly, EXCEPT that only the FIRST 2 BYTE Sat the address $0000 are both kept at the value of $00.
In other words, I can't REALLY MODIFY the value of the first word that is located at the adress $0000.

I've correctly used the ERASECODE (otherwise the first page never will be filled-in with the proper values).
I've double and triple checked if I'm getting the right values from the FRAM and if (of course) I'm correctly starting the filling from the address $0000. Data are correct from the FRAM and I'm actually starting the filling from $0000.
But still the same issue.

I'm using PBP 2.60c and the micro is a 18F4685. Also the great DT interrupts are used here, but I'm switching it off interrupts using:

@ INT_DISABLE RX_UART
GIE = 0
PEIE = 0
RCIE = 0
T1ON = 0 'Disable Timer1

I do the above, before letting the bootloader doing any action on the program memory.

For additional explanation, please look at the attached pictures.

Is there any reason why the WRITECODE act this way or I'm doing something wrong?

Thank you in advance for your help.
Attachment 8119Attachment 8120

Here is a code snippet that show the main stuffs.
Any idea?

Code:

---

' Don't care for Ports and Pin assignment.
' I've removed it for code best reading


DEFINE RESET_ORG 17680h
INCLUDE "modedefs.bas"
DEFINE OSC 20                   
DEFINE I2C_SLOW 1
DEFINE SHIFT_PAUSEUS 1

Flash        var long
x            var long

FW_Bytes      var word
FW_Words      var long
y            var long
programStart  var word
BUFF          var byte[7]
               
    CLEAR
               
    programStart = 0
    FW_Words = $1767E
               
    for x = programStart to $1767F step 64
      Flash = x
      ERASECODE Flash
    next 

    for x = 0 to FW_Words step 2                 
      RAMCS = 0 'SRAM Chip Selected
      SHIFTOUT RAMSI, RAMCLK, MSBFIRST, [$03, x.BYTE2, x.BYTE1, x.BYTE0] ; Send read cmd and address to FRAM
      SHIFTIN RAMSO, RAMCLK, MSBPRE, [BUFF(4)] ; Read data HighByte
      RAMCS = 1 'SRAM Chip NOT Selected

      y = x + 1
      RAMCS = 0 'SRAM Chip Selected
      SHIFTOUT RAMSI, RAMCLK, MSBFIRST, [$03, y.BYTE2, y.BYTE1, y.BYTE0] ; Send read cmd and address
      SHIFTIN RAMSO, RAMCLK, MSBPRE, [BUFF(3)] ; Read data LowByte
      RAMCS = 1 'SRAM Chip NOT Selected
     
      FW_Bytes.lowbyte = BUFF[3]
      FW_Bytes.highbyte = BUFF[4] 'Store the current Word of the new Firmware Code           
     
      Flash = x + programstart
      writecode flash, fw_bytes
     
    next x

---

Thank you.

That's weird. I've never used WRITECODE so I probably won't be of much help but I was thinking:
Erased FLASH contains $FF so, since the data at adress 0 is $00, it looks like "something" is actually writing to that location - just not what's supposed to be there. Have you tried to "manually" write some arbitrary data to the start of the FLASH? Like

Code:

---

WriteCode $0000, $1234
WriteCode $0002, $4567

---

and then read the chip back to see the correct data is being stored.

/Henrik.

Thank you for taking the time to answer.
Seems the problem is much worse.
I get random values in random locations of the Program Area!

Each time I try I get different locations, with different bytes value and with different number of bytes wrong.
So totally messed up!

I've used this in the past and never faced so much problems. The only difference is that now I'm using the (always good) DT Interrupt.
For this reason I thought was enough to mask any interrupt declared, and I do it... but seems not to help.
Or simply I'm looking in a wrong direction.
I've even tryed something like Pause 3 between each WRITECODE sentence but still the same result.

Any (other) idea?

Thank you again.

I think you are trying to change memory locations that are in use at the time by your program...... locations for reset and interrupt vectors are used by basic program..... unless its just data not being used to be stored, bootloader has to run on its very own .....I would think.

Thank you for the answer.
I see your point.
But bootloader code starts at $17680 and do not use any interrupt and not even the DT interrupts.
For the bootloader I've used RESET_ORG $17680
If I see the disassembly there is nothing between $00000 and $1767F

When it is time for the Mainprogram to jump to the bootloader, I execute a
@ goto 0x17680

The booloader code looks at a eeprom location to see if actually is a firmware update to do and if so, then start the writing.
Booloader have also the CLEAR instruction to prevent any data in RAM and I'm also turning off the Global Interrupt bit (GIE = 0)
What keeps alive some portion of the code in the main program, if interrupts are disabled and execution is transferred to $17680, far away from any other portion of the main program?
Also, from the microprocessor datasheet, while writing to the program area, the PC (program counter) is stopped.
I'm really lost now....

I noticed the variable "x" missing I hope will help.

Code:

---

    for x = programStart to $1767F step 64
      Flash = x
      ERASECODE Flash
    next x

---

Quote:

---

Originally Posted by LinkMTech

I noticed the variable "x" missing I hope will help.

Code:

---

    for x = programStart to $1767F step 64
      Flash = x
      ERASECODE Flash
    next x

---

---

Thank you for the answer.
Unfortunately is not that the problem...

I've found that for some reasons, the device showing-up that behaviour (the one I've under test), had the configuration bits named BBSIZ - set to 4K words of the Boot record AND the config bit WRTB (boot block write protection set too!!!)
Seems that this prevent ERASECODE / WRITECODE to deal with the first 4K of code words.

The only one lifesaver is: how to change the configuration bits programmatically?
This topic maybe deserve a different thread...

BTW, thank you for taking time to look at it.