I need help forming a strategy to find execution time
Page 1 of 1

Author:  Obeisance [ Sat Feb 25, 2017 1:49 pm ]
Post subject:  I need help forming a strategy to find execution time

I am working on a disassembly/reverse engineering project. I have read the bootloader code for my MC68376 (CPU32) based microcontroller and believe that I roughly understand the communication protocol for updating the code on the microcontroller. I want to make an external interface for implementing this protocol.

I am having a hard time practically testing the c++ code that I wrote to interface with this microcontroller because of what I perceive as a timing misalignment.

The program-reflashing code does not operate on interrupt routines- instead it checks for a latch condition at startup and if the latch is present it will load the special bootloader reflashing routines into memory and operate on them. It expects a sequence of serial bytes at a specific point in time relative to entering these routines and if it does not receive the correct sequence it will jump to execution of the main code.

Since a delay timer, infinite loop or interrupt routine is not used I am having a hard time aligning the sending of the sequence of serial data (well, this is my perception because when I send these bytes, contrary to what the code should do, I do not receive a response).

I can conceive of two strategies for finding the correct timing-
1) systematically vary the sending of the byte sequence and use trial and error to find the correct timing
2) calculate program execution time in order to figure out how long after power on the byte sequence should be sent

Strategy 1 seems too open ended and hard to control- the power-on switch for the microcontroller is not electrically coupled to the external program timing for the byte sending routine, so too much timing variation would be introduced to get high resolution control over the delay before sending the byte sequence.

Strategy 2 would be ideal, but when I try to find explanations for MC68k instruction execution timing I see that it varies by processor type- the MC68K has very straightforward execution time, but something like a MC68020 (which was the closest to the CPU32 that I could find) has listed 'best case' and 'worst case' timing for each operation. If I use the 68K timing it would likely be wrong for the 68376 that is in my microcontroller, and if I use the 68020 timing I could only come up with a range of times.

If anyone has suggestions for other strategies to try, or knows better how to find execution time, I would greatly appreciate your input.

Author:  Plasmo [ Sat Feb 25, 2017 3:32 pm ]
Post subject:  Re: I need help forming a strategy to find execution time

The back of CPU32 Reference shows the instruction timing of CPU32 instruction. Timing calculation is complicated due to instruction pipeline. The wait state of external devices can also affect the instruction timing.

IMO, the biggest uncertainty is the startup time of crystal or external oscillator which will vary for every power-up cycle, from 20mS to 200mS, depending on the crystal. So if you have access to the reset pin and can synchronize with the negation of reset, then you can eliminate the uncertainty associated with crystal startup time.

I think the best way to reverse engineer CPU32 is through the background debugger module. You can transfer a piece of code into RAM using the BDM and command CPU32 to jump to the RAM code. The sky is the limit after that.

Author:  Obeisance [ Sat Feb 25, 2017 8:17 pm ]
Post subject:  Re: I need help forming a strategy to find execution time

Thanks for pointing me to the CPU32 reference... I missed that because I was searching on google with keywords that did not seem to catch that document.

Similarly, thanks for pointing out the uncertainty in the xal. I did not know that there would be extra variability introduced at that step. Moreso, I had forgotten to look at the physical oscillator chip on the board until you mentioned it. I had previously been disassembling under the assumption that the board used a standard 4.194 MHz reference oscillator (I made this assumption because I did not have access to the physical board when I began disassembly). Now that I have a 'benched' version of the microcontroller I looked and found that the reference oscillator has 4.001 printed on it- this affects my calculations of baud rates, interrupt timers and clock speed (alas, not enough to account for the lack of communication response).

I recognize that the route that I am trying to follow may not be the easiest, but since the microcontroller belongs to an old car I believe that such an interface must be possible because it is the OEM re-programming interface. I think that the interface uses the OBD port in the car and that it does not have direct access to a hardwired reset pin on the microcontroller (although it could potentially monitor the state of the pins for a counter-latch state which indicates a certain point in the code where the pin states are initialized as inputs or outputs).

Although there is a BDM port on the microcontroller board, I have not figured out how to use BDM commands (or how to build the interface). I would prefer to reverse engineer the reprogramming method that is built into the bootloader because it is a convenient interface which does not require opening the microcontroller case (sealed against weather).

Author:  Plasmo [ Sun Feb 26, 2017 5:38 am ]
Post subject:  Re: I need help forming a strategy to find execution time

I can appreciate that you don't want to open up the case and insert a hardware you don't have experience with. Just in case you need to use a BDM in the future, you can download the free software, OCDCommander, from Macraigor Systems. If you have a PC with a parallel port, you can also build a BDM probe yourself. I attached a schematic of a BDM that I built 20 years ago. I've used that successfully on several CPU32 processors. Good luck!

bdm-free_scm.jpg [ 250.64 KiB | Viewed 167 times ]

Page 1 of 1 All times are UTC
Powered by phpBB® Forum Software © phpBB Group