It is currently Sat Jun 06, 2020 1:26 am

All times are UTC

Post new topic Reply to topic  [ 2 posts ] 
Author Message
 Post subject: MC68376 question
PostPosted: Wed Mar 22, 2017 8:05 am 

Joined: Wed Mar 22, 2017 7:49 am
Posts: 1
Let me first introduce myself.
I am Sten, a mechanical engineer with an interest in programming. I am working on the disassembly of a Ducati 998 ECU to be able to change part of the program.
The ECU is a Magneti Marelli using a MC68376 processor. I've found much help in using easy68k to understand the code, but I switched to IDA at some point because there just are so many bytes to analyse.

I used the processor description (pdf) to find specific memory allocation like $FFF100, $FFF080 etc.
At the moment I'm stuck because I can not understand some references in the code.
The Eeprom-file is 3FFFF bytes long, but as you can see there are some references to $44048, $44001 locations.
Now this would be outside of the Eeprom space, so could anybody help me what this reference means.
Thank you for all the help!

68k.png [ 16.12 KiB | Viewed 13704 times ]

 Post subject: Re: MC68376 question
PostPosted: Sun Sep 03, 2017 2:40 pm 

Joined: Sat Jan 09, 2016 9:58 pm
Posts: 24
Sorry for the very late reply. I have some thoughts about memory use in vehicle ECUs.

I believe that this is a complicated topic and would like to admit that I am no expert, so be sure to remain skeptical of my thoughts. I do, however, enjoy talking about ECU disassembly and am having a hard time finding others who want to have a conversation.

I have observed memory management in the Lotus ECU (MC68376 too) ROMs that I have read through which is similar to what you describe. In these ECUs the flash memory is either a AMD AM29F200BB (256k byte - addr up to 0x40000) or AMD AM29F400BB (512k byte - addr up to 0x80000). In spite of this, there is a lot of memory addressing occurring in the 0xfffxxx or 0x8xxxx blocks and the stack pointer is somewhere between these sets of addresses (0xffe800). Also, the ECU memory-read functions allow me to read memory up to 0x100000.

Another interesting note is that the ECU has a 128k HY628100B SRAM chip (this would allow for an extra 0x20000 addresses).

Based on what I have read in the ROM I have the following theory of how the ECU/MC68376 manages memory allocation: as in the MC68376 datasheet set, the 0xfffxxx address range holds control registers which are used to control on-chip functions (DIO, PWM, CAN, SPI, TPU, etc.). I believe that the MC68376 has its own internal memory buffers for these controls (as written in the datasheet).

I've seen that bootloader code will copy itself for runtime to an address outside of the flash memory address range (copied to 0x84000) before acting on flash memory contents as well. The 0x8xxxx block is similarly used during runtime to store variables. It seems likely to me that the 0x80000-0x100000 address range is the SRAM chip, and is used for volatile runtime memory that is not needed to be retained between power cycles (except for when routines copy some of this data back from the 0x8Exxx addresses to flash memory just before power down).

The MC68376 datasheet says that the microcontroller can use a memory virtualization technique that allows the memory space to appear much larger than the physical memory actually is- in that case there is a larger, secondary storage device which holds much of the data and that data is shuffled between the physical memory and the storage device when needed. If this is what is used in the ECU's that I've looked at, I would guess that the addresses in the 0x80000-0x100000 represent SRAM locations (higher speed physical memory), while the 0x0-0x40000 or 0x0-0x80000 (depending on which ECU) are flash memory (the secondary storage device). The program counter cycles through data in the flash memory where the program is stored, sometimes loading data into SRAM for runtime access. At the same time, I believe that variables (computation values, table lookup results, etc.) which are used in runtime will likely be stored in SRAM too.

I'm not sure what to think about the higher address of the stack pointer- it is possible that the programmed address range is not the actual place that it is used - maybe the 0xffe800 address range is mapped to the 0x100000-0x90000 range which is in the SRAM chip in actual runtime use.

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC

Who is online

Users browsing this forum: No registered users and 8 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group