EASy68K  
It is currently Tue Sep 26, 2017 12:17 am

All times are UTC




Post new topic Reply to topic  [ 4 posts ] 
Author Message
PostPosted: Sat Feb 25, 2017 1:49 pm 
Offline

Joined: Sat Jan 09, 2016 9:58 pm
Posts: 12
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.


Top
 Profile  
 
PostPosted: Sat Feb 25, 2017 3:32 pm 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
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.


Top
 Profile  
 
PostPosted: Sat Feb 25, 2017 8:17 pm 
Offline

Joined: Sat Jan 09, 2016 9:58 pm
Posts: 12
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).


Top
 Profile  
 
PostPosted: Sun Feb 26, 2017 5:38 am 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
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!


Attachments:
bdm-free_scm.jpg
bdm-free_scm.jpg [ 250.64 KiB | Viewed 908 times ]
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


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:  
cron
Powered by phpBB® Forum Software © phpBB Group