Skip to main content ↑ ↓

Show Posts

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

Messages - krishnak

1
Bus Pirate Support / Re: SPISniffer Unix Grep
I tried redirection stuff before but couldn't get it working. After too much of Java I have realised that I have forgotten the  basic C stuff :) that the  printf doesn't flush the buffer. I just added fflush(stdout) in the code (spisniffer.c) and recompiled - this has resulted in my grep working.

Thanks for your messages
2
Bus Pirate Support / SPISniffer Unix Grep
I am using SPISniffer and I am trying to filter out the output on screen by trying to use grep

/spisniffer -d /dev/ttyUSB0 -s 115200 | egrep -w 'Starting|Configuring|Entering|Happy|0xA8'

The problem I encounter is that only stderr messages are grepped.

Basically only the fprintf messages from SPISniffer

Is there a way I can grep the printf messages from SPISniffer which print out to stdout?
4
Bus Pirate Support / Re: Buspirate SPISniffer - Solved
Thanks Simon - I think my problem has been solved please see below.

Sleepwalker, you understood my postings correctly.

I measured the resistance between Vcc and MOSI on the remote - this was infinite (so were the  resistance of other SPI pins).

I had a 10K pullup to +Ve and MOSI, now the RF link stays when MOSI is connected to Buspirate

I have managed to sniff using SPISniffer in binary mode. So far I am connecting only at 115200 and it doesn't seem to complain about not keeping up.

Many thanks for all you guys who replied to this message to help me out.
5
Bus Pirate Support / Re: Buspirate SPISniffer
Hi Simon

I followed your advise and connected the remote with the 3.3V power output of the buspirate. The results are the same as before i.e as soon as you plug  in to MOSI the RF link (pairing) between the remote and its game console stops. Remote and bus pirate are still powered ON though. Did not use opto couplers as I don't have any fast one's handy.

Please note if you plug the MOSI before switching on the remote, the RF link is not established at all, irrespective of the power source.

I disconnected everything and did some analysis just with the remote control's MOSI,MISO,CLK,CSN and GND

When I measure the resistance between GND and any of the pins in the remote i.e MISO,CLK,CSN - the multimeter shows infinite resistance.

However between MOSI and GND it shows 125K.

I tried the following analysis - removed buspirate completely from the picture.

Exp 1

Powered on the remote with 2xAA battery

The remote powered ON and the RF link between console and the remote was established - there is a LED for RF link which gets lit.

Now I took a jumper cable and inserted it to the GND pin - other end of the cable is isolated from any contacts, it is just floating.

Now I took another jumper cable and inserted to each one of the following pins one pin at a time, MISO,CLK,CSN. This cables other end is isolated and floating as well. I inserted in to MISO - RF linked stayed ON. Hence removed the jumper cable and inserted in to CLK and so on.

When the cable was inserted in to the MOSI pin on the remote the RF link stopped working.

Please note the inserted cable's other end is not connected to anything else and the other end is isolated.

I repeated this experiment several times and I got the same result each time.

Exp 2

Remote powered with 2AA batteries. RF link up.

I removed the extra jumper cable from GND, which was used in the previous experiment.

Now I tried inserting a jumper cable in to MISO,CLK,CSN one pin at a time - RF link stayed ON. The jumper cable's other end is isolated.

Only 1 cable is used and it is plugged and unplugged from each PIN.

I tried inserting it in to MOSI - RF linked stayed ON.

Moved the cable with reasonable force in the MOSI header to see whether to check whether any shorts, none - RF link stayed ON. Unplugged, replugged this cable in MOSI several times - RF link stayed ON.

With the cable plugged inside MOSI header, I inserted a separate jumper cable (not connected to any where) to the GND header - RF link stayed ON.

After a while, when the jumper wire was still plugged in the GND, I removed the jumper cable from MOSI. RF link dropped.

I repeated this several times and am able reproduce it every time.


The MOSI pin seems to disrupt the RF link only if the ground gets connected to something even if it is a simple wire.

The snooped data with RF link down is something like this (this data was captured when the remote was powered ON with MOSI plugged in and hence no RF link)

[0x81(0xFE)]
[0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)0x00(0xFF)]
[0x04(0x39)]
[0x88(0xF3)]
[0x42(0x1C)]
[0x40(0x1F)]
[0x01(0x3F)]
[0x03(0x0F)]
[0x23(0x0F)]

after the above data, 0x03 and 0x23 keep repeating in no particular order

Do you make out any thing from this information?

Does the remote employ some anti snooping mechanism?
6
Bus Pirate Support / Re: Buspirate SPISniffer
I have tested the buspirate SPISniffer utility against a PIC24 on a Microstick and a RaspberryPI, the SPI sniffer utility is picking up the data with out disrupting anything. So there doesn't seem to be a fault with the MOSI line on the buspirate.
7
Bus Pirate Support / Re: Buspirate SPISniffer
No luck with the firmware upgrade - it is still behaving in the same way. I am going to try to sniff some other SPI traffic between a PIC24 and a RaspberryPI and see whether the sniffer really works on the buspirate. In that way I can probably eliminate whether the issue with the buspirate or the remote.
8
Bus Pirate Support / Re: Firmware update on Linux ?
[quote author="Arkku"]You can exit [tt:]screen[/tt:] by pressing Ctrl-a k. (i.e., hold down ctrl, press a, let go of both keys, press k)

If this is a problem for some reason, try this:

Code: [Select]
stty 115200 </dev/ttyUSB0
echo -e '$rny' >/dev/ttyUSB0

If that doesn't work, replace the [tt:]echo[/tt:] line with: [tt:]cat >/dev/ttyUSB0[/tt:] and type [tt:]$<enter>y<enter><Ctrl-d>[/tt:][/quote]

I am sorry to post to this old thread. Can you please update the firmware upgrade documentation to include the step described above to exit the terminal/screen. It is not quite obvious for some one new to screen.
9
Bus Pirate Support / Re: Buspirate SPISniffer
Dear Tayken

The version is

Bus Pirate v3a
Firmware v5.10 (r559)  Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)


I am not sure whether the latest Firmware V6.x is suitable for this board?

Could you please confirm.
10
Bus Pirate Support / Re: Buspirate SPISniffer
I have tested again using ubuntu and windows, after double checking for shorts etc.

I am running the SPIsniffer utility on the buspirate, I am connecting the remote control's SPI pins to buspirate SPI pins

MISO, CLK,CS,GND

As soon as I connect the MOSI from buspirate to the remote, the remote looses pairing.
11
Bus Pirate Support / Re: Buspirate SPISniffer
Tried with laptop just on batteries. It didn't make any difference.

My earlier observations were with a Ubuntu Laptop.

I ran the test on a Windows 7 Laptop

However there is a change to my earlier observation, the pairing stays put with 3 pins connected  i.e CS,CLK and MISO - it is only when MOSI is connected the pairing stops.

The pairing stays put with the three pins connected to the remote before or after it was switched ON.

But connecting the MOSI pin disrupts the pairing.

I will try to run the test again using Ubuntu to see whether I am able to reproduce the same behaviour as windows or whether I get my earlier issue of CS and CLK disrupting the pairing.
12
Bus Pirate Support / Re: Buspirate SPISniffer
Thanks for you reply. I did try that i.e plugging everything between the buspirate and the remote. then turning on Sniffer and then remote. When I do that the remote doesn't get paired at all.
13
Bus Pirate Support / Buspirate SPISniffer Solved
Hi

I got the bus pirate  V3 yesterday. So still a newbie with it.

I am trying to snoop SPI data using it and have hit some problems.

I have a Wiimote like remote control for a game console.

The remote and the console both communicate wirelessly using NRF24L01 nordic chip.

The remote has a led on it to show that it is paired with the game console (you need to press a button on the console and the remote simultaneously to pair them, once paired they are paired for ever).

In the remote, a micro controller communicates with the nRF via SPI.

I am trying to  use buspirate along with SPIsniffer utility to capture the data transfer between the microcontroller and the nrf chip on the remote.

On the buspirate, I run SPIsniffer program - it shows the following at start up

 Parameters used: Device = /dev/ttyUSB0,  Speed = 115200, Clock Edge= 1, Polarity= 0
 Opening Bus Pirate on /dev/ttyUSB0 at 115200bps...
 Starting SPI sniffer...
 Configuring Bus Pirate...
 Entering binary mode...
 (OK) Happy sniffing! Press ESC to stop.
Sync

At this point I have the remote and the game console both powered ON, the LED on the remote shows that it is paired with the game console.

When I start connecting the MISO,MOSI,CLK and CSN to corresponding pins on the remote control (there are proper header)
the pairing light on the remote control goes off - i.e the remote and console no longer communicate.

After some trial and error, I have narrowed it to MOSI pin, i.e when the MOSI pin from bus pirate gets connected to the corresponding SPI pin on the remote, the pairing on the remote switches off. The remote has to be power cycled and bus pirate disconnected to enable the pairing again.

Because of this I am not able to get the SPI data when the remote is paired with the game console.

However I do get SPI data when there is no pairing - the following data gets repeated again and again from the SPI bus
[0x03(0x0E)0x20(0x03)]
[0x00(0x0E)0x0C(0x08)]
[0x03(0x0E)0x20(0x03)]
[0x00(0x0E)0x12(0x08)]
[0x03(0x0E)0x20(0x03)]
[0x00(0x0E)0x00(0x08)]
[0x03(0x0E)0x20(0x03)]
[0x00(0x0E)0x07(0x08)]
[0x03(0x0E)0x20(0x03)]
[0x00(0x0E)0x00(0x08)]
[0x03(0x0E)0x20(0x03)]
[0x00(0x0E)0x01(0x08)]
[0x03(0x0E)0x20(0x03)]
[0x00(0x0E)0x00(0x08)]

Could some one throw some light on to why the nordic chip looses its pairing as soon as a SPI probe is plugged in from buspirate and any ideas to over come it.

Many thanks

( ! ) 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.01682410336session_write_close ( )...(null):0
20.01722541912ElkArte\sources\subs\SessionHandler\DatabaseHandler->write( )...(null):0
30.01722542688Database_MySQL->query( ).../DatabaseHandler.php:119
40.06672681408Database_MySQL->error( ).../Db-mysql.class.php:273