Author Topic: blah. shoehorn 0, 8052 1  (Read 5660 times)

0 Members and 1 Guest are viewing this topic.

Offline bushing

  • Senior Member
  • Needs to get outside.
  • *****
  • Posts: 119
  • props to my peeps
blah. shoehorn 0, 8052 1
« on: June 26, 2005, 07:08:36 am »
So me + some of the IRC crew were playing with the emergency boot rom / serial loader tonight.

If you jumper the two pins of JP2 together and apply power to the device, it won't execute the normal bootloader out of the Flash ROM.  Instead, the 7312 will execute a small, built-in program that spit out a '<' on the serial port.

When you get this prompt, you can upload 2000 bytes of code over the serial port, and it will store that in its internal SRAM and execute that.  The idea here is that hopefully 2000 bytes is enough for you to load something that will let you load further.

I know of one GPL program available to do this -- shoehorn.  It has a little program it uploads, and then it sends commands to that program to manipulate memory, load stuff, etc.

We ran into one big problem.  If you try putting that jumper on the board, apply power, and then let it sit there, here's what you'll get:

* Apply power
* Wait about 3 seconds
* Red light will come on
* '<' will appear over the serial port
* Wait another 9 (or so seconds)
* Red light will go out
* Wait another 5-6 seconds
* Red light will return, '<' will appear, etc.

We already know that the 8052 controls power to the 7312 -- it turns it on when you select the cd changer input on your head unit, and turns it back off when you turn the car off.  It now appears that it expects to see a "heartbeat" signal from the 7312, over /dev/ttyS1, or else it will reboot the processor.

Since the only code that can send that heartbeat is 51d, which isn't even loaded until after phatd, it's my guess that the max time is tweaked to match that time  -- maybe about 12 seconds or so?

The legitimate purpose for this is to respond to a crash on the part of the 7312 -- but in effect, anything that doesn't load 51d (and damn quick, I might add) will not successfully run, even if you get through all of the other protection.

Open questions at this point:

* How exactly, electrically speaking, is the 8051 controlling the power / reset of the 7312? Could we bypass this?

* What code(s) do we need to send over the serial link to the 8051 to keep it happy?

* Why doesn't shoehorn work very well?  I was able to modify it to, say, turn on the green LED, but not all of the other commands (specifically the memory size check, etc) seemed to work.  You can see a recent version of what I was using at [ur]http://downloads.phathack.com/bushing/shoehorn-3.4-phatbox.tar.bz2[/url] if anyone would like to try.

-b

Offline judb

  • Administrator
  • Veteran.
  • *****
  • Posts: 1329
  • ph4t l3wtz
Re: blah. shoehorn 0, 8052 1
« Reply #1 on: June 26, 2005, 03:03:45 pm »
Interesting.  I'll try and trace all the pins and see if any go to reset on the ARM cpu.

I still can't get connected to IRC for some reason.  I am going to poke some holes in my firewall to see if its being the problem.

Offline RobM

  • Senior Member
  • A few posts under my belt.
  • *****
  • Posts: 48
Re: blah. shoehorn 0, 8052 1
« Reply #2 on: June 26, 2005, 03:28:07 pm »
Apparently the 8052 pulls down the 3.3V power to the 7312 by pulling pin 9 (and possibly pin 10 as well) of the 3681 power controller low for several seconds, then strobing the nPOR line on the CPU to reset it.  If you force pin 9 on the 3681 high the CPU doesn't turn off right away when the watchdog expires, but it eventually does turn off somehow.

Offline sbingner

  • Administrator
  • Veteran.
  • *****
  • Posts: 1301
Re: blah. shoehorn 0, 8052 1
« Reply #3 on: June 27, 2005, 05:46:55 am »
when it pull nPOR low it puts the processor into STANDBY bleh...

Offline ralph.deratt

  • A few posts under my belt.
  • *
  • Posts: 22
Re: blah. shoehorn 0, 8052 1
« Reply #4 on: June 30, 2005, 07:14:39 am »
Quote
So me + some of the IRC crew were playing with the emergency boot rom / serial loader tonight.
[...]


It now appears that it expects to see a "heartbeat" signal from the 7312, over /dev/ttyS1, or else it will reboot the processor.

Since the only code that can send that heartbeat is 51d, which isn't even loaded until after phatd, it's my guess that the max time is tweaked to match that time  -- maybe about 12 seconds or so?

The legitimate purpose for this is to respond to a crash on the part of the 7312 -- but in effect, anything that doesn't load 51d (and damn quick, I might add) will not successfully run, even if you get through all of the other protection.
 


Checkout s2,s3,s4   They go to the 78E516.  It's possible that one of them will disable the watchdog.

RdeR