Skip to main content ↑ ↓

Messages

This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.

Messages - mungewell

1
Bus Pirate Support / Re: Buspirate SPISniffer Solved
Cool, glad you got the captures working.... you didn't yet say what the gaming controller was (make/model), do you have a link?

What are you hoping to achieve once you have the protocol understood?
Simon.
3
Bus Pirate Support / Re: Buspirate SPISniffer
[quote author="krishnak"]
I followed your advise and connected the remote with the 3.3V power output of the buspirate.
[/quote]

Not quite what I suggested, but if it didn't damage your hardware then it proves the power domains are not the problem.

[quote author="krishnak"]
However between MOSI and GND it shows 125K.
[/quote]

Just to be clear this is the resistance MOSI to GND on the target board, without BP attached.

125K is fairly ''weak'. One would normally have pull ups, but they might be using pull downs (or relying on the inherent input resistance of the RF24L01).

Do you have the pull ups enabled on the BP? If yes, try turning them off....
http://http://dangerousprototypes.com/docs/Practical_guide_to_Bus_Pirate_pull-up_resistors

A 'stronger' pull up might be interacting with the pull down and preventing the remote/micro being able to drive the signal low. I still suggest that you use some form of buffer between the MOSI signal and the BP.

[quote author="krishnak"]
Does the remote employ some anti snooping mechanism?
[/quote]

Most unlikely, vendors don't normally care and engineers are lazy.....
Simon
4
Bus Pirate Support / Re: Buspirate SPISniffer
Hi krishnak, you has PM'ed me regarding my previous testing with RF24L01. I was sniffing a USB dongle (cyprus micro driving RF24L01) and from what I remember I had no problem with link dropping when sniffing.

I would suggest that you check the power supply voltages. You might find that your target is using a lower voltage that the BP and therefore having problems when the BP is connected. You may need to buffer the signal(s) before connecting them, I'd suggest a non-inverting O/C driver with input connected to target and output to BP (pulled up to BP's supply with 10K or so).

You should also look at upping the baud rate or you might loose data, I think you can get close to 921K if you use the custom baud rate value (check my older posts).
Simon
(PM me again if you need more info, as I'm not routinely on this forum)
5
Bus Pirate Support / Re: SPI bus sniffing OK at 1 MHz?
You can get significant speed increases by using the buspirate in 'binary' mode and an app on the PC to perform bits->ASCII conversion.

I did some patches to this app (for Linux, but might be OK with windows) and have had success in running serial port at 1MByte/s.
Simon
9
Bus Pirate Support / Re: Pin modes in Binary SPI Sniffing causing problems?
As a side note it would appear that higher speed serial coms is possible with some applications....
460,800 = 8 (-3.55%)
500,000 = 7 (0%)
576,000 = 6 (-0.79%)
921,600 = 3 (+8.51%)
1,000,000 = 3 (0%)

Under Linux I was able to get Minicom working at 576,000 and 1,000,000 but both Screen and Spisniffer fail.
Under Windows I was able to get SerialTerminal working at 576,000 and 1,000,000 but both Hyperterminal and Spisniffer fail.

I guess there must be something in the way different applications setup the serial port.
Simon
10
Bus Pirate Support / Re: Pin modes in Binary SPI Sniffing causing problems?
[quote author="ian"]
The 4 byte buffer is just an entry point to the 4096 ring buffer. It takes almost no time to go from SPI->ring buffers, it's the transfer through serial that's really slow.
[/quote]

Overall the data rate is low as there is a lot of time between 'packets', however I am focusing on the burst of 35bytes which come at quite a rate. It may take no time to actually perform the transfer between SPI buffer -> ring buffer, but presumably this is on an interrupt and it must some time to service it.

Would it be an option to stay in the 'empty SPI buffer' interrupt until the CS line is de-asserted. That way we could ensure that we'd be as fast as possible, with the side effect of halting the rest of the functions. Obviously this would only work if the ring buffer did not overflow. [I would do this with separate blocks of interrupt code, so there wouldn't be extra comparisons being done when not really needed]

There is a 'raw SPI sniff' commands available, ie.
# 00001101 – Sniff all SPI traffic
# 00001110 – Sniff when CS low
# 00001111 – Sniff when CS high

# 00001100 – Sniff aggressively (lock into SPI interrupt)


[quote author="ian"]
I think you already mentioned increasing the serial port speed with a custom BRG setting.
[/quote]

Yes I am using '8' to get 460800 baud on the serial link. This works when I sniff the PC end of the link (which is running at a byte period of 16us), but fails at the wheel end (which is running at a byte period of 6.3us).

The next thing for me to try is to sniff the Wheel end of the old (Wii) wheels to see if that fails in the same manner as the new (PS3) wheel, but I might not get to that until after Christmas.
Cheers,
Simon
11
Bus Pirate Support / Re: Pin modes in Binary SPI Sniffing causing problems?
OK I'm pointing my finger at the 'burst rate'.

On my previous scope traces (on the Dongle end of things) the clock rate was 3.5us between clocks, the period of the bytes was around 16us.
On the latest scope traces (the wheel end) the clock rate is still 3.5us between clocks, but the gap between bytes is smaller. The period of the bytes is around 6.3us, meaning that perhaps the PIC can not keep up with micro (on wheel end).

I think that Ian mentioned that there is a 4byte SPI buffer in the PIC, this is obviously no good if you have a burst of 35bytes coming at high speed.

Is there anything which can be done to improve the rate at which bytes can be removed from the SPI buffer? Even if this holds up other functionality on the PIC (as there's plently of dead time between bursts on SPI activity)... I'd even be OK with only seeing data in the IN or OUT direction...
Simon.
12
Bus Pirate Support / Re: Pin modes in Binary SPI Sniffing causing problems?
I did some more thinking on this. Using the data sent from the other end (PC Dongle) of a very similar wheel.... I don't want to mod this wheel's dongle as the wheel was more expensive and I only have 1.

The following represents a 8ms time slice, all other frames will be similar (identical?) in length.
--
1285207854.392135 : [0x27(0x4E)0x40(0x00)] = 1 + 3 + 3 + 1 bytes
1285207854.392148 : [0x27(0x0E)0x60(0x00)] = 1 + 3 + 3 + 1 bytes
1285207854.392160 : [0x25(0x0E)0x12(0x00)] = 1 + 3 + 3 + 1 bytes
1285207854.392173 : [0x20(0x0E)0x3E(0x00)] = 1 + 3 + 3 + 1 bytes
1285207854.392186 : [0xA0(0x0E)0x2F(0x00)0x1B(0x00)0x40(0x00)0x00(0x00)0x00(0x00)0x8A(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x82(0x00)0x01(0x00)0x00(0x00)0x01(0x00)0x00(0x00)0xFF(0x00)0x81(0x00)0x7F(0x00)0x7F(0x00)0x77(0x00)0x00(0x00)0x7F(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x00(0x00)0x33(0x00)0x5A(0x00)0xC0(0x00)] = 1 + (32 * 3) + 1 bytes
1285207854.396118 : [0x27(0x2E)0x60(0x00)] = 1 + 3 + 3 + 1 bytes
1285207854.396135 : [0x20(0x0E)0x3F(0x00)] = 1 + 3 + 3 + 1 bytes
1285207854.400068 : [0x26(0x40)0x07(0x00)] = 1 + 3 + 3 + 1 bytes
1285207854.400086 : [0x61(0x40)0x00(0x00)0x00(0x04)0x00(0x00)0x00(0x00)0x00(0x75)0x00(0x06)0x00(0xFF)] = 1 + (8 * 3) + 1 bytes
--

So (if I can count properly) that would be encoded as 180 bytes in the binary format, sent in the course of 8ms. At a baud rate of 460800, that is basically 46080 characters per second = 368 characters in 8ms, which should be (and is) OK.

Even if the new wheel adds a few more bytes to the registers, this would still be under 368character/s and no where near the 4096 bytes of the ring buffer... so why would it fail?

Does this mean that it must be related to the SPI capture speed.... which is dependant on PIC clock.
Simon
13
Bus Pirate Support / Re: Pin modes in Binary SPI Sniffing causing problems?
OK here are some screen caps from a scope. Ch1 Enable, Ch2 Clock. Every 8ms the device sends/rends a short packet (RF config/hop), a medium packet (wheel position) and a long packet (force feedback state).

Clock period = 0.5us
Maximum burst rate = 35 bytes in 222us

So it would seem that this is too fast for the BP. Comments?
Simon
15
Bus Pirate Support / Re: Pin modes in Binary SPI Sniffing causing problems?
I did a bit more poking around. If I connect the CLK input to one of the data pins I get a continuous stream of data (fragmented into CS blocks), ie it does not turn off the LED.

In this posting:
http://dangerousprototypes.com/forum/index.php?topic=854.msg9084#msg9084

Ian suggested that if the capture system overflows then the BP falls out of sniff mode to SPI mode, at which point it would assert the CLK/data lines..... which would explain the failure in the RF link to the PC. This is probably a BAD idea as it will effect the system you are snopping.

I should also mention that I'm runing the serial link at 460800 (custom baudrate = '8'), couldn't get anything higher to work. Is there a way to have the BP just drop the data (not send via serial) so that it can be confirmed whether it is the capture or TX which is too slow?

Brain is completely dead, so I'm going home. I'll try to get a scope on the board tomorrow to confirm the CLK speed. It may be too fast for the BP. :-(
Simon

( ! ) Fatal error: Uncaught exception 'Elk_Exception' with message 'Please try again. If you come back to this error screen, report the error to an administrator.' in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
( ! ) Elk_Exception: Please try again. If you come back to this error screen, report the error to an administrator. in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
Call Stack
#TimeMemoryFunctionLocation
10.01652449352session_write_close ( )...(null):0
20.01682580952ElkArte\sources\subs\SessionHandler\DatabaseHandler->write( )...(null):0
30.01682581728Database_MySQL->query( ).../DatabaseHandler.php:119
40.06192720464Database_MySQL->error( ).../Db-mysql.class.php:273