MC9S08DZ60 - Error message: Writing operation was unsuccessful. Either the device is defective or not blank

[jesortsan]

Hello,

I'm working with the MC9S08DZ60 microcontroller and its evaluation board EVB9S08DZ60. I have installed CodeWarrior IDE version 5.7.0 (Special Edition) and working with it.

I attach a zip file wich contents 2 CodeWarrior projects:

* PROGRAM_CORRECT: I make (compile and link), debug and load this project into the microcontroller and it works perfectly.

* PROGRAM_FAIL: I make the project (compile and link) and it works, but when I'm going to debug and load it into the microcontroller, the following message appears in the debugger window:

"Program error:
Writing operation was unsuccessful. Either the device is defective or not blank".

The only difference between this 2 projects is that I have added the function "
void programa_OL1_UHF(void)" to the project "PROGRAM_FAIL". All the code is exactly the same in the 2 projects except that function.

Can you help me, please?? I don't know why this error message could be appearing.

Thanks

Message Edited by Alban on 2007-04-20 05:53 PM

PROGRAMS.zip

Message Edited by t.dowe on 2009-10-27 12:29 PM

[neurovous]

I'm getting the same problem with the softec evaluation kit.  Changing the ROM did work.  To me this is not a valid workaround.  Are there any other solutions?

t

[TAH]

Same CW-version and same problem for me. By commenting out a single function the error disappears.
Puzzling...
Anyone else having the same problem or having a good explanation why this happens?
Thanks!
TAH

[jesortsan]

Hello Tah,

when the CW starts to write the code to the micro, at the beginning of the debugger, it can't write some FLASH area (normally the area wich contains the new function, son when you comment it, it works). This is the explanation, but I don't know why it happens.

To solve it, every time I have this problem, I change the ROM segment in the project.prm file. For example, from "0x1900 TO 0xFFAD" to "0x6000 TO 0xFFAD" and it works. Try it!

Regards

[TAH]

Hello jesortsan!
Yes, changing the ROM segment from "0x1900 TO 0xFFAD" to "0x6000 TO 0xFFAD" works for me too. Unfortunately it is a kludge, because there will eventually be a need for the full flash space.


Message Edited by TAH on 2007-06-28 10:44 AM

[jesortsan]

Hello Tah,

you're right: in case of a need for the full flash space, you have a problem.

My application only has a 10Kb size, so I can solve the problem with this little "trick".

By the way, in my case this problem strarted when I introduced some routines to write and erase EEPROM. And in your case?

Probably you'll have more problems like this with your new Flash start address (0x6000). In that case, you can return to your initial address (0x1900) and it will work. (puzzling...)

Best regards

Jesus

[CurtThompson]

I'm having the same problem.  Started when I was playing with EEPROM code.  The segment move appears to work.  Not a good solution for me as I will eventually need a lot of the FLASH space.

Curt

[JimDon]

Just wondering are you all using the SofTec HCS08 BDM?

[CurtThompson]

Yes, I am using the SofTec HCS08 BDM built into the EVB9S08DZ60 Start Kit.  I think I also had the problem with the P&E Micro  USB Multilink but I had other problems as well.  I also put in a MC9S08DN60 (eventually my target micro) and it did the same thing.  Once a FLASH sector or area gets hosed up, it does not seem to recover by moving the ROM segment back to an area that previously had the problem.  It just seems to create a new area with problems.

I'm using Codewarrior Development Studio V 5.9.0 Build 2330.

Curt

[Alban]

Hello,

And you checked in the datasheet that 0x1900 is Flash memory ?
I didn't.
That could explain the problems when reading back if some locations are missing and used for something else.

Alban.

[jesortsan]

Yes, I checked it. Flash memory is from 0x1900 to 0xFFC0.

[bigmac]

Hello,

Did you actually select the correct "derivative" for the project?  Other members of the DZ family have higher starting addresses for flash.

Regards,

Mac

[TAH]

Hello!
The derivative I use is for the HCS08 -> HCS08D family -> MC9S08DZ60 (Connection: SofTec HCS08).

The label on my chip says:
<text snippet start>
PC9S08DZ60
2M05C 8A
ENG SAMPLE
<text snippet end>

In my Project.map -file I found the size limit where the problem occurr.
Not working:
<text snippet start>
ExeFile:
--------
Number of blocks to be downloaded: 7
Total size of all blocks to be downloaded: 1807
<text snippet end>

Working:
<text snippet start>
ExeFile:
--------
Number of blocks to be downloaded: 7
Total size of all blocks to be downloaded: 1799
<text snippet end>


My Project.prm file says:
<text snippet start>
/* This is a linker parameter file for the DZ60 */

NAMES END /* CodeWarrior will pass all the needed files to the linker by command line. But here you may add your own files too. */

SEGMENTS /* Here all RAM/ROM areas of the device are listed. Used in PLACEMENT below. */
    ROM                      =  READ_ONLY    0x1900 TO 0xFFAD;
    Z_RAM                    =  READ_WRITE   0x0080 TO 0x00FF;
    RAM                      =  READ_WRITE   0x0100 TO 0x107F;
    ROM1                     =  READ_ONLY    0x1080 TO 0x13FF;
    EEPROM                   =  NO_INIT      0x1400 TO 0x17FF;
END

PLACEMENT /* Here all predefined and user segments are placed into the SEGMENTS defined above. */
    DEFAULT_RAM                         INTO  RAM;
    DEFAULT_ROM, ROM_VAR, STRINGS       INTO  ROM; /* ROM1 In case you want to use ROM1 as well, be sure the option -OnB=b is passed to the compiler. */
    _DATA_ZEROPAGE, MY_ZEROPAGE         INTO  Z_RAM;
END

STACKSIZE 0x50

VECTOR 0 _Startup /* Reset vector: this is the default entry point for an application. */
VECTOR 11 Timer1_Overflow
VECTOR 22 TEST_ButtonInterrupt
VECTOR 24 I2c_TransactionInterrupt
<text snippet end>

According to the data sheet, the Flash area is 0x1900 TO 0xFFFF (59136 bytes)

TAH