USBDM and Coldfire V1 Programmer for MCF51JM128 Target

[embeddedprogram]

I am receiving an error programming when it is nearly complete (progress bar past 3/4 way) with "Reason: Program data not within target flash memory"

I am using the latest version--4.10.0 for firmware and dll version 4.10.6100

I am using the included standalone Coldfire V1 Programmer with a known good S-record file which I have attached.

Since this is  128k part, I checked the cfv1_devices.xml file and could not find anything obviously wrong: (see below)

      <device family="CFV1" name="MCF51JM128" subfamily="MCF51JM">

         <clock registerAddress="0xFF8048" type="S08MCGV3" />

         <memoryRef ref="coldfire16K_Ram" />

         <memoryRef ref="coldfireIO" />

         <memory registerAddress="0xFF9820" type="flash" securityAddress="0x0400">

            <securityEntryRef ref="CFV1-default-security" />

            <memoryRange start="0x000000" size="128K" />

         </memory>

         <soptAddress value="0xFF9802" />

         <sdidAddress value="0xFF9806" />

         <sdid value="0x0C16" />

         <sdid value="0x0C17" />

         <tclScriptRef ref="CFV1-default-Scripts" />

         <flashProgramRef ref="CFV1-default-FlashProgram" />

         <projectActionListRef ref="Options-file-list-CFV1" />

         <projectActionListRef ref="Coldfire-V1-ProjectActions" />

      </device>

Any help would be greatly appreciated.    I am using Wytec USBDM under Windows 7 64 bit.

Original Attachment has been moved to: boot.abs.S19.zip

[pgo]

Hi Jeffrey,

The Srec file has data at locations as follows:

	-0.00:	TargetPanel::loadHexFile(): Memory Block[0x000000...0x0001BB]
	-0.00:	TargetPanel::loadHexFile(): Memory Block[0x000200...0x0002C7]
	-0.00:	TargetPanel::loadHexFile(): Memory Block[0x000410...0x003397]
	-0.00:	TargetPanel::loadHexFile(): Memory Block[0x006000...0x00600F]
	-0.00:	TargetPanel::loadHexFile(): Memory Block[0x800428...0x8005FF]
	-0.00:	TargetPanel::loadHexFile(): Memory Block[0x801B78...0x802FFF]

The data at 0x801B78 etc is located in RAM.

The programmer can't program RAM and flags this as an error.

The image would not normally have RAM data unless it was intended for loading on each execution run.  The data is all zero so I suspect the image is accidentally including BSS data.

How are you producing the image?

bye

[embeddedprogram]

It was produced from an xp machine running Codewarrior 6.3 (may have been for debugging).  I am going to rebuild the project and try again.  Thanks for your rapid response.

[embeddedprogram · Accepted solution]

I went to rebuild the application in CodeWarrior 6.3 and found I could use the debugger to program the application successfully (hiwave.exe).   This worked fine and utilized the USBDM after I changed the debugger to CFv1 Open Source BDM. 

This did not remove the RAM references from the S-record file because after I was successful with HI-WAVE I went back to the standalone Coldfire V1 programmer and received the same error as in my initial post. 

But that is not really a problem for me because I can now flash and debug the application using Codewarrior 6.3.

[pgo]

Hi Jeffrey,

I suggest you investigate where the RAM data is coming from.

There may be a problem since any code that relies upon this data area being initialised will function correctly in the debugger but not in the final target.

bye

[embeddedprogram]

The RAM data is coming from the compiler or debugger.  It is initializing RAM to zero.  This is not by our design and I couldn't find any options in Codewarrior 6.3 to turn it off.  Since our code runs fine from a power-on, I don't think we have problems or are expecting RAM to be initialized.

I would like the standalone programmer to simply ignore these RAM directives if possible.

[pgo]

Hi Jeffrey,

The .s19  file produced by a  basic CFV1 project created with Codewarrior 6.3 doesn't contain any data directed to RAM.

Adding various types of global variables doesn't change this.

I'm unsure how it could be done without changing the linker file.

Are you using the standard linker file (.lcf) ?

I'm reluctant to change the operation of programmers since I believe having data directed to RAM indicates an error.  It should not be ignored.

In your case it may be OK.  In other situations it may result in unpredictable behaviour and should not be ignored.

If the project is not confidential I would be interested in examining it to seeing where the data is coming from.  The linker file and map would probably be sufficient.

bye

[embeddedprogram]

Attached please find the linker file and map.  Thanks for your help.

[pgo]

Hi Jeffrey,

I haven't finished looking at the files but there are some obviously strange things I would like to query.

You appear to be using a section description:

  .usb_bdt :
  {
    . = ALIGN(512);
    __BDT_BASE = .;
    *(.usb_bdt)
    __BDT_END = .;
  } >> userram

The intention of this is to place the USB BDTs in RAM at an 512 byte boundary.  This is not occurring.

The relevant part of the map file is shown below (along with the corresponding section description)

__END_SDATA = .;

___DATA_END = .;

    __SDA_BASE = .;        => #>00800428          __END_SDATA (linker command file)
    . = ALIGN (0x4);         
  } >> userram
 
  .usb_bdt :
  {
    . = ALIGN(512);
    __BDT_BASE = .;        => #>00800600          __BDT_BASE (linker command file)
    *(.usb_bdt)
    __BDT_END = .;         => #>00800600          __BDT_END (linker command file)
  } >> userram

  .bss :
  {   
    . = ALIGN (0x4);       => #>00800600          ___BSS_START (linker command file)
    ___BSS_START = .;

                           =>   00800600 00000400 .sbss   mpLineBuffer    (BootMain.c)

From this it can be seen that the contents of the .usb_bdt segment is only due to the alignment statement i.e. the space between the previous segment ending @00800428 and the next 512 byte boundary.

The *(.usb_bdt) line is not matching any contents of your project files.  It is this alignment "filling" that is producing a block of zeros in the RAM file.  This is definitely a strange arrangement and almost certainly not what was intended.

How are you defining the BDTs in the C code?

Very strange.

bye