Dangerous Prototypes

Dangerous Prototypes => Bus Pirate Support => Topic started by: Homens on October 01, 2013, 07:07:11 pm

Title: BusPirate hangs in SPI sniffer mode.
Post by: Homens on October 01, 2013, 07:07:11 pm
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?
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Sleepwalker3 on October 04, 2013, 01:02:03 pm
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.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Homens on October 05, 2013, 10:04:56 am
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/ (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?
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Sleepwalker3 on October 05, 2013, 12:58:08 pm
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 (http://dangerousprototypes.com/docs/images/4/4d/Cct-BusPirate-v3.5.png)

This one will take you to the BP FAQ
viewtopic.php?f=4&t=271 (http://dangerousprototypes.com/forum/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 (http://dangerousprototypes.com/forum/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  :)
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Homens on October 05, 2013, 11:41:49 pm
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.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Homens on October 07, 2013, 09:50:26 am
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.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Sleepwalker3 on October 07, 2013, 09:59:12 am
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?
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Sleepwalker3 on October 07, 2013, 10:05:16 am
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.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Homens on October 07, 2013, 12:45:39 pm
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.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Sleepwalker3 on October 07, 2013, 02:24:05 pm
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/
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: arakis on October 11, 2013, 04:53:48 pm
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
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: arakis on October 14, 2013, 10:41:55 pm
I was unable to reproduce the error... please get back to me with the info above if posible.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Homens on October 19, 2013, 01:37:01 pm
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.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: lilianjie on November 20, 2013, 09:15:06 am
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.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: juanma on January 02, 2014, 02:15:14 am
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!
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: tayken on January 02, 2014, 09:52:47 am
Can you upgrade to 6.2 or 6.3 and try again?
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: juanma on January 02, 2014, 10:09:36 am
I will try, but where can I find 6.3 version?
Thanks!
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: juanma on January 02, 2014, 06:14:08 pm
Can I install firmware 6.3 in a BusPirate v3a? Where can I find this version?  I have only found this:

For BPv4:
http://code.google.com/p/dangerous-prot ... 4-firmware (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn%2Ftrunk%2FBus_Pirate%2Fpackage%2FBPv4-firmware)

General:
http://code.google.com/p/dangerous-prot ... loads/list (http://code.google.com/p/dangerous-prototypes-open-hardware/downloads/list)

In the last link you can only find firmware 6.1 or 6.2beta1
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Sleepwalker3 on January 02, 2014, 06:34:55 pm
If you're like me, you find the repositories a bit overwhelming and confusing, they can take quite a bit of digging around.
Try here
http://http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/#svn%2Ftrunk%2FBus_Pirate%2Fpackage%2FBPv3-firmware 
there is a number of V6.3 builds there for BPV3

Hope that helps :)
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: sre71 on January 02, 2014, 08:08:47 pm
Hi there,
a bit OT but maybe this can help.
Bus Pirate v3.6 using firmware v6.3-beta1 r2151 Bootloader v4.4, when performing # command (RESET) I get:

HiZ>#
REÿ
Bus Pirate v3.5
Firmware v6.3-beta1 r2151  Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com (http://dangerousprototypes.com)
HiZ>
 
I guess the word "REÿ" in the beginning should in reality be "RESET" like for previous versions.
There is a little bug.
This don't be annoying but remove it would be better IHMO.
Apologizing me for the OT, thanks in advance.
 
Kindest regards,
sre71
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: juanma on January 03, 2014, 12:04:03 am
Thanks Sleepwalker3, now I have downloaded and installed firmware v6.3 but the problem still happens. Maybe BP sniffs more bytes with v6.3 than with v6.1 but finally it hangs too.

I think the problem is that the serial can't pass the bytes at the rate the SPI sniffs, then the BP buffer overflows and BP hangs.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Sleepwalker3 on January 03, 2014, 01:09:22 am
I guess that might be possible, but I would have thought more people would have found the same problem if that was the case. I'll leave it to the experts like Arakis and Tayken.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: juanma on January 03, 2014, 01:35:14 am
In the beginning of the process, sniff rate is about 310 pair/sec and all is fine, but then the traffic increases and it is when BP hangs. These are the last 10 pair of bytes that BP sniffs:

IN   OUT   TIME (s)
20   ff   7.25218931456
00   98   7.25233626061
83   ff   7.25248320666
00   ff   7.25262959398
81   ff   7.25277598130
23   ff   7.25292236863
83   ff   7.25306903531
84   ff   7.25321570200
07   ff   7.25336180995
00   7a   7.25350819727

So when BP hangs it is sniffing at 1/(7.25350819727 - 7.25218931456) = 7582 pair/sec
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Sleepwalker3 on January 03, 2014, 01:45:10 am
If you are able to, it would probably be worthwhile keeping the data rate down to see if it handles it fine, even with a lot of data. That might show if it is rate dependant. Of course you might not be able to do that!
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: juanma on January 03, 2014, 01:53:05 am
No, I cant modify data rate.

Maybe Im wrong, but if com speed is 115200 and BP sends 3 bytes per pair sniffed (slash, in and out), the maximum sniff rate would be 115200/3/8=4800 pair/sec. Isnt it?
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Sleepwalker3 on January 03, 2014, 01:58:22 am
I'm pretty sure that's been covered before and that with the VCP it doesn't work like that. In short I think the 'Baud rate' is more just a token thing.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: juanma on January 03, 2014, 06:39:55 pm
Sorry, I dont understand... what do you mean, Sleepwalker3?
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: sre71 on January 03, 2014, 08:11:11 pm
Hi juanma,
maybe I'm wrong, it isn't the specific case, but I hope here you can find some hint:
viewtopic.php?f=4&t=5851 (http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=5851)
 
Best regards,
sre71
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Sleepwalker3 on January 04, 2014, 01:54:29 am
[quote author="juanma"]Sorry, I dont understand... what do you mean, Sleepwalker3?[/quote]

From my recollection, I think that the speed over the USB is not specifically governed by the Baud rate - not in the way that a real serial port would be. It's using the FTDI chip and the driver creates a 'Virtual Comms Port' (VCP), so the data throughput is more determined by the limitations of the driver and how fast the device on the other end (the BP) can clear it. Some FTDI chips I think have buffers too, so that that also affects things.  I could be wrong here and somebody may well correct me, but I believe the Baud rate only really affects comms at the far end - i.e. the BP processor <--> FTDI.  Anyway, one of the experts on the firmware will probably correct me here.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: juanma on January 04, 2014, 01:57:00 am
Thanks sre71. Actually this is what I do. I have try both writing in a text file throught  script code and piping the output of the console to a file with the same result.
What is very strange is that BP doesn't hang at the same moment each time (with the same method, I mean).
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: juanma on January 04, 2014, 02:02:54 am
Quote
but I believe the Baud rate only really affects comms at the far end - i.e. the BP processor <--> FTDI.

Sleepwalker3, it sounds right...
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: juanma on January 05, 2014, 03:21:24 am
I have done a very simple test to reproduce the problem: I have programmed an arduino as SPI source and I have done a few tests with different bytes per seccond. The arduino code is:

Code: [Select]
/*Simple SPI test 
  Pinout:
  GND  to ground
  CS  to digital pin 10
  MOSI  to digital pin 11
  CLK  to digital pin 13
*/

#include <SPI.h>

const int CSPin = 10;

void setup() {
  // set the CSPin as an output:
  pinMode (CSPin, OUTPUT);
  // configure SPI:
  SPI.setClockDivider(SPI_CLOCK_DIV2);
  SPI.setDataMode(SPI_MODE3);
  SPI.begin();
  digitalWrite(CSPin,LOW);
}

void loop() {
  SPI.transfer(0xFF);
  delayMicroseconds(200);
}

I have seen that with 400us in the delayMicroseconds function the BP works fine, but with 200 us the BP hangs the same way it does with the circuit im trying to sniff.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: tayken on January 05, 2014, 06:03:45 pm
OK, managed to dive into the source (never had to deal with SPI sniffer before) and have some insight on the problem, here it goes:
- Dived into the source code for actual sniffer. If you suspect that BP cannot keep up, try using the sniffer from the terminal. It gives out a warning, "Couldn't keep up", if there is an overflow.
- In binary mode (and terminal mode) the mode led turning off means there is a buffer overflow aka sniffed signal too fast.
- There is a circular buffer inside BP for things like this but it can overflow too.
- BPv3 uses the FTDI IC so there is a bottleneck between uC and FTDI interface which is UART at 115200 bps. I'm thinking the calculations are about right, but you cannot be precise.

In conclusion the reason for the hangs seems to be the buffer overflow. The reason for that is you SPI traffic picks up and we cannot send it fast enough through the FTDI and to the PC. And you mentioned that you cannot change the speed of the traffic and there is no faster baudrate (115200) on the menu. However, it may be possible to have a faster baudrate set up in the code (sorry you have to deal with that) that can fix your problem.

Or you have to have a specific hardware for transferring SPI to your PC. BP is like a Swiss Army Knife, you can use the screwdriver on it but using a real screwdriver is faster. :)
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: Sleepwalker3 on January 05, 2014, 09:56:59 pm
That's awesome work Tayken, thanks for the great insight, very informative. Obviously I was wrong (and kind of a little right) about the bottleneck being between the BP PIC and the FTDI. Not sure about the FTDI on the BP, but I think most of them are capable of going up to around 1M Baud rate and I think many have small buffers which perhaps haven't been pressed into service. If the PIC is capable of the throughput, then as you suggest, there may be a way of increasing the throughput by increasing the baud rate.

I imagine the BP V4 would be better in this respect, as far as throughput goes, so that might be an option for Juanma too.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: juanma on January 06, 2014, 02:22:18 am
SOLVED!! Thanks tayken and SleepWalker3!

Actually the limitation was in the UART speed between PIC and FTDI, that is by default 115200bps. I dont know why is 115200 the default speed in code and not higher speed while both pic and ftdi supports higher baudrate.

Anyway, what I have done is modify the baudrate manually through terminal menu option 'b' to 'BRG raw value' (I didnt know it could be done) with a value of 8, what means a baudrate around 460800bps. Then I have run my python script and the BP doesnt hang.

After that I have rewritten the script to modify the baudrate automatically at the beginning.

By other hand, I have take a look inside the firmware source and I have seen that the different baudrates are set in baseIO.c:

Code: [Select]
static unsigned int UARTspeed[] = {13332, 3332, 1666, 832, 416, 207, 103, 68, 34,}; //BRG:300,1200,2400,4800,9600,19200,38400,57600,115200

and the default index is set to 8 in main.c what means a baudrate of 115200bps:

Code: [Select]
   bpConfig.termSpeed = 8; //default PC side port speed, startup in 115200, or saved state (later)....

I havent read all the source code and I dont have any ideahow to compilethe firmware, but It seemsto be very easy to modify the baudrate to higher values even its possible to set BRG to 0 what means highest baudrate. Maybe If people finds it useful it could be changed in future firmware versions.

Thanks to every body!
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: tayken on January 06, 2014, 11:00:39 am
[quote author="juanma"]Actually the limitation was in the UART speed between PIC and FTDI, that is by default 115200bps. I dont know why is 115200 the default speed in code and not higher speed while both pic and ftdi supports higher baudrate. [/quote]
Well, BP was developed as a device that is controlled by a user. 115200 was enough at the time and it is pretty standard with similar devices. Binary mode and scripting works fairly well with the same baudrate so there was no need to change it.

[quote author="juanma"]Anyway, what I have done is modify the baudrate manually through terminal menu option 'b' to 'BRG raw value' (I didnt know it could be done) with a value of 8, what means a baudrate around 460800bps. Then I have run my python script and the BP doesnt hang.[/quote]
Yes, there is a raw value entry but I wasn't sure if it supported higher baudrate. Sometimes you have to edit a prescaler and from time to time that is not implemented in the code. :)

[quote author="juanma"]I havent read all the source code and I dont have any ideahow to compilethe firmware, but It seemsto be very easy to modify the baudrate to higher values even its possible to set BRG to 0 what means highest baudrate. Maybe If people finds it useful it could be changed in future firmware versions.[/quote]
Baudrate entry from the terminal is possible, so it is not really best to change the source. But not sure if implemented in binary mode. BRG = 0 means something like 4Mbps which may not be possible for FTDI to handle.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: juanma on January 06, 2014, 07:26:45 pm
[quote author="tayken"]Baudrate entry from the terminal is possible, so it is not really best to change the source. But not sure if implemented in binary mode.[/quote]

No, it is not possible to change baudrate from binary mode. What my script does is:

- Change BP baudrate in terminal mode through the 'b' option in the main menu.
- Reconfigure the baudrate of the com port used by the script to match the new BP speed.
- Enter the binary mode.
- Enter SPI function, configure SPI and sniff.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: tayken on January 06, 2014, 07:38:16 pm
That's what I guessed. I think we can use one of the unused binary mode keys for configuring it. You'll have to send the key first, then BRG. I'll start working on that and let's see if others like it.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: juanma on January 06, 2014, 08:00:14 pm
Thanks tayken.
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: sre71 on January 07, 2014, 08:24:18 pm
@juanma, @tayken
 
Thank you both, you saved my day!
I have learned something new I don't knew before.
 
@tayken
 
Kinda OT.
I know this isn't the right place, but I understand you want do changes in the firmware.
So I have noted another trunk message while performing b command:
 
Bus Pirate v3.5
Firmware v6.3-beta1 r2151 Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com (http://dangerousprototypes.com)
HiZ>
 
Enter raw value for BRG
 
(34)>8
Adjust your terminal
Space to conti
 
so pressing spacebar I get:
 
(34)>8
Adjust your terminal
Space to contiHiZ>
 
I guess "Space to conti" of course it mean "Space to continue".
Apologizing me for the OT, thanks in advance.
 
Kindest regards,
sre71
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: HSE on February 02, 2014, 02:45:32 pm
Hi guys,

I have just bought a BP to snif a SPI connection with the target chip allowing a maximum SPI frequency of 10 MHz. So from the description the BP should work perfectly fine in sniffer mode.
Anyways, when I use the binary sniffing tool it just stops working after a couple of bytes (around 20). The mode led turns off in that case. If I try it manually using a serial terminal, I get around 6-7 bytes followed by continuous lines "Couldn't keep up", mode LED staying on.

I have been reading this forum and trying everything I could find including increasing the baud rate to 960... baud (register value 3). The beaviour stays the same, though, and I just cannot get it to work.

Something I notived using my oscilloscope was, that on the board they are trying to "obscure" the data by inserting invalid clock pulses etc while the CS line is inactive. Maybe that has something to to with it..

Would be cool if anybode here could give me some hints to try :)

Thanks for your kind help,
Tobi
Title: Re: BusPirate hangs in SPI sniffer mode.
Post by: tayken on February 02, 2014, 03:26:25 pm
If it is giving you some invalid clocks, you may try to use some logic IC for getting clock and data when CS line is active. If it's active high, an AND gate will work. Just a though.