SuperH emulator
Aug 31, 2006, 03:20 PM
#1
Evolved Member
Thread Starter
SuperH emulator
http://www.lauterbach.com/cgi-bin/do...file=simsh.zip
Just found the above emulator.
When you load up TRACE32, close the windows it comes up with and go to the file menu then "Load" your .hex file. Don't change the CPU type from SH7040 even though it doesn't match. Then View...list source. View...registers.
Reset the PC to 0 and track the first vector.
You can also view...dump from address 0 and then scroll down to the RAM area and it does update appropriately. Peripherals don't seem to emulate, and we don't know the channels they're on either.
Just found the above emulator.
When you load up TRACE32, close the windows it comes up with and go to the file menu then "Load" your .hex file. Don't change the CPU type from SH7040 even though it doesn't match. Then View...list source. View...registers.
Reset the PC to 0 and track the first vector.
You can also view...dump from address 0 and then scroll down to the RAM area and it does update appropriately. Peripherals don't seem to emulate, and we don't know the channels they're on either.
Last edited by jcsbanks; Aug 31, 2006 at 03:38 PM.
Sep 1, 2006, 05:05 AM
#2
Evolved Member
Thread Starter
If you download the http://www.lauterbach.com/cgi-bin/do...ile=monsh7.zip monitor program, then the .per files in there can be put in the directory where you installed TRACE32 and then you can see the peripherals.
Sep 1, 2006, 05:50 AM
#3
Evolved Member
Thread Starter
You can change the CPU type to 7055 as well if you change the direction back to up in the same window. Then close the demo windows and "load" you hex. Then view the peripherals, list the source, see the registers, stack etc. Looks nice.
Sep 1, 2006, 07:35 AM
#6
Evolved Member
Thread Starter
It took a lot of googling to find emulators/simulators for various microcontrollers.
I wondered about doing some resistance checks between known ECU pins and pins on the microcontroller, although they are tiny surface mount pins and my multimeter probe is a little phat
I don't think this would harm it, and we should be able to identify the channels and get labelling better.
I wondered about doing some resistance checks between known ECU pins and pins on the microcontroller, although they are tiny surface mount pins and my multimeter probe is a little phat
I don't think this would harm it, and we should be able to identify the channels and get labelling better.
Trending Topics
Sep 4, 2006, 10:44 AM
#10
Evolving Member
Wow, now comes the reprogramming of the ecu , if you can view the code , then you are effectively disassembling the program. I hate messing with assembly though, you cant change things like you can in C or another language, its yucky. Stupid addressing.
Sep 4, 2006, 10:49 AM
#11
Evolved Member
Thread Starter
I still wonder about rewriting the ECU from scratch. It would probably be easier, except I have no experience/detailed understanding of code to control MIVEC.
The basics to run an engine are not so bad at all, it is getting it into a nice overall package that takes work.
I've already done previous work to make 3d maps chuck out voltages or duty cycles based on RPM and MAP.
The complex stuff is fault checking, OBD, stuff like that.
The basics to run an engine are not so bad at all, it is getting it into a nice overall package that takes work.
I've already done previous work to make 3d maps chuck out voltages or duty cycles based on RPM and MAP.
The complex stuff is fault checking, OBD, stuff like that.
Sep 4, 2006, 11:22 AM
#12
Evolving Member
yeah that would be no easy task. Injector timing, ignition timing, all from scratch?! I had toyed with the idea of a SuperH based ecu which is funny that the actual ecu uses SuperH, but i had probems with software driven pwm for fan/wg solenoid control. Im not sure how the stock ecu handles duty cycle (its probably hardware driven by a register/buffer) and the ecu just sets the value, i didnt have the knowledge to do hardware duty cycle, maybe with a 555 but id need one for each solenoid... ugly.
Sep 4, 2006, 11:36 AM
#13
Evolved Member
Thread Starter
I've done Atmel AVR stuff so the hardware stuff is actually quite intuitive. We're not dealing with a terrible number of signals.
PWM stuff - generally you just set a mode register and then set a compare match signal. The chip double buffers it all for you. Starting PWM is as easy as printing to a display on a microcontroller with integrated hardware.
PWM stuff - generally you just set a mode register and then set a compare match signal. The chip double buffers it all for you. Starting PWM is as easy as printing to a display on a microcontroller with integrated hardware.
Sep 4, 2006, 12:17 PM
#14
Newbie
iTrader: (3)
Join Date: Dec 2005
Location: Seattle, WA
Posts: 87
Likes: 0
Received 0 Likes
on
0 Posts
An emulator is a handy additional tool if you are having trouble understanding what a sequence of instructions does, but in general I prefer to use a disassembler to gain the most understanding of how things work. Unfortunately, that is a tedious process. The problem with emulation is that you must build an accurate model on all of the sensors and actuators (I/O) for the emulation to run in a meaningful way. Even if the emulation runs perfectly, it doesn't always give you insight as to how the system actually works. It's a useful tool to have, I just wouldn't suggest that you look at it as your primary tool.
Sep 4, 2006, 12:28 PM
#15
Evolved Member
Thread Starter
I'm using IDA Pro mainly, trying to decode the serial routines (particular the ones that Evoscan requestIDs get processed by to make their reply) to chuck out the load and then redefine the pointers to the fuel and timing maps to RAM.
Colby, are you willing to share any info on the actuator and sensor channels, and the serial routines?
Colby, are you willing to share any info on the actuator and sensor channels, and the serial routines?