Using STM32F4 as a logic analyser (SUMP/8channels/21Mhz) – (not 24Mhz)

Posted by

or “Will my STM32F4-discovery board replace Arduino/Bus Pirate ? “…

Well I needed a logic analyzer to track some bugs in a project I am working on, but that could do more than the Bus Pirate OLS mode…

So I found this on the web : SUMP compatible logic analyzer code for Arduino.

But I also wanted a higher sampling rate.

– The code for the SUMP protocol was there from the Arduino project.
– I had the STM32F4 handy (the same I used for the MP3 – libmad port)
– The libopencm3 had a simple working example of a USB-CDC on the Discovery board

Go… Mixing everything in that code : here.
(you need libopencm3 in /opt/libopencm3)

Code update 28/04/2103 : Acquisition rate was in fact 21Mhz, there was a bug in function “cdcacm_data_rx_cb”, the acquisition loop is now in an asm-inline code which should prevent different code optimization by different compiler versions. Those problems were submitted by Iosif in the comments, many thanks to him. Here is the new code.

After some tests + optimizations , here is the result : 2421Mhz sampling, 8 channels (port PE8-15).

(For the moment, there is no configurable trigger, sampling frequency / buffer size. This is just raw code for my needs.)

  • Acquisition of a 1Mhz square wave generated by an Arduino (5v to 3v3 via a Zener diode – be careful STM32F4 is not 5V tolerant)
  • As it was mentioned in the comments, most STM32 pins ARE 5v tolerant, and I have confirmed this in the DM00037051 document, pages 48 & 49.

Setup (a ols.profile file is provided in the tgz)

10 comments

  1. Hi, I think there is currently a subtle bug in the current sump metadata implementation that results in arming for the capture. More exacly if you try to request “Show device metadata” in OLS (see your pictures above the dialog with “OLS capture settings”) the response to the 0x04 command contains buf[0]=1, that will also set the ARM capture which at least on Windows makes the program either crash or respond very slowly. I have recompiled the code with the arm option ahead of the metadata one and all seems fine.

    Apart from this minor issue the program is quite OK and thank you for making it available!.
    As a side note, I have also worked a bit on Thomas’ Stellaris version and implemented various delay options so that OLS can actually receive different sample rates. The same could be implemented for your version and it would make it more versatile. The tricky part is determining the proper delays. Please let me know if you would like to know more.

    All the best,
    Iosif

    1. Iosif,

      You are perfectly right : the cdcacm_data_rx_cb function should use a switch-case, or some ‘else’ statements to avoid that bug.

      I will release correction when I will have time. If you have some code to share, please send it to me (mail : jjmz at free.fr). I will try to include it.

      Thanks a lot,

      Jean-Jacques

      1. I think that this code would be better :

        static void cdcacm_data_rx_cb(usbd_device *usbd_dev, u8 ep)
        {
        (void)ep;

        char buf[64];
        int len = usbd_ep_read_packet(usbd_dev, 0x01, buf, 64);

        if (len) {
        len=0;

        switch (buf[0])
        {
        case SUMP_RESET:
        return;
        case SUMP_QUERY:
        buf[0]=’1′; buf[1]=’A’;
        buf[2]=’L’; buf[3]=’S’; len=4;
        break;
        case SUMP_GET_METADATA:
        buf[0]=0x01 ; buf[1]=’S’; buf[2]=’T’; buf[3]=’M’;
        buf[4]=’3′; buf[5]=’2′; buf[6]=’F’; buf[7]=’4′; buf[8]=0;
        buf[9]=0x21; buf[10]=0; buf[11]=0; buf[12]=0x1C; buf[13]=0;
        buf[14]=0x23; buf[15]=0; buf[16]=0xF; buf[17]=0x42;buf[18]=0x40;
        buf[19]=0x40; buf[20]=0x08;
        buf[21]=0x41; buf[22]=0x02;
        buf[23]=0x00;
        len=24;
        break;
        case SUMP_ARM:
        sending=1; addr=0; break;
        }

        if (len) while (usbd_ep_write_packet(usbd_dev, 0x82, buf, len) == 0) ;

        }

        gpio_toggle(GPIOD, GPIO13);
        }

  2. Hi,

    The modifed code should seems fine.
    I will have a go at understanding how to use timers (just to measure delays) on STM32F4 and I’ll send you my version when done. For the Stellaris it was easier as the Stellarisware interface makes it almost too easy, but for the STM I’ll try to use the libopencm3 as I saw you built upon it.

    Regards,
    Iosif

    1. The code only represents the stm32 side (libopencm3 is not included).
      OLS (the GUI) is a separate project.
      10 kb compressed is more than enough for this.

Leave a Reply

Your email address will not be published. Required fields are marked *