Loading ...
Sorry, an error occurred while loading the content.

Olimex STM32-P107 Ethernet driver

Expand Messages
  • max.holtzberg
    Hi, I m trying to get the stm32_eth driver working on a stm32f107vc. The uip example with DHCP enabled already asks for DHCP leases and gets responses. The
    Message 1 of 5 , Jul 4, 2012
    • 0 Attachment
      Hi,

      I'm trying to get the stm32_eth driver working on a stm32f107vc.
      The uip example with DHCP enabled already asks for DHCP leases and
      gets responses. The problem is that the DMA reception handling is not
      working as expected.
      The first ARP frame is written to the rx descriptor list and dispatched
      by the uip stack.
      After that "Receive buffer unavailable status" interrupts occur.
      That is what I don't understand, because all items are marked as DMA
      owned.

      If the DHCP times out and tries again, the same happens but
      the DMA uses the 3rd descriptor in the list.

      Any hint is welcome!

      Best regards from Hamburg

      Max Holtzberg
    • Gregory N
      Hello, Max, ... I wrote that Ethernet driver, but it has been awhile since I have worked with it. I am afraid that I don t have fresh memories and I don t
      Message 2 of 5 , Jul 4, 2012
      • 0 Attachment
        Hello, Max,

        > I'm trying to get the stm32_eth driver working on a stm32f107vc.
        > The uip example with DHCP enabled already asks for DHCP leases and
        > gets responses. The problem is that the DMA reception handling is not
        > working as expected.
        > The first ARP frame is written to the rx descriptor list and dispatched
        > by the uip stack.
        > After that "Receive buffer unavailable status" interrupts occur.
        > That is what I don't understand, because all items are marked as DMA
        > owned.
        >
        > If the DHCP times out and tries again, the same happens but
        > the DMA uses the 3rd descriptor in the list.

        I wrote that Ethernet driver, but it has been awhile since I have worked with it. I am afraid that I don't have fresh memories and I don't have any good insights off the top of my head.

        Does this only occur with DHCP? I don't believe that I have ever used DHCP with that driver. Have you ever tried using a fixed IP address? If so, does that work with any problems? If so then, it might be something specific to what DHCP does.

        DHCP is unique in that it uses UDP broadcast packets. Two things come to mind.

        1. First, there are some very special configuration requirements to use DHCP. These are described in apps/netutils/README.txt and duplicated here:

        If you use DHCPC/D, then some special configuration network options are required. These include:

        CONFIG_NET=y Of course
        CONFIG_NSOCKET_DESCRIPTORS And, of course, you must allocate some
        socket descriptors.
        CONFIG_NET_UDP=y UDP support is required for DHCP
        (as well as various other UDP-related
        configuration settings).
        CONFIG_NET_BROADCAST=y UDP broadcast support is needed.
        CONFIG_NET_BUFSIZE=650 The client must be prepared to receive
        (or larger) DHCP messages of up to 576 bytes (excluding
        Ethernet, IP, or UDP headers and FCS).

        The other thing that comes to mind is the Ethernet driver MAC filtering. Could there be any special hardware configuration that is missed for filtering broadcast packets in this case?

        Now, on the other hand, if your driver does not work with DHCP disabled, then that is another story. It is just broken.

        > Best regards from Hamburg

        And best wishes from Costa Rica.

        Greg
      • max.holtzberg
        ... Thanks for your quick reply! I tried your suggestions but there seem to be some issues in the driver for stm32f107vc. I will let you know when I fixed
        Message 3 of 5 , Jul 5, 2012
        • 0 Attachment
          --- In nuttx@yahoogroups.com, "Gregory N" <spudarnia@...> wrote:
          >
          > Hello, Max,
          >
          > > I'm trying to get the stm32_eth driver working on a stm32f107vc.
          > > The uip example with DHCP enabled already asks for DHCP leases and
          > > gets responses. The problem is that the DMA reception handling is not
          > > working as expected.
          > > The first ARP frame is written to the rx descriptor list and dispatched
          > > by the uip stack.
          > > After that "Receive buffer unavailable status" interrupts occur.
          > > That is what I don't understand, because all items are marked as DMA
          > > owned.
          > >
          > > If the DHCP times out and tries again, the same happens but
          > > the DMA uses the 3rd descriptor in the list.
          >
          > I wrote that Ethernet driver, but it has been awhile since I have worked with it. I am afraid that I don't have fresh memories and I don't have any good insights off the top of my head.
          >
          > Does this only occur with DHCP? I don't believe that I have ever used DHCP with that driver. Have you ever tried using a fixed IP address? If so, does that work with any problems? If so then, it might be something specific to what DHCP does.
          >
          > DHCP is unique in that it uses UDP broadcast packets. Two things come to mind.
          >
          > 1. First, there are some very special configuration requirements to use DHCP. These are described in apps/netutils/README.txt and duplicated here:
          >
          > If you use DHCPC/D, then some special configuration network options are required. These include:
          >
          > CONFIG_NET=y Of course
          > CONFIG_NSOCKET_DESCRIPTORS And, of course, you must allocate some
          > socket descriptors.
          > CONFIG_NET_UDP=y UDP support is required for DHCP
          > (as well as various other UDP-related
          > configuration settings).
          > CONFIG_NET_BROADCAST=y UDP broadcast support is needed.
          > CONFIG_NET_BUFSIZE=650 The client must be prepared to receive
          > (or larger) DHCP messages of up to 576 bytes (excluding
          > Ethernet, IP, or UDP headers and FCS).
          >
          > The other thing that comes to mind is the Ethernet driver MAC filtering. Could there be any special hardware configuration that is missed for filtering broadcast packets in this case?
          >
          > Now, on the other hand, if your driver does not work with DHCP disabled, then that is another story. It is just broken.
          >
          > > Best regards from Hamburg
          >
          > And best wishes from Costa Rica.
          >
          > Greg
          >

          Thanks for your quick reply!
          I tried your suggestions but there seem to be some issues in the
          driver for stm32f107vc. I will let you know when I fixed that.

          BTW very nice, beautiful project!!!
        • max.holtzberg
          ... After some further testing / investigating I figured out that the driver works correct if I switch off the uip example. The strange happenings start when
          Message 4 of 5 , Jul 8, 2012
          • 0 Attachment
            --- In nuttx@yahoogroups.com, "max.holtzberg" <max.holtzberg@...> wrote:
            >
            >
            >
            > --- In nuttx@yahoogroups.com, "Gregory N" <spudarnia@> wrote:
            > >
            > > Hello, Max,
            > >
            > > > I'm trying to get the stm32_eth driver working on a stm32f107vc.
            > > > The uip example with DHCP enabled already asks for DHCP leases and
            > > > gets responses. The problem is that the DMA reception handling is not
            > > > working as expected.
            > > > The first ARP frame is written to the rx descriptor list and dispatched
            > > > by the uip stack.
            > > > After that "Receive buffer unavailable status" interrupts occur.
            > > > That is what I don't understand, because all items are marked as DMA
            > > > owned.
            > > >
            > > > If the DHCP times out and tries again, the same happens but
            > > > the DMA uses the 3rd descriptor in the list.
            > >
            > > I wrote that Ethernet driver, but it has been awhile since I have worked with it. I am afraid that I don't have fresh memories and I don't have any good insights off the top of my head.
            > >
            > > Does this only occur with DHCP? I don't believe that I have ever used DHCP with that driver. Have you ever tried using a fixed IP address? If so, does that work with any problems? If so then, it might be something specific to what DHCP does.
            > >
            > > DHCP is unique in that it uses UDP broadcast packets. Two things come to mind.
            > >
            > > 1. First, there are some very special configuration requirements to use DHCP. These are described in apps/netutils/README.txt and duplicated here:
            > >
            > > If you use DHCPC/D, then some special configuration network options are required. These include:
            > >
            > > CONFIG_NET=y Of course
            > > CONFIG_NSOCKET_DESCRIPTORS And, of course, you must allocate some
            > > socket descriptors.
            > > CONFIG_NET_UDP=y UDP support is required for DHCP
            > > (as well as various other UDP-related
            > > configuration settings).
            > > CONFIG_NET_BROADCAST=y UDP broadcast support is needed.
            > > CONFIG_NET_BUFSIZE=650 The client must be prepared to receive
            > > (or larger) DHCP messages of up to 576 bytes (excluding
            > > Ethernet, IP, or UDP headers and FCS).
            > >
            > > The other thing that comes to mind is the Ethernet driver MAC filtering. Could there be any special hardware configuration that is missed for filtering broadcast packets in this case?
            > >
            > > Now, on the other hand, if your driver does not work with DHCP disabled, then that is another story. It is just broken.
            > >
            > > > Best regards from Hamburg
            > >
            > > And best wishes from Costa Rica.
            > >
            > > Greg
            > >
            >
            > Thanks for your quick reply!
            > I tried your suggestions but there seem to be some issues in the
            > driver for stm32f107vc. I will let you know when I fixed that.
            >
            > BTW very nice, beautiful project!!!
            >

            After some further testing / investigating I figured
            out that the driver works correct if I switch off the uip example.
            The strange happenings start when uip_lockedwait(&state.acpt_sem)
            is called.
            So I tried the ostest app and there seem to be similar issues
            see [1]. I wonder if its a bug or me.
            I adapted the linker script from stm3210e-eval and changed the
            memory section according to the stm32f107vc soc. In the config
            file a changed:

            CONFIG_DRAM_SIZE=0x00010000
            CONFIG_DRAM_START=0x20000000
            CONFIG_DRAM_END=(CONFIG_DRAM_START+CONFIG_DRAM_SIZE)

            Is that sufficient for a working memory configuration?

            [1] http://pastebin.com/JdZmLdHH

            Max
          • Gregory N
            Hi, Max, ... Yes, that should be sufficient. In your attachment, I see that you are getting a hard fault. So something is very wrong with your configuration.
            Message 5 of 5 , Jul 8, 2012
            • 0 Attachment
              Hi, Max,

              > I adapted the linker script from stm3210e-eval and changed the
              > memory section according to the stm32f107vc soc. In the config
              > file a changed:
              >
              > CONFIG_DRAM_SIZE=0x00010000
              > CONFIG_DRAM_START=0x20000000
              > CONFIG_DRAM_END=(CONFIG_DRAM_START+CONFIG_DRAM_SIZE)
              >
              > Is that sufficient for a working memory configuration?

              Yes, that should be sufficient.

              In your attachment, I see that you are getting a hard fault. So something is very wrong with your configuration.

              > up_hardfault: PANIC!!! Hard fault: 40000000
              > Assertion failed at file:armv7-m/up_hardfault.c line: 142 error code: 32771
              > sp: 2000bfe0
              > stack base: 2000a148
              > stack size: 00001ffc
              > ERROR: Stack pointer is not within allocated stack
              > R0: 00000000 20007c04 20000348 00000000 20000006 08009c6c 0000007b 00000000
              > R8: 20000006 00000000 000000fc 0000000d 00000000 2000c090 080041bf 20000000
              > xPSR: 20000000 PRIMASK: 0000000

              First, the stack pointer does not agree with the stack limits in the task control block (TCB). This means that your system is badly corrupted by the time that the hard fault occurs. Normally, I would analyze the hard fault stack dump to understand what happened, but since the system is so corrupted, there is no stack dump and the register dump may not be meaningful.

              This is possibily caused by a stack overflow or perhaps a bad memory configuration. It is not possible to know the cause without analyzing the failure.

              At the time of the failure, it looks like the system was trying to call to address 0x20000000 (R15) from the return address 0x080041be (R14 without bit 0). I would use objdump -d to find out what is at 0x080041be. But, as I said, since the system is corrupt that address may not be meaningful.

              Greg
            Your message has been successfully submitted and would be delivered to recipients shortly.