MC9S12XEG EEE repartitioning problem ?

[adelantesey]

In using EEE of MC9S12XEG128, suppose that there is a wrong partition on D-Flash & Buffer RAM.

Partition-D-Flash command (which is an application level command) wants to reparation D-Flash.

Which command should be launch before Partition-D-Flash command?

Please note that since I’m using cyclonePro for programming micro, it is not possible to launch Erase-All-Block command (because of micro operating mode).

Please kindly review following initialization function and let me know if there is any problem.

Thank you.

bool ETK_boolEEPROMInit(void)

{

  int8u dfPart, erPart;

  while(!FSTAT_CCIF);

  /* Set clock value */ 

  FCLKDIV  = FCLK_DIV_CFG;

  while(!FSTAT_CCIF);

  if(FCLKDIV != (FSTAT_CCIF_MASK | FCLK_DIV_CFG))

      return EEPROM_INIT_FAIL; 

LaunchEepromCommand(0,EEPROM_QUERY,0,0,0);

  if((FSTAT!=FSTAT_CCIF_MASK)||(FERSTAT !=0x00)) 

     return  EEPROM_INIT_FAIL;

  FCCOBIX = 1;

  dfPart = FCCOBLO;

  FCCOBIX++;

  erPart = FCCOBLO;

  if((erPart != EEE_RAM)||(dfPart != DFPART))

  {        

      /* EEPROM hasn't been initialized yet */

      LaunchEepromCommand(2, PARTITION_D_FLASH, 0, DFPART, EEE_RAM);

if((FSTAT!=FSTAT_CCIF_MASK)||(FERSTAT !=0x00)) 

         return EEPROM_INIT_FAIL;

      LaunchEepromCommand(0,EEPROM_QUERY,0,0,0);

if((FSTAT!=FSTAT_CCIF_MASK)||(FERSTAT !=0x00)) 

         return EEPROM_INIT_FAIL;

      FCCOBIX = 1;

      dfPart = FCCOBLO;

      FCCOBIX++;

      erPart = FCCOBLO;

      if((erPart != EEE_RAM)||(dfPart != DFPART))

        return EEPROM_INIT_FAIL;

  }

  LaunchEepromCommand(0,ENABLE_EEPROM_EMULATION,0,0,0);

  if((FSTAT!=FSTAT_CCIF_MASK)||(FERSTAT !=0x00)) 

      return EEPROM_INIT_FAIL;

  return EEPROM_INIT_DONE;

}

[adelantesey]

How can I set operating mode of MC9S12XEG128 to special mdoe?

As far as I know, In order to repartitioning D-Flash for EEE, I should launch full-Partition-D-Flash command.

Since this command could be launch just in special mode, how can I set operating mode of micro in to special mode.

I’ve connected MODA, MODB & MODC pins to GND and power ON micro in order that micro works in special mode.

But it doesn’t work . after power ON CPU stalled and nothing happened.

For your information, I’m using CyclonePro as programmer.

[RadekS]

Special mode:

MODA and MODB should be connected to GND. MODC is handled by BDM interface (BDM interface holds MODC=BKGD pin tied to GND and reset MCU into special mode).

So, if you debug your program step by step, MCU is already in special mode.

Full Partition D-Flash has FCMD value 0x0F. In case of Full Partition D-Flash command you don’t need take care about erased D-Flash, Full Partition D-Flash command will erase D-Flash and restore partition.

Simplest way for erase all blocks is execution of unsecure command file.

Please connect CyclonePro to board and PC, open debugger window, connect to MCU, go to menu-HC12MultilinkCyclonePro-Unsecure-Enter FCLKDIV value (approximately oscillator clock in MHz – 1, for example 9 for 10MHz crystal).

You MCU should be now completely erased and you can apply Full Partition D-Flash command (only in special mode) or Partition D-Flash command (typically during first run in production).

[adelantesey]

thanks for your help,

I’ve tried unsecure command in different way, but sometimes it’s not working.

My units has been programmed by cyclonPro in standalone mode.

At the end of programming, units have been secured by cyclonPro with command “SD, SECURE DEVICE”.

Now I want to change partition of D-Flash with reprogramming new code to units again  by cyclonPro in standalone mode.

So I ticked check box of “Unsecure target if communication fail” as you can see in the attachement.

After reprogramming by CyclonPro, EEE working properly in some of them but not in all of them (about 10% of units has problem in EEE, their EEE behaves like RAM not EEPROM)

If I reprogram again remaining 10% will be alright.

Conclusion:

Some units should be unsecured 2 or 3 times by cyclonPro in order to be able to repartition by partition-D-Flash command.

Is it normal? Is it a problem of my cyclonPro? Or something else?

[RadekS]

From your description it looks like some issue with termination of partitioning command.

Has your software implemented watchdog?

Is there any special time for partitioning of MCU in your programming procedure? (I mean programming, disconnecting BDM, reset MCU to normal mode, wait till partitioning is done,… )

In attachment you can find simple example code for partitioning.

[adelantesey]

No, there is no such timing limit nor watchdog enabled.

Watchdog will be enabled after initialization of EEPROM done successfully.

after unit programming finished by cyclonPro, CPU won’t start until power off and on the micro.

It means that micro working in normal mode, not special mode.

I think there is no reason for termination partitioning.

It seems that unsecuring micro by cyclone don’t erase address 0x12_0000  through 0x12_0007 sometimes (is it possible?).

Failed units (10% I’ve already discussed) has the correct partition but when application writes to buffer RAM, FERSTAT_ERSVIF0 will be set and data won’t transfer to D-flash.

After reprogramming (again unsecure, program & secure) everything going to be alright.

Confusing !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[RadekS]

You are right. It is confusing.

I don’t think that unsecure command could miss erase same data in flash.

It more looks like issue with clock stability or FCLKDIV value (too short time for erasing/program).

Could you please specify follow points?

1. Oscillator circuit (part of schematic)
2. XCLKS pin voltage level
3. PLL settings
4. FCLKDIV value

[adelantesey]

thanks for your following,

1. 1. Oscillator circuit (part of schematic): Attached file
2. 2. XCLKS pin voltage level : this pin used as a push button (low-side) input. In normal condition is 5.35v but when mentioned input is active it will be 0v as obvious. In initialization this input is not active.
3. 3. PLL settings

  static void OSC_Init()

{

   ECLKCTL        = 0xC0;     /* Bit7: NECLK, Bit6: NCLKX2, Bit5: DIV16, Bit4~0: EDIV4~EDIV0  */  

   PLLCTL = 0x00;     /* Bit7: CME, Bit6: PLLON, Bit5: FM1, Bit4: FM0, Bit3: FSTWKP, Bit2: PRE, Bit1: PCE, Bit0: SCME */

CLKSEL         = 0x00;     /* Bit7: PLLSEL, Bit6: PSTP, Bit5: XCLKS, Bit4: 0, Bit3: PLLWAI, Bit2: 0, Bit1: RTIWAI, Bit0: COPWAI */

   /* Fosc =  8MHz   */

   /* Fbus =  16MHz  */  

   /* Fbus =  Fpll/2 */

   /* Fpll = (2*Fosc*[SYNDIV+1])/([REFDIV+1][2*POSTDIV]) */

   SYNR_SYNDIV    = 0x01;     /* Set PLL synthesizer register */

   SYNR_VCOFRQ    = 0x00;     /* VCO frequency range */

   REFDV_REFDV    = 0x00;     /* Set PLL divider register */         

   REFDV_REFFRQ   = 0x02;     /* Reference frequency range */

   POSTDIV        = 0x00;     /* Set CRG postdivider */

   PLLCTL = 0x40;     /* PLL enabled */  

   while(!CRGFLG_LOCK); /* Wait until the PLL is within the desired frequency */

   CLKSEL = 0x80;     /* Bit7: PLLSEL, Bit6: PSTP, Bit5: XCLKS, Bit4: 0, Bit3: PLLWAI, Bit2: 0, Bit1: RTIWAI, Bit0: COPWAI */  

}

1. 4. FCLKDIV value : 7

My current solution for this problem is as follows:

1. At the beginning of production line, all units are unsecured first by CyclonePro then program new application on it.
2. I’ve added EEPROM test routine to EOL tester.
3. If a unit has been failed, it return to step 1.

Do you think is it a reliable solution? Or any idea?

[kef]

• 2. XCLKS pin voltage level : this pin used as a push button (low-side) input. In normal condition is 5.35v but when mentioned input is active it will be 0v as obvious. In initialization this input is not active.

Using XCLKS pin as inpit is tricky. XCLKS defines oscilator mode, Pierce vs loop controlled Pierce. Wiring push button here is quite dangerous. Even if no one presses push button at power up or reset, excess capacitance of push button circuit may make MCU booting with wrong XCLKS mode.

[adelantesey]

Dear Edward & Radek

Thank you very much for your concern.

I’ve tried to simulate error condition. I’ve pushed the button (PE7 = 0) and reset micro by power cycle.

I checked CLKSEL_XCLKS bit. It was zero (based on my oscillator circuit it should be 1). But EEPROM & other parts of software worked as expectation and no error observed.

What is your idea?

What is the observable effect of setting micro in wrong XCLKS mode?