Erasing and Flashing mc9s12xep768

PeterB1 · ‎11-08-2023

I am trying to flash a mc9s12xep768 with USBDM, but memory range 10_0000-10_7FFF does not get erased when using "Mass Erase Now". Only 74_0000-7F_FFFF is erased.

Also flashing 10_0000-10_7FFF is not possible with HCS12 programmer. I get "Program data not within target memory Flash Memory".

74_0000-7F_FFFF works fine.

The .s19's I am flashing are linear. Both are attached.

Setup:

Win10

USBDM-JS16-0001 - DLL 4.12.1.305

USBDM_4_12_1_305

Can someone help or at least point me in the right direction?

pgo · ‎11-11-2023

Following from above:

The range given above is the maximum range shown in the generic memory map. For the mc9s12xep768 the actual DFLASH range is 0x13_F000 - 0x13_FFFF (p36 in ref manual) https://www.nxp.com/products/processors-and-microcontrollers/additional-mpu-mcus-architectures/16-bi....
Your image appears to be outside that range.

If you dump that range you may see invalid data or data from the valid range imaged.

Could you check the correct range please?

This still doesn't explain the mass erase problem. The TCL script that does the erasing, HCS12-XFTMRK-flash-scripts.tcl, uses the NVM_FCMD_ERASE_ALL_BLKS command (0x08) which should erase both flash regions.

PeterB1 · ‎11-11-2023

I dumped 13_F000-13_FFFF and the range does get cleared by mass erase. All bytes FF. Thanks!

Now to the next problem. When trying to flash the same range, I get the following response.

Flashing 74000-7FFFFF is possible though. Could the other range be write protected somehow?

I based 100000-107FFF from the below table in the XEP768 section of the data sheet.

EDIT

I noticed this in the documentation. Is D-flash considered a Block, or should a different erase command than NVM_FCMD_ERASE_ALL_BLKS (0x08) be used? 0x10?

I'm just guessing here though.

pgo · ‎11-12-2023

Hi,

Yes it looks like the memory map information in the Flash specific part of the manual is correct. I can't reconcile this with the the main section which indicates an EE_LOW address of 0x13_F000.

I located a MC912XEP100MAL (chip markings) which is the larger variant of the chip you are using.

After much stuffing around I have concluded that this chip has:

I-Flash 0x700000 0x7FFFFF (agrees with Table 29-2)

D-Flash 0x100000 0x107FFF (agrees with Table 29-6)

Anyway all of the above is irrelevant since the Generic XEP linear image used for the software covers both the maximum range anyway.

OK - to summarise my testing:

- It appears the software correctly programs the above regions on the chip I have BUT

- The handling of linear address is a bit patchy. The stand-alone verify function does not work because it does not handle linear addresses at all (now fixed). This is the used if the verify button on the programmer is selected. The inherent verification done as part of the programming does work.

- The memory dump program does not handle linear addresses at all (Now added) . This makes it easier to do round-trip testing i.e. program an image, read back independently and verify the read-back image.

- UsbdmScript does not handle linear addresses (Now added). This can more easily be used to check memory ranges by probing the device.

I develop and test on Linux so the above applies to that version.

I will build a new installer for windows incorporating the above changes. Please try this version (USBDM_4_12_1_320_Win) and advise of outcome.

Now available on Sourceforge https://sourceforge.net/projects/usbdm/files/Version%204.12.1/Software/

by

PeterB1 · ‎11-19-2023

Hi pgo and sorry for the late response!

I got the chance to test the updated tool yesterday and it works! I managed to flash both memory ranges and they match the flashed files.

...but, this is where I realized something else is missing. Even though the P- & D-flash are correct, the ECU does not work properly. I then started reading the data sheet and think I may have found the issue. The mass erase also clears partition data starting at 0x120000.

This is what I read at 0x1200000 after flashing.

"S21412000000000000000000000000000000000000D9"

If I understood it correctly from the data sheet, it is necessary to perform a "Fullpartition D-Flash Command", flash command 0x0F to fix this.

Online I could find that my ECU should have DFPART=128 and ERPART=16. I then tried modifying your .tcl, but I am in way over my head. Scripting is not really my expertise.

Is this something that could easily be added to the script? I would appreciate any support I can get!

Regards Peter

pgo · ‎11-20-2023

Hi,

I have attached a script to program the partition information.

Unzip this somewhere easy to locate (location needed below)

To use this open UsbdmScript and type the following commands (modify as necessary):

settarget hcs12
openbdm
source partition.tcl (modify path as needed)
partition 64 6

It should report the resulting partition information.

Note the values you suggest (128, 16) appear to be invalid. AFAIKS they do not meet the requirements given in 28.4.2.15 Full Partition D-Flash Command of the manual. Trying to program those values fails.

Some comments:

I only have as small amount of experience with using this style of EEPROM with the Kinetis devices.
In my programs I have always left the DFLASH erased when programming.
The code then self partitions the flash on 1st boot. No need to to do it with the programmer.
Programming the partitioned flash is unlikely to be successful (even if done before partitioning) as the mapping of DFLASH to EEPROM window is dynamic.
Programming after partitioning should be done through the EEPROM window. The programmer does not support this but I guess it might work through UsbdmScript by simply writing to the EEPROM window. I haven't tried.

You may find this app note useful:

https://www.nxp.com/docs/en/application-note/AN3743.pdf

PeterB1 · ‎11-24-2023

Hi pgo!

I got the original ECU and wanted to find out how it is partitioned, and thought I could do it by using the command "queryPartition" in your script. Every time though I get a different response, please see attached log from UsbdmScript.

Is the command only possible to use right after running a Full Partition command?

FYI The P- & D-flash are now correct in the replacement ECU but something is still off. When I test it seems be stuck in a reset-loop. The relays it controls are opening and closing every other second.

Are there maybe other registers I could check to see if anything is indicating an issue?

pgo · ‎11-24-2023

Hi,

queryPartition requires initFlash to have been done beforehand but failure to do this would result in an error message. This only occurs once in the trace you provided so I don't really have any idea.

I have attached an updated script that sets the clock dynamically rather than assuming 8MHz.

Try the following please and see if it gives consistent results (you can modify the tryit function to conveniently try a different sequence):

source partition.tcl
tryit

Again, this has only been tested on the 1 similar chip I have.

bye

PS.

I am not really familiar with this chip so I can't provide in depth comments. You may be able to check if the chip is actually doing a reset by looking at the reset pin. This is driven low by the CPU when an internal reset occurs (1.2.3.2 in manual). Of course it might also be driven low by an external reset source.

If this is the case there are several possible causes (Table 11-16).

Low voltage detect
External Reset
Illegal address
Clock monitor
COP (watchdog)

I don't know if your test ECU could have some defect causing the above (clock or power?). The reset could be from incomplete programming e.g. not programming the entire flash.

In any case it might be useful to post a query on a more general discussion forum. https://community.nxp.com/t5/Product-Forums/ct-p/Products

bye

PPS. Corrected attached file.

PeterB1 · ‎11-24-2023

Hi,

Thank you for the support and for answering all my questions! I will take your advise and ask further questions in the general discussion forum. The changes you made to the USBDM memory dump and HCS12 programmer work as expected, so I guess this topic could be set to solved.

PS. I think you attached the wrong file by accident. It is my readout instead of a script.

Thanks,

Peter

pgo · ‎11-25-2023

Updated the file!
You are welcome to post further questions here. I just think you will reach a wider audience
bye

pgo · ‎11-11-2023

Hi,

I'll check some more tomorrow but for the moment could you try the next device entry:

MC9S12XEP-Linear

and see if it has any effect on the outcome.

Thanks

PeterB1 · ‎11-11-2023

Hi PGO and thanks for replying!

I have played around with the LINEAR-option but I get a similar result. It is when the .s19 contains data in the 10_0000-10_7FFF range, that i get the following response.

I always click the "Mass erase now" first, and from a dump I see that 74_0000-7F_FFFF is erased, all bytes FF. 10_0000-10_7FFF is not erased though, stays the same as before.

PS. I attached a dump of 0-7F_FFFF from the original ECU, if it could be helpful in any way.

pgo · ‎11-11-2023

Hi,

The range 10_0000 - 13_FFFF is EEEPROM (DFLASH).

It should be supported but it may not have been tested with a linear image.

I haven't looked at this is a long while so I will have to see what XEP chip I can find before I can retest this.

bye