MSP430 Launchpad Logic Analyzer

[Markus Gritsch]

I think the maximum sample buffer depth OLS can address is 256 kSamples: The "Set Read & Delay Count (81h)" command specifies the count divided by four [1], and because the command uses two bytes this results in 0xFFFF * 4 = 256 kSamples.

So two 23LC1024 would be perfect :)

[1] http://dangerousprototypes.com/docs/Log ... ommands.29

[oPossum]

Ok, here it is...

Eagle files for all four designs:

logicboost_eagle.zip

(130.06 KiB) Downloaded 86 times

[Markus Gritsch]

Great, thanks! I think this is a reasonable optimum. More sample memory cannot be addresses by the OLS and more channels are not easily connected to the MSP430. Besides, 8 channels should be enough for a lot of use cases :) Do you think it would be worth having the MSP430 also on the same PCB and have the whole thing being powered over the FTDI adapter?

[oPossum]

I prefer to have something that can be used with the whole Launchpad family - MSP430, C2000 & Stellaris.

There may be a Launchpad with a MSP430 F5000 series chip soon. That would eliminate the need for the FTDI chip.

[Markus Gritsch]

Good point. The Stellaris LaunchPad also has USB-device capabilities, so it would also make the FTDI chip obsolete.

[oPossum]

Yes, and the C2000 has a FT2232 chip - one channel for program/debug and the other for user comms.

[Markus Gritsch]

The FTDI chip has a master bit clock of 3 MHz (48M / 16) and the MSP430 has a master bit clock of 1 MHz (16M / 16). The greatest common factor is 1 MHZ. So the ideal bit rates are 1,000,000 / N, where N is an integer.

Thanks for clarifying this. I tried setting the baud rate to 1M in the MSP430 code and when setting the FTDI chip to this "proper" bit rate I can successfully transfer the 256 kSamples in a bit under 3 seconds using my Python script. Great!

I hope the RXTX library used by OLS gets fixed soon, so that one can also use this high Baud rate with the OLS.

[Markus Gritsch]

I prefer to have something that can be used with the whole Launchpad family - MSP430, C2000 & Stellaris.

Although it might be desirable to have the board reroutet for other LaunchPad members anyway, to better match the port-to-pin mapping. For example I had a quick look at the Stellaris LaunchPad and the P2.0-P2.5 data lines from the Logic Boost are placed quite randomly between the ports of the Stellaris chip.

@oPossum:
Do you plan to write a firmware for the Stellaris Launchpad which interfaces with your Logic Boost?

[t0mpr1c3]

Do you plan to write a firmware for the Stellaris Launchpad which interfaces with your Logic Boost?

It *would* be very cool.

[hlipka]

Thanks to the FreePCB drawer, I got my hands on a LogicBoost board. I got it build up last weekend, and after discovering that I need to swap RX and TX on my launchpad it worked without problems (it's a 1.3 version which doesn't work with the hardware UART ouf-of-the-box). I have written up a blog post about it, with more detail of the build and some pictures. Here just the one from the build:

Next step will be building a USB-to-UART cable, to have it connect faster than 9600 baud. My main gripe is that the FTDI header doesn't use the Vcc pin, so I cannot power the board via USB in an easy way (an additional connector to the power pins is needed...).

Btw: the baud rate definition in main.c has a small error - the value is defined as int, not as long, so the compiler mangles this when setting a larger value like 115200...

Thanks for this design, it is a neat little board and will be quite useful in my toolbox.

[Markus Gritsch]

Hi,

I too got my free PCB on Friday (thanks a lot!) and built it over the weekend.

I made a quick proto board containing the MSP430G2553 to free up my LaunchPad for other things.

Further, I added a connection from the FTDI board's VCC pin to power the circuit.

From reading the serial RAM datasheet I was a bit concerned that the 50 mA which the FTDI chip can provide might not be enough (since the maximum read current at 20 MHz is specified to be 10 mA per RAM chip), but it turns out the whole circuit consumes just about 15 mA.

@hlipka: The baud rate definition in main.c was already mentioned earlier in this thread :)

Currently I am waiting for the 5 cm x 5 cm Sick of Beige cases to appear at Seeed Studios store, and for a new version of the OLS which hopefully will fix the serial buffer overflow issue at higher baud rates.

[hlipka]

That looks quite nice, especially since you don't need a launchpad. I think I will do the same. Unfortunately I killed my '2553 while programming it on my old launchpad - it doesn't send anything on the TX pin anymore. I guess I should have removed the TX/RX jumpers before programming, since then there are 2 TX pins fighting against each other :(

[Markus Gritsch]

I made a little paper label. Please find the SVG file attached.

[skytoatar]

So I understand the how SUMP protocol limits the buffer the 256k samples. But that seems like it should be a simple addition to the protocol to allow for longer buffer reads. I think using the 23CL1024 chips is a great idea and would love an 8 channel analyzer with 1024k samples. I like oPossum's design using two 23LC1024 chips. It could be a 1024/512/256k sample buffer for 2/4/8 channels. I also understand the downside that reading out the buffer over serial would obviously take longer the larger the buffer is.

It seems to me a new command would have to be added to the protocol to keep it backwards compatible with the existing protocol rather than modifying an existing command. This also seems like something that probably would have been brought up already. Is there a lot of demand for this or is everyone satisfied with 256k samples? Would the OLS client be difficult to modify to add this capability?

[Markus Gritsch]

Or, alternatively, the .cfg files could contain a new entry which specifies the sample-count multiplier, and which defaults to 4 when it is missing. This way the protocol would also be backwards compatible and could continue to use two byte values for the sample read and delay count.

@jawi, what do you think?