Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

Please accept the use of cookies on our site

At PEmicro we use web browser cookies in order to provide you with an enhanced experience and in order to be able to do things like shopping cart processing and identify you when you login to our website.

Click here to accept

search inside this forum
search inside all forums
Problem with DFLASH memory location in include file
Mark K. Apr 5, 2015 at 09:31 PM (21:31 hours)
Staff: Takao Y.

  • Our design uses a S9S12P32J0MQK microcontroller.  We are using Codewarrior Version 6.1 build 10221.  The include file for this microcontroller (included with Codewarrior) is  We program boards with both a PE Micro USB Multilink Interface (for development) and with a USBDM programmer (in the field).

    One strange thing about the include file is the location of the DFLASH memory:

    DFLASHStart:      equ   $00010400
    DFLASHEnd:      equ   $000113FF

    As this memory location does not exist on the chip.

    At one time the programming procedure would work fine with the Codewarrior and the PE Mirco programmer, but in order to generate an .s19 file that would work with the USBDM programmer, we had to change the location of the DFLASH memory in the include file to a more realistic location:

    DFLASHStart:      equ   $00000400
    DFLASHEnd:      equ   $000013FF

    By subtracting $00010000 from the original DFLASH memory locations in the include file.

    However, recently we have found that we need to change the DFLASH memory locations in the include file to the lower values ($00000400 and $000013FF) in order to make the PE micro programmer & Codewarrior work to program the microcontroller, and we don’t know what to do to create an .s19 file for use with the USBDM programmer. We are not sure what has changed from the previous situation, but it may be that our version of Codewarrior was updated from an older version.

    While I would like to know why the DFLASH address problem exists, a much bigger problem is that we currently have no way to generate an .s19 file that can be used with the USBDM programmer.

    We desperately need, and would sincerely appreciate, help with generating the .s19 files that would work with the USBDM programmer.

    Thank you for any help you can provide.


  • Greetings,

    When generating the S19 file, are you then using this file and using it somewhere else? Or are you using Hiwave to debug? Are you able to use Hiwave for both P&E's multilink and the USBDM?

    Note, P&E's tools must use physical file format (PHY) to be able to program. USBDM might not use physical formatting. You may not be able to use the same compiled object file to work for P&E's and other 3rd party tools.

    I want you to try creating a new project in Codewarrior and just compile the default code with no modifications. Try using P&E's log2phy utility to convert the s19 file to PHY file format (Do not use the PHY file that Codewarrior generates. It is not the correct.):

    Takao Yamada

  • Greetings,

    Any update on this?

    Takao Yamada

    • Hi Takao,

      Thanks for checking back. I did reply to your first response (Comment #2 above), but for some reason it isn't showing up.

      I also contacted Freescale about this problem, and they were able to duplicate the problem. Apparently they are checking into it, but they haven't given me a reason why this is occurring yet. I was hoping they would give me a quick answer so that I could avoid digging into this.

      In my mind there are several questions to be answered:

      1. Why is the DFLASH address in the include file a location that doesn't exist in memory?
      2. Why did this bogus address work for programming with Codewarrior and your USB Multilink Interface (up until recently)?
      3. Why does this bogus address no longer work for programming with Codewarrior and the USB Multilink Interface? (What changed)?
      4. Why does programming with Codewarrior and the USB Multilink Interface suddenly require the DFLASH address to be corrected to actual memory locations?
      4. Why is a different DFLASH address needed for programming with a USBDM programmer and with the PE programmer?
      5. Why does the .s19 file generated with corrected DFLASH locations in the Include file no longer work with the USBDM programmer? (It did work up until recently).
      6. What does the DFLASH address in the include file now need to be in order to generate a .s19 file that will work with the USBDM programmer? (This is the most urgent question at the moment).

      In answer to your questions:
      1.   I’m trying to program two ways: with Codewarrior and the USB Multilink interface, and with a USBDM programmer, using .s19 files generated with Codewarrior.
      2.   I’m not using Hiwave to debug. I’m not familiar with Hiwave. Is this something that might help resolve the problem?
      3.   I’m not familiar with physical file format (PHY), although I just read an entry in a Freescale forum about this. However, I’m pretty sure that the USBDM programmer uses the .s19 file to program, as that is the file type you need to select when programming with this programming software. I appreciate any further insight you can give me on the .phy programming format.
      4.   I have not tried the log2phy utility yet. Given that the USBDM programmer uses the .s19 file, would a conversion from the generated .s19 to a .phy file have any impact on the operation of the USBDM programmer?

      Thanks for any further help you can provide.


  • Greetings,

    Since USBDM is not our product, I cannot answer any questions related to it. I just have no idea. You are asking the wrong people.

    It is not bogus addressing. There is a difference between logical and physical addressing. Please read your chip's reference manual about the memory structure.

    The S19 file that is compiled by Codewarrior is in logical format. Our LOG2PHY utility converts any logical formatted file into physical format. This will help get P&E tools to work. Again, I have no idea what USBDM does. You need to ask Freescale or whoever the tool vendor.

    Takao Yamada

    • Hi Takao,

      I guess the question would then be:

      Why has the PE Micro USB Multilink Interface always worked with Codewarrior to successfully program the S9S12P32J0MQK chip using the supplied include file (with DFLASHstart:   equ $00010400), AND

      why is it now necessary to change the include file so that DFLASHstart:   equ $00000400 to program the same chip?

      The change was sudden and seen on several computers.


  • Greetings,

    Create a new project for your chip and do not change the include file. Try programming and debugging with the P&E multilink and see if it works. This is a good start to figuring out why you are seeing this problem.

    Takao Yamada

  • Greetings,

    Any update on this?

    Takao Yamada

  • Hi Takao

    Sorry for not responding sooner, and thanks for checking back. Unfortunately, the problem is not yet resolved. Freescale has been able to duplicate the problem, but has not gotten back to be with a resolution.


Add comment

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

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