Strange WRITECODE behaviour

[HenrikOlsson]

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

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

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

/Henrik.

[mikebar]

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.

[amgen]

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.

[mikebar]

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....

[LinkMTech]

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

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

[mikebar]

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

    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.