SLLogicLogger - A simple logic analyser for the Stellaris Launchpad

[Thomas1426459898 0]

Hi,

 

Here is my last project with the Stellaris Launchpad: SLLogicLogger - A simple logic analyser for the TI Stellaris Launchpad.

 

Logic levels on PORTB are sampled with 10MHz to RAM (16 kBytes) and then transmitted through the debugging controller over USB to a host computer. No additional hardware is needed - a pure Stellaris Launchpad connected over the debug-USB to an PC is enough. The firmware implements the main functions of SUMP, a serial protocol for logic analysers. There are some clients which supports SUMP. I used LogicSniffer OLS (http://www.lxtreme.nl/ols/) which is a multiplatform Java client. A simple OLS profile file is sufficient to read out the sampled data from the Launchpad.

Sampling starts on any state change on PORTB, no further trigger functions are supported yet.

 

Further description and download:

http://www.fischl.de/arm/sllogiclogger_logic_analyser_for_stellaris_launchpad/

 

The logic states are sampled from the GPIO to an array within an for-loop:

// sampling buffer
char buffer[BUFFERSIZE];

// aquire data
for (i = BUFFERSIZE; i != 0; i--) { buffer[i - 1] = GPIO_PORTB_DATA_R; }

With this method I get 10 MHz sampling rate at 80 MHz system clock. Does anybody know, if there is a chance to speed it up? E.g. using AHB, uDMA, ...?

 

Thomas

[bluehash 1,581]

Are you talking over serial or USB bulk.. I think you are doing serial as the Stellaris can only act as a HOST.

[Thomas1426459898 0]

The UART is used and is mapped through the "debugging Stellaris" to CDC/USB. This communication path ist not very fast but it matches the concept of SUMP.. sampling is done to RAM and in a next step is transmitted over serial to a PC.

[ben1066 0]

This is quite nice but a bit short on sample memory I can at most see 2 bytes of SPI data from my MSP to my 74HC595 for example. That said, if triggers were added it wouldn't be so bad.

[Pny 0]

With this method I get 10 MHz sampling rate at 80 MHz system clock. Does anybody know, if there is a chance to speed it up? E.g. using AHB, uDMA, ...?

The speed will depend of the optimization capabilities of the compiler. Using a byte pointer to the buffer and adressing it without the index is probably faster ( *ptr++ = GPIO_PORTB_DATA_R ). Unfolding the for loop will also increase speed at the expence of memory.

[Schtrak 0]

First, I'd like to thank Thomas for his work.

I have a rather lame question for the members of this forum.

Can I use a non-inverting buffer/converter (CD4050B, in particular) to convert the signal levels to 3.3V before I "feed" them to the microcontroller?

 

Thanks

[ronen1kr 0]

Why not use the CCP modules/pins for triggering ?

[sbuchholz 0]

Thomas

 

   Can I ask what complier your using to build this?

 

 

Thanks

[Bingo600 0]

Thomas

 

   Can I ask what complier your using to build this?

 

 

Thanks

 

While i don't know what compiler Thomas is using , my guess would be Yagarto.

http://www.yagarto.de/

 

It's a well proven arm-gcc compiler for windows , and the latest version generates very tight code.

That the Yagarto homepage and author is German based like Thomas , doesn't hurt either.

 

But that's all a qualified guess.

 

Thomas could be "linux based" ...

 

 

/Bingo

[tkg 0]

From the Makefile included in the sllogiclogger.2012-12-24.tar.gz archive it seems to be gcc.  

Please read the Makefile header and you will also have the links to the tools used. 

I can confirm that I have used a newer version of the GCC toolchain recommended there

to compile the project under MinGW Windows (just a bit more dificult than Linux) 

and with minimal modifications for the Stellarisware and the flasher paths in the makefile it built ok.

 

tkg

 

While i don't know what compiler Thomas is using , my guess would be Yagarto.

http://www.yagarto.de/

 

It's a well proven arm-gcc compiler for windows , and the latest version generates very tight code.

That the Yagarto homepage and author is German based like Thomas , doesn't hurt either.

 

But that's all a qualified guess.

 

Thomas could be "linux based" ...

 

 

/Bingo

[Pradeepa 1]

What is the maximum duration I can capture using this? I could only get 1.46ms which is not enough.
 

[igor 163]

 

What is the maximum duration I can capture using this? I could only get 1.46ms which is not enough.

 

From the first post 10m samples/second in 16 kb RAM should give about 1.6ms,

so what you are getting sounds in the right ballpark.

 

Either slow down sampling, or get something with more RAM (e.g., STM32 F4, Arduino Due, etc.).

[Pradeepa 1]

From the first post 10m samples/second in 16 kb RAM should give about 1.6ms,

so what you are getting sounds in the right ballpark.

 

Either slow down sampling, or get something with more RAM (e.g., STM32 F4, Arduino Due, etc.).

 

When I try to slow down the sampling time it says that the device not found. Only works at 10M. Any clue?

[igor 163]

What says device not found?  Can you post your code modifications?

(how much of a slowdown are you aiming for, how are you doing the slowdown - e.g. what adding to inner loop for delay, etc.)

[Pradeepa 1]

The logic sniffer app says so. I did not change the code. I used the available window in the provided software. So you suggest that I should change the code. I'll look into it. I thought changing the sampling time will change the period.