Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
search inside all forums
Programming 9S12XET512
Jessica D. Aug 19, 2019 at 11:55 AM (11:55 hours)
Staff: Takao Y.

  • Hi there!

    I am doing a remanufacturing project where I am re-programming a 9S12XET512 with a Multilink to the latest flash from a series of dumps of the PFlash, DFlash, and EEE.

    The issue I am seeing is that the DFlash and EEE srec files I have appear to be max memory size (32k and 4k respectively). So I can't set the partition to allow them both to program.

    I read that a dump of the DFlash or EEE will overrun any partition and give you the full memory space of each, but if that were the case I would expect to see replicated data somewhere in my DFlash and EEE files.

    Any idea what's going on or how to properly flash the DFlash and EEE back to a new micro?



  • Greetings,

    There would be replicated data if these memory regions were contiguous, however, they are not.

    DFLASH max partition covers from 0x0010_0000 up to 0x0010_7FFF.
    EEEPROM max partition covers from as low as 0x0013_F000 to 0x0013_FFFF.

    When using Show Module or Upload Module commands, you will get data from the entire region. This is the max memory size srec files you got. If you check your uploaded files using a text editor though, you should see large regions of just "FF" at the end of your DFLASH file which are spaces that were probably cut from the partition. Similarly lots of "FF" at the beginning of your EEEPROM file. You will have to determine where this cutoff is in each file and determine how this device was partitioned. Unfortunately not an easy task.

    Takao Yamada

  • Hi Takao,

    Thanks for the reply.

    Interestingly enough, there is no "blank" space (FF's) at the end of the DFLASH file or at the beginning of the EEEPROM file. Both had data at the very beginning and at the very end. There are blank sectors within both files though.

    I read in the NXP app note AN3490, section 4.2 ( that the EEEPROM is stored as 16 bits of address and 16 bits of data.

    When looking at the DFLASH file, I can confirm that the data here is the EEEPROM data, stored with addresses. However, it's totally not contiguous. For instance a line in the DFLASH file might look like this:
    "bc 28 23 0c bc 2b 01 20 bc 2a ff 20 bc 67 ff 04"

    where the 16 bit words starting with BC are the addresses, and the next 16 bit words are the EEEPROM data. So, in this line, the addresses are "BC 28," "BC 2B," "BC 2A," and "BC 67." Totally not contiguous.

    I'm not sure if this information helps at all, but I'm definitely not seeing how to set up the partitions given this. Any further help would be greatly appreciated.


  • Greetings,

    I do not think contiguous addressing is important in EEEPROM. This memory region typically holds tables and constants and other data that is not changed during the application run. How it is stored is not going to affect the project.

    I do not have any further insight on this without looking at the files themselves.

    Do you not have the original device that the object files are based on? If you do have it, then we could maybe use a debugger software and check the registers that indicate how the partitions are set.

    Takao Yamada

  • Greetings,

    Any update on this?

    Takao Yamada

  • Hi Takao,

    Unfortunately, I could not make any headway on this project.

    I didn't have access to the original hex files used to program the mcu, since this is a remanufacturing job. I only had the hex dumps from using the Multilink and memory views through the Multilink's GUI.

    I didn't attempt to use a debugger because I don't know that I could get one working without prior knowledge of the original IDE or access to the original hex.

    It *appeared* like both the DFLASH and the EEEPROM are using the largest possible partition spaces that each can, but that doesn't make sense since it was outside of the configuration options.

    I tried a few dozen configurations of the partitions and none of them gave me the original hex dumps.

    At that point I was stuck.

  • Greetings,

    The way I would go forward would be to program both files as is and let the partition that it is in now take hold. There is no way to read the current partition from PROG software, but you just have to trust that it was partitioning correctly and that the data you newly programmed is valid within the current configuration.

    Does that make sense to you?

    Takao Yamada

  • Hi Takao,

    Unfortunately, in order to program the DFLASH, I had to set the partitions. There was no way around it. It's a hard stop within the Multilink IDE.

    I also tested the functionality of a few of the different partition configurations with the MCU back in the module, but the module didn't work in any of those scenarios.


  • Greetings,

    I have no further suggestions. Without the original binary file there is nothing else to extract other than what was left in flash when you first got it. Good luck on your project!

    Takao Yamada

  • I appreciate the help! I ended up canceling the project.

Add comment

   Want to comment? Please login or create a new PEmicro account.

© 2020 P&E Microcomputer Systems Inc.
Website Terms of Use and Sales Agreement