SIO Crashing

[dega]

I just finished my serial cable, I plugged in the headphones and the cable that I made and for some reason, when the sample SIO program calls pspDebugSioInit the program crashes after a few seconds and gives me a "game cannot be started" error. I have read that the program needs to be kernel mode in order for anything with SIO to work, how do I ensure that the sample program is in kernel mode, and could the program not being in kernel mode be causing the crash?

Thanks a ton!
- dega

EDIT: pspDebugInstallErrorHandler also results in the same crash. Also, the function that handles the exception, if it is compiled with the code it causes the crash :(.
EDIT: After some altering, I got the PSP to completely crash and upon restarting it I had to re-enter the date and time.

[jimparis]

What firmware? Those samples might not work on anything above 1.5.

[dega]

I was running SE-B'', I just upgraded to SE-C but I have yet to try the SIO sample again.

Edit: I was flipping through the configurations of SE-C just now and noticed that there is a way to set what firmware version hombrew is run under, I'll force 1.50 and give it a try and see if it makes any difference with my problem.

[dega]

Sorry for the double post, but I have tracked down my problem and have no idea how to fix it.

Code: Select all

// right after includes
extern int sceHprmEnd(void);
extern int sceSysregUartIoEnable(int uart);

PSP_MODULE_INFO("REMOTE", 0x1000, 1, 1);
PSP_MAIN_THREAD_ATTR(THREAD_ATTR_USER);

// later on
__attribute__ ((constructor)) void InitKernelFunctions()
{
	pspDebugScreenInit();
	pspKernelSetKernelPC();

	// enable the serial port
	sceHprmEnd();
	sceSysregUartIoEnable(4);  // wonderful crash here
	sceKernelDelayThread(2000000);
}

-----------------------------------------------------
The make file:

TARGET = SIO
OBJS = main.o

CFLAGS = -O2 -G0 -Wall
CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti
ASFLAGS = $(CFLAGS)

EXTRA_TARGETS = EBOOT.PBP
PSP_EBOOT_TITLE = SIO Tester

PSPSDK=$(shell psp-config --pspsdk-path)
include $(PSPSDK)/lib/build.mak 

LIBS += -lpsphprm_driver

For some reason, the call to "sceSysregUartIoEnable(4);" crashes the PSP forcing me to try and turn off the PSP about 20 times (and it won't turn off until that last time) and eventually when it comes back I have to re-enter the date and time. Any ideas on what may be causing this very fun *cough* error?

Side Note: I am running 2.71 SE-C forcing 1.50 for my homebrew.

Thanks again :)!
- dega

[jimparis]

Try running it on a real 1.5 firmware, as that has definitely been tested to workk. Also, try running it without your cable attached; it's possible you have a short in the cable or something which causes the PSP to brown out and crash as soon as it enables the port.

[dega]

I tried running it without my cable and my program worked just fine. I have no idea where to begin looking for what is wrong with my cable lol, I am building a dual shock adapter cable, this is what I have:



I know that the PSP uses 2.5V and my cable's power supply is 3.0V, could this be causing the crash?

[dega]

Well, I have got the crashing to stop. Now when I call "pspDebugSioGetchar" my program freezes (with or without the cable) and after a few seconds the PSP turns off.

[jimparis]

pspDebugSioGetchar needs to be called from kernel mode because it does direct hardware access, so I would guess that you're calling it from user mode?

[dega]

I was; though now I am working off another example of which I found that registers some stdio handlers while in kernel mode and uses stdio functions while in user mode, which this seems to make the freezing goes away.

Once I found this I attempted to send the controller the start command 0x01 and the data request command 0x42 in hopes that I would get some data back from it but as soon as I do that my PSP crashes (the good ol' play with the power switch a billion times and then reset the date and time upon boot), which leads me to believe that the PSP does not like a 3V signal sent to it. As usual, if I run the program without the cable and controller attached the PSP does not crash.

[Charles]

Rule out your cable by using the Lua serial program.

You can reset the PSP by holding the power switch all the way "up" for 5-10 seconds.

Post a pinout of your cable.

3v does no harm to PSP, there is a huge crowd using GPS-recievers with the homebrew GPS navigation software MapThis.

I think you have something miswired.

[dega]

Rule out your cable by using the Lua serial program.

Ok, I tried this and the program ran without any problems, however I don't think this program is much help. The controller doesn't send data until you send it the bytes 0x01 and 0x42. I tried altering the sample as follows to do send these bytes (keep in mind, I know nothing about Lua), it doesn't crash but it also doesn't echo anything to the screen:

Code: Select all

-- Original sample that came with Lua player
printTerminal("initializing SIO...\n");
System.sioInit(2400)
infoString = "starting echo...\n"
printTerminal(infoString);
System.sioWrite(infoString)
ping = 0
while true do
	text = normalizeLinefeed(System.sioRead())
	ping = ping + 1
	if ping == 60 then
		ping = 0
		text = text .. "."
	end
	printTerminal(text)
	System.sioWrite(text)
	screen:blit(0, 0, terminal, 0, 0, terminal:width(), terminal:height(), false)
	screen.waitVblankStart()
	screen:flip()
	if Controls.read():start() then break end
end
-- End original

-- My alteration
printTerminal("initializing SIO...\n");
System.sioInit(2400)
infoString = "starting echo...\n"
printTerminal(infoString);
System.sioWrite(0x01)  -- CHANGE
System.sioWrite(0x42)  -- CHANGE
ping = 0
while true do
	text = normalizeLinefeed(System.sioRead())
	ping = ping + 1
	if ping == 60 then
		ping = 0
		text = text .. "."
	end
	printTerminal(text)
	System.sioWrite(0x01)  -- Change
	System.sioWrite(0x42)  -- Change
	screen:blit(0, 0, terminal, 0, 0, terminal:width(), terminal:height(), false)
	screen.waitVblankStart()
	screen:flip()
	if Controls.read():start() then break end
end
-- End my alteration

You can reset the PSP by holding the power switch all the way "up" for 5-10 seconds.

I know that, however when it 'crashes' I have to do it multiple times during which the screen flickers etc (it appears as if the power is off, but the power light is still on)... then after a few tries of holding the switch all the way up for about 10 seconds each it finally shuts off and I can restart it normally (though when I do I am greeted with a date time entry).

3v does no harm to PSP, there is a huge crowd using GPS-recievers with the homebrew GPS navigation software MapThis.

That is a relief :).

I think you have something miswired.
Post a pinout of your cable.

I agree, here is the info on my cable (you can see my cable and power source in one of the replies above).

References:
http://mc.pp.se/psp/phones.xhtml - This is the pinout I used to learn about the remote port
http://www.technick.net/public/code/cp_ ... conjoy_psx - This is the pinout I used to learn about dual shock controllers

Used this for ideas on where to wire up the power pack:

- taken from http://www.emulatronia.com/reportajes/d ... /print.htm

Anyways, this is my current pinout:

PSP Pin / Power Source >> Female Controller Adapter
===============================================
PSP Digital Ground (pin 2) >> Ground (pin 4)
PSP TXD (pin 3) >> Command (pin 2)
PSP RXD (pin 6) >> Data (pin 1)
Power 3V + >> VCC & Clock (pins 5 & 7)
Power 3V - >> ATT Select (pin 6)

Just to clairify the wires in the picture of my cable, psp pin 2 is the green cable, psp pin 3 is the orange cable, psp pin 6 is the grey cable, power 3V + is red and power 3V - is black.[/code]

P.S. Sorry for this post being so long :).

[J.F.]

Anyways, this is my current pinout:

PSP Pin / Power Source >> Female Controller Adapter
===============================================
PSP Digital Ground (pin 2) >> Ground (pin 4)
PSP TXD (pin 3) >> Command (pin 2)
PSP RXD (pin 6) >> Data (pin 1)
Power 3V + >> VCC & Clock (pins 5 & 7)
Power 3V - >> ATT Select (pin 6)

Not gonna work. While TxD and RxD can be used for command and data, pulling the clock line to +V is never gonna work. It has to CLOCK... hence the name. Each transition on clock tells everyone when the next bit is due. Also, select HAS to be high before a frame, stay low during the frame, then return high after the frame, so tying it to ground won't work either.

[dega]

Not gonna work. While TxD and RxD can be used for command and data, pulling the clock line to +V is never gonna work. It has to CLOCK... hence the name. Each transition on clock tells everyone when the next bit is due.

Wouldn't that mean that the normal PSP headphone remote also needs to sync with clock? If so, how does it do it?

Also, select HAS to be high before a frame, stay low during the frame, then return high after the frame, so tying it to ground won't work either.

What are high and low? I'm still new to all of this stuff :). Also, if V+ can't be wired to clock and V- cant be wired to select, where would V- get wired up to then (I'm assuming V+ would stay wired to VCC)?

[J.F.]

Not gonna work. While TxD and RxD can be used for command and data, pulling the clock line to +V is never gonna work. It has to CLOCK... hence the name. Each transition on clock tells everyone when the next bit is due.

Wouldn't that mean that the normal PSP headphone remote also needs to sync with clock? If so, how does it do it?

Okay, TxD and RxD are normal asynchronous serial lines. They are clocked at LOW fixed rates (a set of fixed rates usually set in a register somewhere). Typical speeds are like 9600 baud, 19200 baud... the receiver is usually set to the same frequency and checks the data line with a 16X clock to make sure it catches the bit cells right. There is almost always a start and stop bit framing each transmitted byte.

The serial on the PS controllers is a high-speed synchronous serial port - it expects a clock line that tells it specifically when the bit cells are valid. So the serial on the PSP is unsuitable for such a purpose.

There are two lines of 2.5V and two lines of GND on the PSP serial port. Some of these are most probably standard serial handshake lines - RTS, CTS, etc. If that is the case, it may be possible to use them to make a synchronous serial connection. I don't know how fast the PSP CPU can read/write these lines... there isn't quite enough info on this port yet. At the moment, people are simply hooking the RxD and TxD to normal async serial devices and sending/receiving unhandshaken bytes in experiments to see what is possible... like maybe utilizing a keyboard.

Also, select HAS to be high before a frame, stay low during the frame, then return high after the frame, so tying it to ground won't work either.

What are high and low? I'm still new to all of this stuff :). Also, if V+ can't be wired to clock and V- cant be wired to select, where would V- get wired up to then (I'm assuming V+ would stay wired to VCC)?

Okay... look at this. notice that SEL starts high, then goes low and stays low. The CLK line then starts going up and down, each cycle clocking a bit on the CMD and DAT lines. Eight of them and then you wait for the pad to assert low the ACK line. That tells you that the pad got the byte and is now ready for another. After the last byte in a frame, no ACK is generated (so don't wait on the last one, or have a timeout). After the last byte from the pad is received, the SEL line goes high again. This has to all be fairly well timed - the clock rate for each bit is 250KHz for normal PSX peripherals, while PS2 peripherals can handle 500KHz. This is well beyond normal asynchronous serial rates.

You COULD make a programmable chip that communicated with the pad, then sent the data on to the PSP across a normal async serial port, but that's beyond the scope of this discussion.

[jimparis]

There are two lines of 2.5V and two lines of GND on the PSP serial port. Some of these are most probably standard serial handshake lines - RTS, CTS, etc.

Only RxD and TxD are available; there aren't any handshaking lines exposed. The 6 pin connector is GND, +2.5V, RxD, TxD, and two pins for the microphone input. A microcontroller would be his only option, as you mentioned.

[J.F.]

:)

Well then, it's REALLY unsuitable for trying to read a pad directly. That's why most PSX controller interfaces for the PC hook to the parallel port - it's either that or use a chip to convert between the pad and USB (which is what commercial pad interfaces do).