Has anyone ever figured out what the two pins beneath the power supply plug were for? Has anyone ever guessed that they are used for a special I2C interface used by Sony to put the PSP into service mode for flash recovery? Did anyone ever connect the dots inside the main hardware initialization routine in main_led.bin of the IPL to come to this conclusion? Did you then request a PM from anyone else who has discovered this, or anyone with the hardware knowledge to build such an interface?
Just curious...
Service mode by power supply pins?
-
jockyw2001
- Posts: 339
- Joined: Thu Sep 29, 2005 4:19 pm
Re: Service mode by power supply pins?
and knowledgable for sure. Sounds cool! Come on guys reverse that thing!mrbrown wrote:Just curious...
/JockyW
Re: Service mode by power supply pins?
If I were you, I would lock this thread :-) But a continuity tester reveals, that there is nothing magic about these pins (check against + and GND).mrbrown wrote:Has anyone ever figured out what the two pins beneath the power supply plug were for?
Well it's not really development related so I'll move it off-topic.
Right, it's been confirmed that the 2 pads are the same as the power supply jack. But I'm not convinced that you couldn't use the power supply to send and receive data...
And scratch the I2C bit for now, that has to do with other code in the IPL, but don't rule it out yet :).
Right, it's been confirmed that the 2 pads are the same as the power supply jack. But I'm not convinced that you couldn't use the power supply to send and receive data...
And scratch the I2C bit for now, that has to do with other code in the IPL, but don't rule it out yet :).
The IPL is only accesible by the sceNand driver, so it's relatively protected from a casual bricking. Remember that most of the PSP's security hinged on people not being able to use kernel mode :).
What makes me even more suspicious is the layout of the IPL. You have main_led.bin loaded first, which *only* initializes flash, DDR, GPIO, I2C, the clockgen driver, and the interface to the battery/power port. The second program (what nem termed iplpayload) only has enough of sysmem, loadcore, and the FAT flash driver to bootstrap the kernel out of flash. It isn't until the proper kernel is loaded that the remaining peripherals are even initialized at all.
Why would they only bring up a subset of the hardware in main_led.bin? Why would they jump to a routine that doesn't exist (the address is composed by reading hardware registers and demangling the values) that has an infinite loop when that routine returns? Why would they pass that routine function pointers to sceSysconCmdExec (responsible for interface with the power port and battery), sceI2C routines, and some other mysterious hardware access routine?
What makes me even more suspicious is the layout of the IPL. You have main_led.bin loaded first, which *only* initializes flash, DDR, GPIO, I2C, the clockgen driver, and the interface to the battery/power port. The second program (what nem termed iplpayload) only has enough of sysmem, loadcore, and the FAT flash driver to bootstrap the kernel out of flash. It isn't until the proper kernel is loaded that the remaining peripherals are even initialized at all.
Why would they only bring up a subset of the hardware in main_led.bin? Why would they jump to a routine that doesn't exist (the address is composed by reading hardware registers and demangling the values) that has an infinite loop when that routine returns? Why would they pass that routine function pointers to sceSysconCmdExec (responsible for interface with the power port and battery), sceI2C routines, and some other mysterious hardware access routine?
They do reflash it from 1.x -> 2.x, so it could still get messed up for entirely innocent behavior, although that's unlikely since the IPL is so small.mrbrown wrote:The IPL is only accesible by the sceNand driver, so it's relatively protected from a casual bricking.
My bet is that they want to bring up as little hardware as necessary and use the I2C routines to check on the battery before continuing, possibly in an attempt to prevent the PSP from blowing up in Little Johnny's hands just because he left it in a hot car for too long.... which *only* initializes flash, DDR, GPIO, I2C, the clockgen driver, and the interface to the battery/power port ...
Why would they only bring up a subset of the hardware in main_led.bin? ...
Why would they pass that routine function pointers to sceSysconCmdExec (responsible for interface with the power port and battery), sceI2C routines, and some other mysterious hardware access routine?
The center pin on the battery looks like a bidrectional serial protocol running at 19200 baud, 0v to +2.5v. Activity on this line occurs very soon after the power switch is pressed, before the LED or backlight or any other visible response.
I put a serial dump with comments and timestamps at http://psp.jim.sh/battery/. There's also a scope trace of the beginning of one of the packets (which I've decoded as 5A, 02, 01, A2..).
I didn't think to watch that line when booting up with no battery present before I desoldered my test wires, but I can put it back together if you're interested in knowing that.
Why do you think it is a bidirectional protocol? BTW: I was wondering why a battery has a serial connector, so I opened the case and looks like there is some more electronic to discover. Why didn't Sony integrated this into the PSP but in the battery?jimparis wrote:The center pin on the battery looks like a bidrectional serial protocol running at 19200 baud, 0v to +2.5v. Activity on this line occurs very soon after the power switch is pressed, before the LED or backlight or any other visible response.
Because there's at least some communication initiated by the PSP, and it's used to get status information from the battery. I could build a better circuit and figure out which data comes from where, but unless we think this is more than just battery status it's probably not too interesting :)Shine wrote:Why do you think it is a bidirectional protocol?
That's standard practice for Li-Ion, mostly for the safety circuits, probably also to reduce pin count, and to allow new types of batteries in the future.Why didn't Sony integrated this into the PSP but in the battery?
-
Dr. Vegetable
- Posts: 171
- Joined: Mon Nov 14, 2005 1:32 am
- Location: Boston, Massachusetts
- Contact:
I had thought of doing this when I was looking at the battery protocol a few months back. The problem is that the TX and RX are connected inside the battery, so you'd get loopback and everything will look as if it's coming from the battery. I think you have the same problem on the PSP side.digihoe wrote:I think a pair of diods in combination with two RS232 echo interface and timing would do the trick...
I did some experimentation by breaking the line and echoing back and forth using two COM ports on a PC to see what came from where. It gets pretty tricky to fake everyone out this way. For example, once every 30 seconds, the PSP sends a BREAK and expects to get a BREAK back in return or it goes silent. I also found that there is communication between the PSP and the battery when you first insert the battery. If the PSP doesn't get the right info from the battery, it will not turn on.
I've got a few logs of some of these transactions around here somewhere. I'll dig out my notes and post what I've got...
p.s. Could this thread be moved into PSP Hardware Development, please?
EDIT: Thank you!
Last edited by Dr. Vegetable on Thu Feb 23, 2006 2:11 am, edited 1 time in total.
-
Dr. Vegetable
- Posts: 171
- Joined: Mon Nov 14, 2005 1:32 am
- Location: Boston, Massachusetts
- Contact:
This is the data stream sent from the PSP to the battery when it is inserted. In this case, the battery's COM pin was disconnected, so it did not respond, and the PSP refuses to power up:
This time, the battery was inserted with the COM port connected through to the PSP:
...Then the link went quiet. After about 10-15 seconds I turned on the PSP...
And then the battery connection fell out.
From this, it looks like commands sent from the PSP to the battery start with 0x5A and the responses sent from the battery to the PSP start with 0xA5.
I have other logs of the normal powered-up operation. The communication occurs in bursts spaced 5 seconds apart, in a larger pattern that seems to cycle every 30 seconds:
That was about as far as I got in understanding this protocol. Does anyone else see more of a pattern?
Code: Select all
[00] <BREAK>
[5A]Z[00] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[09] [0B] [26]&[FD]
[5A]Z[09] [0B] [26]&[FD]
[5A]Z[09] [0B] [26]&[FD]
[5A]Z[09] [0B] [26]&[FD]
[5A]Z[09] [0B] [26]&[FD]
[5A]Z[09] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[00] [0B] [26]&[FD]
[5A]Z[09] [0B] [26]&[FD]
[5A]Z[09] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[00] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[09] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[09] [0B] [26]&[FD]
[5A]Z[00] [0B] [26]&[FD]
[5A]Z[00] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[5A]Z[01] [0B] [26]&[FD]
[00] <BREAK>
Code: Select all
[00] <BREAK>
[5A]Z[09] [0B] [24]$[FD]
[A5] [15] [32]2[08] [4C]L[B3] [20] [C2]
[5A]Z[09] [63]c[70]p[FE]
[A5] [19] [32]2[88] [41]A[21]![23]#[AA] [F4]
[5A]Z[0D] [03] [06] [10] [B9] [4A]J[C2] [D4] [30]0[7D]}[92] [53]S[0E] [FC]
[A5] [49]I[32]2[48]H[97] [74]t[2E].[66]f[D2] [F2] [80] [E7] [0D] [19] [BD] [16] [4E]N[5C]\[4D]M[97] [28]([43]C
[5A]Z[00] [0A] [95] [5F]_[B3] [0C] [17] [28]([46]F[56]V[63]c[F3]
[A5] [29])[32]2[08] [87] [AB] [32]2[57]W[D1] [77]w[99] [E7] [FD] [FF]
[5A]Z[09] [0B] [24]$[FD]
[A5] [15] [32]2[08] [90] [66]f[81] [18]
[5A]Z[04] [03] [07] [10] [2C],[2F]/[00] [E7] [1E] [CB] [99] [00] [4D]M[FE]
[A5] [49]I[32]2[C8] [BB] [CD] [CF] [5E]^[47]G[D3] [9E] [AB] [CC] [09] [5B][[CA] [6D]m[19] [AB] [A9] [2F]/[F3]
[5A]Z[01] [0A] [E5] [AD] [2C],[67]g[FA] [33]3[17] [61]a[AD] [24]$[FD]
[A5] [29])[32]2[E8] [CD] [6E]n[B4] [D1] [A8] [22]"[DD] [79]y[FF]
[00] <BREAK>
Code: Select all
[5A]Z[09] [0B] [26]&[FD]
[5A]Z[09] [0B] [26]&[FD]
[A5] [15] [32]2[08] [4C]L[B3] [20] [C2]
[5A]Z[09] [63]c[74]t[FE]
[A5] [19] [32]2[88] [41]A[21]![23]#[AA] [F4]
[5A]Z[0D] [03] [07] [90] [ED] [DA] [4D]M[D6] [3C]<[5F]_[4A]J[92] [0C]
[A5] [49]I[32]2[88] [1D] [2C],[E6] [A0] [AF] [7D]}[62]b[30]0[29])[6D]m[FB] [03] [0D] [5D]][5F]_[E9] [39]9[75]u
[5A]Z[00] [0A] [F5] [59]Y[AA] [64]d[27]'
[5A]Z[23]#[0F] [5B][[AA] [FF] [A5] [29])[32]2[48]H[7A]z[36]6[D3] [2C],[55]U[58]X[FA] [FC] [31]1
From this, it looks like commands sent from the PSP to the battery start with 0x5A and the responses sent from the battery to the PSP start with 0xA5.
I have other logs of the normal powered-up operation. The communication occurs in bursts spaced 5 seconds apart, in a larger pattern that seems to cycle every 30 seconds:
Code: Select all
<PSP turned on, 10 seconds of silence>
[5A]Z[00] [0B] [26]&[FD]
[5A]Z[09] [0B] [26]&[FD]
[A5] [15] [32]2[08] [4C]L[B3] [20] [C2]
[5A]Z[00] [63]c[74]t[FE] [A5] [19] [32]2[88] [41]A[21]![23]#[AA] [F4]
[5A]Z[5B][[06] [1C] [20] [AF] [61]a[B8] [94] [0B] [B5] [25]%[14] [AD]
[A5] [49]I[32]2[E8] [AE] [31]1[25]%[0E] [26]&[7E]~[D2] [F9]
[5A]Z[E9] [32]2[1F] [0B] [4A]J[2A]*[EA] [B0]
[5A]Z[29])[0A] [F5] [3C]<[50]P[0E] [27]'[F8] [D2] [1D] [06] [1D] [FF]
[A5] [29])[32]2[88] [54]T[6F]o[BE] [77]w[3F]?[BD] [22]"[2A]*[4A]J[E1]
<1 second of silence>
[5A]Z[09] [0B] [26]&[FD]
[A5] [15] [32]2[08] [90] [66]f[81] [18]
[5A]Z[09] [3B];[C6] [FA]
[A5] [11] [33]3[08] [D8] [B0] [90]
[5A]Z[01] [4B]K[A4] [FA]
[A5] [11] [33]3[E8] [0A] [A0] [D6]
[5A]Z[00] [13] [16] [FD]
[A5] [0D] [32]2[48]H[EC] [F3]
[5A]Z[09] [23]#[EC] [FA]
[A5] [11] [33]3[C8] [FF] [4D]M[FE]
[5A]Z[00] [1B] [04] [F5]
[A5] [11] [33]3[E8] [D2] [90] [DF]
<5 seconds of silence>
[5A]Z[09] [0B] [26]&[FD]
[A5] [15] [32]2[08] [90] [B2] [81] [12]
<5 seconds of silence>
[5A]Z[00] [3B];[C6] [FA]
[A5] [11] [33]3[08] [D8] [B0] [90]
<5 seconds of silence>
[5A]Z[01] [4B]K[A4] [FA]
[A5] [11] [33]3[48]H[16] [58]X[F8]
<5 seconds of silence>
[5A]Z[09] [13] [2C],[FD]
[A5] [0D] [32]2[48]H[EC] [F3]
<5 seconds of silence>
[5A]Z[09] [23]#[EC] [FA]
[A5] [11] [33]3[C8] [FE] [54]T
<2 seconds of silence>
[5A]Z[09] [0B] [26]&[FD]
[A5] [15] [32]2[08] [50]P[B2] [81] [C9]
[5A]Z[05] [03] [07] [B0] [7E]~[FC] [36]6[6B]k[49]I[6B]k[44]D[79]y[D3] [FE]
[A5] [49]I[32]2[28]([11] [6D]m[1C] [68]h[D2] [9C] [00] [63]c[C5] [FC] [89] [4D]M[C5] [68]h[B7] [61]a[6E]n[E8]
[5A]Z[29])[0A] [65]e[93] [DD] [28]([E6] [9A] [E4] [0C] [33]3[27]'
[A5] [29])[32]2[88] [46]F[75]u[48]H[A2] [5B][[7E]~[E8] [F4] [36]6[FF]
<2 seconds of silence>
[5A]Z[09] [16] [08] [F5]
[A5] [11] [33]3[48]H[D2] [D0] [FF]
<10 seconds of silence>
[5A]Z[00] [0B] [26]&[FD]
[A5] [15] [32]2[08] [10] [A2] [81] [93]
<5 seconds of silence>
[5A]Z[09] [3B];[C6] [FA]
[A5] [11] [33]3[08] [D8] [B0] [90]
<5 seconds of silence>
[5A]Z[09] [4B]K[A4] [FA]
[A5] [11] [33]3[28]([16] [98] [F8]
<5 seconds of silence>
[5A]Z[01] [13] [16] [FD]
[A5] [0D] [32]2[48]H[EC] [F3]
<2 seconds of silence>
[5A]Z[00] [0B] [26]&[FD]
[A5] [15] [32]2[08] [90] [44]D[81] [28](
[5A]Z[05] [03] [07] [10] [53]S[3D]=[00] [AA] [DF] [D6] [3C]<[2D]-[20]
[A5] [49]I[32]2[48]H[AE] [F6] [37]7[50]P[B9] [8D] [EE] [56]V[BD] [9A] [97] [17] [5B][[38]8[A7] [C5] [9C] [AB]
[5A]Z[01] [0A] [95] [13] [5B][[22]"[CD] [52]R[02] [C5] [1A] [EE] [FF]
[A5] [29])[32]2[A8] [1F] [6E]n[4C]L[2B]+[E7] [09] [63]c[BC] [AB]
<2 seconds of silence>
[5A]Z[01] [23]#[F6] [FA]
[A5] [11] [33]3[E8] [F9] [53]S[FF]
<5 seconds of silence>
[5A]Z[01] [1B] [04] [F5]
[A5] [11] [33]3[48]H[D2] [D0] [FF]
<10 seconds of silence>
[5A]Z[09] [0B] [26]&[FD]
[A5] [15] [32]2[08] [10] [62]b[81] [3A]:
<5 seconds of silence>
[5A]Z[09] [3B];[8C] [FA]
[A5] [11] [33]3[08] [D8] [B0] [90]
<5 seconds of silence>
[5A]Z[09] [4B]K[A4] [FA]
[A5] [11] [33]3[48]H[2C],[B0] [E3]
<2 seconds of silence>
[5A]Z[09] [0B] [26]&[FD]
[A5] [15] [32]2[08] [90] [58]X[20] [8F]
[5A]Z[2D]-[03] [06] [90] [BE] [45]E[D2] [7F][E1] [0D] [08] [52]R[28]([FF]
[A5] [49]I[32]2[48]H[6B]k[AF] [40]@[95] [F2] [C2] [45]E[16] [5E]^[BC] [BF] [98] [F3] [11] [B0] [38]8[06] [FF]
[5A]Z[09] [0A] [C5] [6A]j[9B] [64]d[D7] [C2] [03] [51]Q[30]0[C5] [FE]
[A5] [29])[32]2[28]([9F] [5F]_[F1] [C7] [25]%[F6] [99] [B3] [A9] [FA]
<2 seconds of silence>
[5A]Z[09] [13] [2C],[FD]
[A5] [0D] [32]2[48]H[EC] [F3]
<5 seconds of silence>
[5A]Z[01] [23]#[F6] [FA]
[A5] [11] [33]3[88] [9F] [66]f[FF]
<5 seconds of silence>
[5A]Z[09] [1B] [00] [F5]
[A5] [11] [33]3[88] [92] [98]
That serial line from the battery is used primarily to tell the PSP the battery
temperature.
It's used in mobile phones as well.
If the battery doesn't have the cell damper like nicads and NiMh do,
the battery will explode if it gets too hot under charging conditions.
There might be extra 'thinking' going on inside the battery to work out
how much charge time is left since the PSP tells the user this info.
That would need to be worked out inside the battery because once you
changed the battery, the data would be different (an older battery has less life per charge).
So you guys remove chips and dump firmware and can't figure out that :D
As suggested in this thread, it isn't that interesting, and cannot expand our
capabilities at all.
Art.
temperature.
It's used in mobile phones as well.
If the battery doesn't have the cell damper like nicads and NiMh do,
the battery will explode if it gets too hot under charging conditions.
There might be extra 'thinking' going on inside the battery to work out
how much charge time is left since the PSP tells the user this info.
That would need to be worked out inside the battery because once you
changed the battery, the data would be different (an older battery has less life per charge).
So you guys remove chips and dump firmware and can't figure out that :D
As suggested in this thread, it isn't that interesting, and cannot expand our
capabilities at all.
Art.
-
Dr. Vegetable
- Posts: 171
- Joined: Mon Nov 14, 2005 1:32 am
- Location: Boston, Massachusetts
- Contact:
Great! Since you seem to know so much about this, why don't you explain to me how the data is formatted in these messages: What was the temperature and charge level of my battery pack when I recorded this dump? What is the serial number of the battery pack?? How does the PSP identify a "legitimate" Sony battery???Art wrote:That serial line from the battery is used primarily to tell the PSP the battery temperature.
It's used in mobile phones as well.
The picture that is emerging is that this port may have other responsibilities beyond simply monitoring the battery recharge state. I understand that the communications logs I monitored are not going to tell us how to put the PSP into service mode. However, understanding the protocol used to talk to the battery could provide some important clues, such as:Art wrote:So you guys remove chips and dump firmware and can't figure out that :D
As suggested in this thread, it isn't that interesting, and cannot expand our capabilities at all.
- Perhaps the Debug Mode uses similar commands and/or framing, and so knowing how the PSP talks to a battery might help us understand how the PSP talks to a diagnostic console.
- Maybe one day someone will be reading through disassembled firmware and stumble upon the command handler for the battery port. If we know what commands are used for routine battery communication, we will be able to focus on any "extra" commands that might be decoded by the firmware.
a good link on battery circuits: http://batteryuniversity.com/partone-17.htm
.plus everything from the main page .)
ok, i think there is much -much more inside the PSP battery as we think.
why? in normal mobile accus there used to be 1 or 2 pcs of an 8-pin chip
plus one 6-pin circuit. but there we see a HUGE IC. for what? these days everything is integrated...
q1: how does the communication look like with a "X2" BATTERY PACK?
q2: how does the circuitry look like in the "X2" BATTERY PACK?
q3: are the X2 producers involved (assuming they are 3rd parties)
and finally, q4 for Dr.Vegetable:
q4: cam you measure the communication of the battery from one of the latest sony-ericcson phones, pls?
.plus everything from the main page .)
ok, i think there is much -much more inside the PSP battery as we think.
why? in normal mobile accus there used to be 1 or 2 pcs of an 8-pin chip
plus one 6-pin circuit. but there we see a HUGE IC. for what? these days everything is integrated...
q1: how does the communication look like with a "X2" BATTERY PACK?
q2: how does the circuitry look like in the "X2" BATTERY PACK?
q3: are the X2 producers involved (assuming they are 3rd parties)
and finally, q4 for Dr.Vegetable:
q4: cam you measure the communication of the battery from one of the latest sony-ericcson phones, pls?
As I said, I don't consider it the most worthwhile investment in time, and have little intrest in the battery connector.why don't you explain to me how the data is formatted in these messages
I think it likely that there is more potential at the headphone serial connector,
and was digging around here because I am biulding a headphone remote emulator.
If I wanted to tell you the left over charge time and temp of your battery
at the time of your capture, I'd consider it a job more suited to a
microcontroller for a repeatable result since timing is involved.. rather than trying to match timing of each tx with a Windows terminal.
You must have me mixed up with someone who suggested there is a guy at SonyWhat is the serial number of the battery pack??
who sits at a desk and manually enters serial numbers from battery
stickers into every individual battery firmware code (or vice versa).
I thought I did since nobody had mentioned the obvious (temperature) until then, I simply answered a question that had not been answered,So Art, if you have nothing useful to add to this discussion, then please STFU
and I didn't need to interpret your serial dump to do so:
As it happens I do know a little about it.BTW: I was wondering why a battery has a serial connector,..... Why didn't Sony integrated this into the PSP but in the battery?
Temerature is one of the only two ways that any charging circuit can tell if a battery is charged
without being overcharged, and any decent charger will employ both.
and I think the flaming is a little harsh. I only meant to be light hearted about it.
Art.
This thread got me thinking...
At the risk of getting flamed again for suggesting something obvious....
I wonder if any of the data packets are sent just prior to the update of data
displayed on the System Settings=>Battery Information screen.
This data seems to be updated to screen at erratic intervals.
I'm not suggesting that the 'Hours Left' figure is sent straight from the battery
since you can make the estimate jump up and down by switching the
screen back and forth from minimun to maximum brightness and waiting for the figure to change each time.
... now that is somewhat interesting.. some programmer's forethought there.
Art.
At the risk of getting flamed again for suggesting something obvious....
I wonder if any of the data packets are sent just prior to the update of data
displayed on the System Settings=>Battery Information screen.
This data seems to be updated to screen at erratic intervals.
I'm not suggesting that the 'Hours Left' figure is sent straight from the battery
since you can make the estimate jump up and down by switching the
screen back and forth from minimun to maximum brightness and waiting for the figure to change each time.
... now that is somewhat interesting.. some programmer's forethought there.
Art.