Unable to program flash --- CW says 'Device is secured' even after a full erase

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Unable to program flash --- CW says 'Device is secured' even after a full erase

Jump to solution
1,536 Views
bithacker
Contributor I

Hi,

 

I'm running into some problems trying to program the flash of S09QG8 and S09QE8 devices. I'm using CW 10.1 and a new PEmicro USB Mulitlink programmer. (However, I've tried the same hardware setup with classical CW, and it too refuses to program these two types of microcontrollers)

 

First I click Erase Device, that seems to work fine despite the worrying warnings:

 

 

fl::target -lc "8-kanals analog IO_MC9S08QG8_PnE U-MultiLink"fl::target -b 0x80 0x200fl::target -v off -l off -ie on -i "" -p MC9S08QG8cmdwin::fl::device -d "MC9S08QG8_FLASH" -o "8kx16x1" -a 0xe000 0xffffcmdwin::fl::erase all Beginning Operation ...    ------------------------- Initializing remote connection ...    Performing target initialization ...    Device MC9S08QG8_FLASH is secured    Can't autodetect flash clock divider. Set FCDIV register manually and use Active Debug Context for run configuration in target task.    Erasing .............Erase Command Succeeded.   Device MC9S08QG8_FLASH    cmdwin::fl::blankcheck all Beginning Operation ...    ------------------------- Flash Operation.   Device MC9S08QG8_FLASH     Blank Checking .............BlankCheck Command Succeeded.  

 

Then I click Program with Erase:

 

fl::target -lc "8-kanals analog IO_MC9S08QG8_PnE U-MultiLink"fl::target -b 0x80 0x200fl::target -v off -l off -ie on -i "" -p MC9S08QG8cmdwin::fl::device -d "MC9S08QG8_FLASH" -o "8kx16x1" -a 0xe000 0xffffcmdwin::fl::image -f "Z:\\LOF_Fritid\\Min_kildekode\\workspace_CW\\8-kanals analog IO\\MC9S08QG8\\8-kanalsanalogIO.abs.s19" -t "Auto Detect" -re on -r 0xe000 0xffff -oe offcmdwin::fl::erase image Beginning Operation ...    ------------------------- Auto-detection is successful.     File is of type Motorola S-Record Format.    Initializing remote connection ...    Performing target initialization ...    Device MC9S08QG8_FLASH    Detect frequence ...   Frequence 3971.07 Khz    Erasing .............Erase Command Succeeded.   Device MC9S08QG8_FLASH    cmdwin::fl::write Beginning Operation ...    ------------------------- Flash Operation.  ... Device MC9S08QG8_FLASH     Programming ....Warning.  ...Operation timeout. Protect violation error. Error in command sequence. Device MC9S08QG8_FLASH is secured    Program Command Succeeded    Flash Operation. done 

 

Hm... a warning, and confusing "Device is secured" message.

 

Now comes the problem: If I click Program with Erase a second time, I get this:

 

fl::target -lc "8-kanals analog IO_MC9S08QG8_PnE U-MultiLink"fl::target -b 0x80 0x200fl::target -v off -l off -ie on -i "" -p MC9S08QG8cmdwin::fl::device -d "MC9S08QG8_FLASH" -o "8kx16x1" -a 0xe000 0xffffcmdwin::fl::image -f "Z:\\LOF_Fritid\\Min_kildekode\\workspace_CW\\8-kanals analog IO\\MC9S08QG8\\8-kanalsanalogIO.abs.s19" -t "Auto Detect" -re on -r 0xe000 0xffff -oe offcmdwin::fl::erase image Beginning Operation ...    ------------------------- Auto-detection is successful.     File is of type Motorola S-Record Format.    Initializing remote connection ...    Performing target initialization ...    Device MC9S08QG8_FLASH is secured    Can't autodetect flash clock divider. Set FCDIV register manually and use Active Debug Context for run configuration in target task.   Error:  Erase Command Failed.  Device is secured. Please unsecure or do a mass erase operation. An invalid preference was passed to the GDI protocol plugin(HC GDI Protocol AdapterError: command failed

 and during this step I was also asked to power cycle the device (Problems entering BKGD mode).

The same problem appears if I click on CW's bug symbol in the menu bar (to enter the Debugging mode).

 

Some more info:

- I can effortlessly program 9S08QD4 devices in this HW setup. (Works for CW 10.1 and CW classic.)

- For alle three device types (QD4, QG8 and QE8) I use 3.3 volts for Vdd.

- The PEmicro USM Mulitlink is brand new

- The LEDs on the Usb Mulitlink light up in blue and yellow, as they should.

- I searched the foum for simular problems, but found none.

 

All ideas on how I can debug/solve this issue are appreciated !

 

Thanks!

Labels (1)
Tags (1)
0 Kudos
1 Solution
441 Views
Lundin
Senior Contributor IV

I suppose you should start with the classic BDM troubleshooting steps:

 

- Is the target's clock running? Oscilloscope. If you are using internal clocks, there should be some way to get the internal clock routed to a pin (I don't remember the specifics, it is usually called ECLK).

 

- Ohm meter between the MCU pin and BDM connector. Do this for the BKGD and reset pins both.

 

- Reset pin & BKGD pin may or may not need pull-up. Some (all?) S08 have this pull-up internally. 4k7 or 10k are common values.

 

- Reset pin should have a decoupling cap of 100nF, but not larger than that.

 

- The Vdd pin of the BDM connector needs to be connected to the 3V3 net. PE micro devices use this pin to get the correct logic levels. However, some PE micro pods also draw supply from this pin! At least the older ones did. Make sure your pod is getting its supply from -somewhere-.

View solution in original post

0 Kudos
1 Reply
442 Views
Lundin
Senior Contributor IV

I suppose you should start with the classic BDM troubleshooting steps:

 

- Is the target's clock running? Oscilloscope. If you are using internal clocks, there should be some way to get the internal clock routed to a pin (I don't remember the specifics, it is usually called ECLK).

 

- Ohm meter between the MCU pin and BDM connector. Do this for the BKGD and reset pins both.

 

- Reset pin & BKGD pin may or may not need pull-up. Some (all?) S08 have this pull-up internally. 4k7 or 10k are common values.

 

- Reset pin should have a decoupling cap of 100nF, but not larger than that.

 

- The Vdd pin of the BDM connector needs to be connected to the 3V3 net. PE micro devices use this pin to get the correct logic levels. However, some PE micro pods also draw supply from this pin! At least the older ones did. Make sure your pod is getting its supply from -somewhere-.

0 Kudos