Skip to main content
Topic: BusPirate hangs in SPI sniffer mode. (Read 21839 times) previous topic - next topic

BusPirate hangs in SPI sniffer mode.

I recently purchased a BusPirate 3.6 from SeeedStudio.  My primary use for the BusPirate is to monitor SPI communications using the spi sniffer program.  Everything seems to work fine until the spi traffic increases to more than a few bytes per second.  The BusPirate just stops passing any output to the PC and turns off its mode light.

After that happens and I close spi sniffer then connect to the serial port with TeraTerm, the BusPirate does not respond correctly.  Pressing keys on the keyboard while in TeraTerm causes the BusPirate to emit single lower case characters (one character is displayed for most keys pressed).  I am guessing that this is a bug. 

I set breakpoints in the spi sniffer program to verify that it doesn't transmit anything to the BusPirate after it has finished configuring the BusPirate and switching the BusPirate into spi sniffer mode.  So spi sniffer is not the cause of the problem.

The BusPirate arrived with v5.1 firmware on it.  I upgraded first to v6.1 then to v6.3 beta, with no change in behavior.  I was running the SPI clock at 16 MHz, then I dropped the speed to 1 MHz then 250 kHz, again, with no change in BusPirate behavior.  (Well, at 1 MHz, but not at the other speeds, I noticed errors (dropped bits) in the data sent from the BusPirate to the PC.)  (Also, the MCU that I'm using won't transmit any more slowly, unless I also drop the main clock speed.) 

Is there anything else that I can try, or do I just write off the BusPirate?

Re: BusPirate hangs in SPI sniffer mode.

Reply #1
There are thousands of BP's out there, so I'm sure somebody here will be able to make a suggestion. About the only thing I can suggest as a first thing is to check your supply lines out and insure it's got the correct voltages in and out of the reg. Check the board for any dry joints, etc. If it turns out to be a dud unit, then contact Ian and he'll let you know what to do.

Re: BusPirate hangs in SPI sniffer mode.

Reply #2
Thanks for your response!  My chip is an Atmel Xmega mounted in an Atmel STK600 development board.  That board has a programmable voltage power supply.  The PC read out shows 3.2 V.  I just put a meter on some pins and I show 3.3 V.  (The upper voltage limit for Xmega chips is 3.6 V.)

I just spent more than an hour looking on line and I can't find anything definitive.  Bus Pirate pins appear to be variously 5 or 5.5 V tolerant.  I assume that the Bus Pirate runs natively at 3.3V, so I thought that an SPI bus running at 3.3 V wouldn't be a problem.  (Please let me know if I'm doing it wrong.) 

I've clicked on numerous links promising to take me to a Bus Pirate manual.  They all lead to:

http://dangerousprototypes.com/bus-pirate-manual/

...which appears to be an advertisement for selling more Bus Pirates.

When the Bus Pirate shuts down on me, I also see a slight flicker on the USB LED.  About 15 bytes arrive in a final packet before the Bus Pirate stops sending output.  Is there perhaps a bug in the USB stack?

Re: BusPirate hangs in SPI sniffer mode.

Reply #3
OK, that link does indeed go to an 'advert' of sorts, interesting. 

This link will take you to the circuit for the 3.5, which is very similar
http://dangerousprototypes.com/docs/ima ... e-v3.5.png

This one will take you to the BP FAQ
viewtopic.php?f=4&t=271

and this is the area of the forum specifically for the BP, though you likely already know that, as you posted here!
viewforum.php?f=4

I was actually meaning to check the voltages and soldering on your BP. Whilst I believe they are tested at manufacturing, it's always possible something didn't show up as a problem in testing. There are thousands of people using BP all the time, so if there is a problem, it would be brought up pretty quickly, especially with something as common as SPI. Even I have a BP I built, though I haven't got to using it as yet.

Usually there is tons of people that can help, but as Ian has been moving lately, he's not around quite as much recently. I'm pretty limited with what help I can give you, but I expect it's either that there is something wrong with the BP (less likely, but certainly possible), something wrong with your hookup / configuration, or something wrong with your test circuit. From what you describe it does sound like the BP is having trouble for some reason, but that could possibly be because something is causing it to fail, like for instance an incorrect hookup (just a possibility, not suggesting this is the case). If you have another circuit with a known good SPI setup, then it would be worth trying it on that and see what happens.

Also make sure you have a good 'Common' (Ground, 0V, whatever you like to call it) between the BP and your test circuit. None of that seems to explain why the BP would stop responding, but perhaps something odd is occurring. If you haven't already done so, also try another USB port and USB cable. If you are going via a Hub, try going direct, as it could be the hub isn't supplying sufficient power. Check the supply voltages on the DP before and after the fault occurs, both on the input to the regs and the output (be careful not to short anything).

Hopefully somebody with a bit more experience specifically on the BP will drop by and help you out soon, they are usually a very helpful lot around here  :)

Re: BusPirate hangs in SPI sniffer mode.

Reply #4
Thanks again.  I just inspected the board with a microscope.  All of the solder joints look good.  There is a solder bridge between pins 25 and 26 on the FT232RL chip, but those are both tied to ground. 

I checked the voltages on the board.  VR1 looks fine before and after the event.  VR2 and VR3 aren't used in SPI sniffer mode.  However, I did get them enabled and they appear to be fine too.  (I have no way to enable them once the event has occurred.)

I had already experienced some issues when plugged into a USB hub.  So I'm plugged into a USB port on the motherboard.  I don't think that power is an issue.

The STK600 isn't much more than a glorified break out for the Atmel chips.  I'm connected directly to the SPI pins on the Xmega chip.  The only things on the SPI bus are the Xmega chip and the Bus Pirate.  I have the 4 standard SPI pins plus ground connected to the Bus Pirate.  I have no reason to believe that there is any issue with the ground pin.  Before the event occurs, the Bus Pirate is showing what I'd expect from the MISO and MOSI signals, so I'm reasonably sure that I have everything hooked up correctly.

Re: BusPirate hangs in SPI sniffer mode.

Reply #5
One thing that I've noticed is that very often (if not always), I see the following sequence of bytes immediately before the Bus Pirate stops transmitting: 

[B1(00)00(00)10(00)][00(FF)

(I've dispensed with the punctuation character key codes.)  I'm not sure if that means anything, but it's strange if it's only a coincidence.

Re: BusPirate hangs in SPI sniffer mode.

Reply #6
OK, well it *seems* like nothing is being sent back when the problem occurs, so if it were me, I'd be trying to determine what part was not working. As it's using the FTDI, it should, I assume, be possible to check the TX and Rx to see if the FTDI is working properly or not. Whilst there is the Rx LED, I'd check the actual lines with a logic probe, CRO or whatever else you have, to determine if data is going in or out of the FTDI.

If you have a CRO, it's probably worth having a look at the ripple on the outputs of the relevant reg(s). Whilst it's very unlikely to cause any issue, many of us have found quite high levels of ripple with some of the LDO regs, as discussed in a post somewhere here. Might be just worth a look anyway, if nothing else than for curiosity.

Do you have a similar problem if you run 'fast' (fast enough to cause the problem) data through it of other types, eg. UART, I2C, etc?

Re: BusPirate hangs in SPI sniffer mode.

Reply #7
Oops, seems you were posting when I was writing. Your observations are interesting, though I'm not sure what to make of it either. Whereabouts are you located? It might be that there's somebody in your area with a BP that could be used for a sanity check.

Re: BusPirate hangs in SPI sniffer mode.

Reply #8
A couple of things make me think that it's the software in the MCU and not the FTDI chip.  As I mentioned before, the "Mode" light goes out at the same time that the last USB packet is transmitted.  After an event, the MCU will still communicate via USB, that is, it will respond to characters sent to it (most of them anyways) but it's in some strange mode. 

It looks very much like the MCU has dropped out of SPI sniffer mode, and that's the only reason why it has stopped talking.  (Once the chip is in SPI sniffer mode, the SPI sniffer program doesn't send any more characters to the Bus Pirate, and the Bus Pirate pretty much doesn't send out anything over USB except if it's in response to some input, or its in sniffer mode.)

I had been using TeraTerm so far to interrogate the Bus Pirate, and that wasn't getting me anywhere.  I downloaded Hercules Setup, but so far I've been unable to get it into a mode where it will echo bytes in ASCII and hex the same way that I've seen Ian do in his videos, so it's very hard for me to see what I'm doing.  (Any hints?)

In any case, I started a sniffer session in Hercules and I triggered an event.  After the event, it appears that the Bus Pirate is indeed in some binary mode.  It responds to a binary 0x01 command with "SPI1", which should indicate that either it was in BBIO mode and just switched to SPI mode, or it was in SPI mode and was just echoing its version number.  In either case, the Bus Pirate's Mode light should be on, and it's not, so it's in some other (confused) mode. 

Without useful hex output, I couldn't really go any further with Hercules so I switched to RealTerm.  (Each program seems to have its limitations.  I couldn't even get the Bus Pirate into sniffer mode using RealTerm.)  I tried some other binary SPI mode commands.  Some commands, like 0x0E (i.e. enter sniffer mode) that should return a response, (i.e. a status, 0x00 or 0x01) don't appear to do anything at all (but that could just be RealTerm).  Other commands that I would expect to always return success, return a 0x00 status.  The CS low and CS high commands return a 0x01 status, but don't appear to do anything (the Bus Pirate CS pin appears to remain in high impedance mode).

A Logic Sniffer arrived from SeeedStudio on Saturday.  I haven't had a chance to figure it out yet.  The pincer-like probes provided by Seeed will grasp the FTDI chip's pins, but I can't see any way to do it without shorting to adjacent pins.  The pins are just too close together.  My oscilloscope probes won't even grasp the pins.  I'll need to fashion some different probes before I can get anywhere with the Logic Sniffer.

Re: BusPirate hangs in SPI sniffer mode.

Reply #9
Yes, the stuff you point out here does seem to put the light back on the micro. It's always possible it's a faulty micro. It might even be worth contacting Seeed and requesting a warranty. Ian doesn't seem to be around lately, I know he was really busy with the move and probably still is - or he's just enjoying running around China ;)

You can make up fine probes by getting a set of good quality needles from a Sewing shop (cheap ones often break too easily or blunt out). You grind the area around the eyelets a little to get to a better surface for soldering the lead on and use a good flux or worst case use a small screw terminal or similar. You can put that inside a housing like the plastic case of a marker, etc. and epoxy it in place. These sorts of things can be really useful for probing fine pitch devices, especially as you can make up different size ones, so are handy in general, not just for this problem.  The quick and dirty alternative is to use a pin or needle and just clip an alligator clip lead on the end.

Obviously with a probe you sometimes kind of need 3 hands or somebody assisting. An alternative is to solder a thin wire onto the pin you need by masking the other pins - Amad from Ultrakeet wrote up a good article on this (don't tell him I said it was good, he'll get a big head) here http://http://ultrakeet.com.au/write-ups/kaptonMasking#pmask

If you aren't considering sending the board back for replacement, then you could cut the Tx and Rx lines and temporarily bridge them together at the FTDI, then make sure it echos when shorted, as well as not echos when open. I fully expect that would be fine, so might be a useless test, but just a thought.

The Logic Sniffer might give you some answers anyway, if you can sort some suitable probes.

Comms programs - well there's heaps and yeah, they have their good and bad points. When I'm really digging and really need to see what's going on, I usually turn to XTALK, the old DOS version amazingly enough, it's served me well since those days and still does, even in Vista and using VCP. It's solved many problems for me when other programs couldn't. I sometimes you Roger Miers' 'CoolTerm', it's 1 bit clunky for the way I like things and I would like to change some things, but you could try it.  http://http://freeware.the-meiers.org/

 

Re: BusPirate hangs in SPI sniffer mode.

Reply #10
Hi, sorry for the late replay. I'll take a look at this issue over the weekend, and get back too you on monday. Ill try to recreate it on my own BP 3.6 ...

can you give me more info on how the issue is caused... what mode are you using.. etc... SPI setup, even the string of bytes you are sending over SPI, would help..

One possible culprit could be a bad SPI setup on the BP, although it sounds more like a firmware problem.. 

can you post the log from your Bus Pirate terminal from power on until it starts to hang
best regards FIlip.

Re: BusPirate hangs in SPI sniffer mode.

Reply #11
I was unable to reproduce the error... please get back to me with the info above if posible.
best regards FIlip.

Re: BusPirate hangs in SPI sniffer mode.

Reply #12
Thanks

Unfortunately, Im on a boat in the Carabean sea, 5000 km from my BP

Ill be back in civilization on the 31st.  Ill try to get a log for you then.

Re: BusPirate hangs in SPI sniffer mode.

Reply #13
Oops, seems you were publishing  when I was composing. Your findings are exciting, though I'm not sure what to  create of it either. Location are you located? It might be that there's somebody in your place with a BP that could be used for a peace of mind examine.

Re: BusPirate hangs in SPI sniffer mode.

Reply #14
Has anyone solved this? I have the same problem. My BP is v3a and the firmware is 6.1. I'm using bitbang mode, sniff all command. I'm using a python script but I have try with realterm too with the same result. The commands I'm using are the following:

x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00 ->BitBang mode
x00000001 -> SPI mode
x10001100 -> Configure SPI: w=3.3v, x=CKP idle= 1, y=CKE edge = 0, z=SMP sample midle
x01001100 -> Configure peripherals: power on, pullup on (I have also try with pullup off)
x00001101 -> Sniff SPI traffic (all)

I can sniff lots of bytes but suddenly mode led turns off and BP hangs. If I restart BitBang mode and rerun the script I can snif again until It hangs too. I think it is a firmware problem.

Thanks!