Copying mc9s12 flash memory with usbdm

[dflash]

I'm trying to copy MC9S12XEP100 with 768k flash module to a new alike one. There is no copy protection.

I'm trying to copy the image from MC9S12XEP100 with 768k flash module to another.

I'm trying to achieve this by using Memory Dump to obtain an image which is then written to the other chip using the HCS12 programmer. 

I have successfully connected with memorydump however I do not know what the width should be this presumably the number of byte read at a time. I have tried with width 1, 2 and 4 getting different results.

Also in memorydump I assume only the memory option table which has start end address and width need to be set and keep empty SRECs ticked? Does paged flash need to be ticked and set to what?

I'm using usbdm 4.12.1.1.29.5

[pgo]

Hi,

Very strange result. That error message indicates that the programmer thinks the chip ID is wrong.  Since you confirmed the ID to start with I can't see why this would be happening.

I tried with the settings you used, on the XEP100 I have, without any problems.

I used the following sequence:

1. Created dummy image occupying all the range.
2. Programmed the chip
3. Read contents
4. Verified with programmer.
5. Mass erased chip
6. Reprogrammed the chip
7. Read contents again
8. The last image was identical to that read previously at 3.

This seems like a thorough check of the programmer and memory dump programs.

Please do the following:

• Use the latest version 4.12.1.340
• Updated the BDM firmware to that supplied with the software

If it is still not working please do the following:

• Run the debug version of the programmer.  To do this you will need to use the command line opened in the binary directory of the USBDM installation.  The command would be UsbdmFlashprogrammer-debug -target=hcs12.  This will create log files in $APPDATA/usbdm. 
• Please post the programmer and usbdm logs please along with the image you are programming.

bye

[dflash]

I'm using  Ver4.12.1.340 in Debug and Linux mint.

I was not sure what I should use to update the firmware for USBDM-JS-SWD-0001, however I have attached the usbdm.log and the p flash I tried to verify.

I could understand if it might not flash but as it is only verify I would have thought the process would be successful as the memorydump is consistent with rereads.

[pgo]

Hi,

To update the firmware use FirmwareChanger.

===========

I have had a look at the logand it appears that it is losing the connection very early in the process.

There are a few minor points I don't understand.

But firstly - can you post the FlashProgrammer.log as well as usbdm.log.

===========

Select Automatically reconnect on the first page of the programmer.

According to the log it is using "status" which is strange since I can't get that option with my setup - probably something I have forgotten.

===========

Can I confirm that you have a 8MHz crystal? Just to check the connection speed is being detected correctly.

===========

Can you do the following sequence so that I have a know comparison:

• Load flash image
• Detect Chip
• Verify

Thanks

[dflash]

Hi

I've done the sequence Load flash image, Detect Chip, Verify with linear image option not selected followed by with selected. The interface options of reconnect and guess target speed were selected too.

I updated the firmware and verified it successfully beforehand.

One thing I noticed when I opened the usbdm hardware was that there was a 12MHz crystal though that does not mean it is operating at that. Perhaps this is the problem?

The same fail message was produced as before.

[pgo]

HI,

I have only had a quick look at the logs so apart from saying that it is not connecting I'm unsure why.  This is strange since the memory dump looks plausible using the same interface.  

Is Chip detect not working?  The connection is failing while try to do this (according to the log).

The 8MHz crystal was referring to the target.  That is implied by the 4MHz connection speed.  The chip I have is using 16MHz but I would not expect that to produce an error.

I might try changing it after you r confirmation.

bye

[dflash]

Hi
yes chip detect is working as it recovers chip id cc92.
A 12MHz crystal has been implemented on the usbdm, I'm not sure what is being used on the target; looking under magnification there is a clear marking of

80. B

It is the component shown top right hand corner on the not very good webcam picture. I think it is the oscillator. Unfortunately I'm not familiar with this type of possibly 3 or 6 pin surface mount module.

It could be 8MHz or unlikely 80.

[pgo]

Hi,

I'm not getting anywhere with looking at this.

I have tried changing the crystal on my board to 8MHz but it made no difference (apart from the obvious connection speed changes).

Tried Vcc=3.3V and 5V

Looking at the log in detail it appears to fail several times with the detect chip before succeeding.  It then fails to connect for the verify.  When it fails it appears to be detecting a communication speed of about 40MHz (80MHz bus clock assuming no changes to BDMSTS.CLKSW) which is out of range for the chip.

From log

 444:Speed = 4000 kHz (1920 ticks, sync=32.0 us)
 530:Speed = 39385 kHz (195 ticks, sync=3.2 us)
 810:Speed = 4000 kHz (1920 ticks, sync=32.0 us)
 896:Speed = 39385 kHz (195 ticks, sync=3.2 us)
1259:Speed = 4000 kHz (1920 ticks, sync=32.0 us)
1546:Speed = 4000 kHz (1920 ticks, sync=32.0 us)
1753:Speed = 3996 kHz (1922 ticks, sync=32.0 us)

About the only reason I can think for this happening is that the device is being reset during communication.

Is is possible that there is an external watchdog on the reset pin?

Sorry but I can't think of anything to try at this stage.

Could you give a description of what exactly you are doing?  Are you replacing a chip in the board or cloning a module?

bye

[pgo · Accepted solution]

Hi,

The XEP supports global addresses so it is easier to do them than paged addresses.

The above settings include the EEPROM (DFlash) and PFlash.

You will need to adjust the ranges to accommodate the specific chip variant you have. The above was tested with a MC9S12XEP100 which has the full 1-24 KByte flash. Use the manual to check the memory ranges using the above as a starting point.

To program the device select MC9S12XEP-linear.

To partially verify your captured image I suggest you use the programmer with the original chip and Verify Flash.  Obviously don't program the device!

bye

[pgo]

PS. Update to a current version of the software if the above doesn't work or looks too different!

[dflash]

Thank you. I managed to now get the memdump working successfully after updating the program with your configuration modified for 768k flash. I have saved with memdump only a section 7C0000 to 7FFFFF for testing.

However I am having trouble when I select the verify flash button with the HC12 programmer as shown in the picture. The picture below shows the memdump setting and status after reading.

I thought maybe the flash had been copied wrong but comparing rereads show the data to be the same.

So I wondered what might wrong to cause the verify failed message?