Re: [lwip-users] LPC1768 lpc_low_level_input: Packet dropped witherrors (0xffffffff)

[Jan Menzel]

Hi all!
        It seems that I've found the problem now. For anyone facing the same
issue: I have changed the linker script and positioned the buffer
descriptors and the receive buffers into the same RAM block. Before this
the linker had placed the buffer descriptors in SRAM (0x1000xxxx) and
the buffers in AHB-SRAM (0x2007xxxx).
        Any clue why that matters?

        Jan

On 27.11.2014 11:25, Jan Menzel wrote:
> Dear Darius!
>       Many thanks for your response. This is what I'm doing in some more 
> details:
> - I retargeted all debug output to a UART (available standalone)
> - a terminal is watching the debug output
> - Wireshark is recording network activity
> - I flash the code into the MCU via SWD using the IDE
> - The code executes with the IDE connected in debugging mode (I can stop
> the MCU, watch registers/memory, see where the PC is, ...)
> - debug output and Wireshark show me DHCP discovery, offers, request and
> acknowledgements, my own ARP responses, DNS traffic, TCP connection
> establishment with the server I'm connecting to.
> - I power-cycle the board (JTag/SWD debugger is still connected)
> - debug output shows normal boot procedure
> - Wireshark records DHCP traffic incl. my acknowledge, then it records a
> DNS request with response and a start of a TCP connection.
>       The first DNS-Offer is lost as well as the [SYN,ACK] from the server.
> Afterwords almost all received packets get lost. The terminal records
> lost of "lpc_low_level_input: Packet dropped with errors (0xffffffff)"
> messages and Wireshark shows lots of missing ARP responses and TCP
> retransmission.
>       The code is intended to run on custom hardware. I've just ported it
> back to a MCB1700 eval-board with comparable results: the first DHCP
> offer is lost and many other messages too. In between I've seen some
> regular traffic, but then again lots of unusual retransmission which
> would be consistent with missing input packets. (I don't have access to
> the serial debugging output on the eval-board)
>       I wonder, why this problem only appears if I power cycle the hardware
> and not as long as the IDE is controlling the MCU. To my understanding
> the IDE is doing nothing with the MCU. I don't use SWO, break-points,
> watch-points or vector catch, I've disabled all periodic update
> features, there shall be nothing the IDE is asking the MCU using
> JTag/SWO that could alter timings...
> 
>       Jan
> 
> On 27.11.2014 07:10, Darius Babrauskas wrote:
>>> I'm facing the unpleasant problem that most input packets are dropped
>>> by the LPC1768 low level input if my code is run without IDE connected.
>> What you mean "run without IDE connected"? Without JTAG connected ? Are
>> you using demo board, or your self made board?
>> If you using self made board, maybe forget insert some pullup resistors?
>>
>>
>>
>>> Hi All!
>>> I'm facing the unpleasant problem that most input packets are dropped
>>> by the LPC1768 low level input if my code is run without IDE connected.
>>> The same code started using the IDE works well and I don't see this kind
>>> of errors. The error message is "lpc_low_level_input: Packet dropped
>>> with errors (0xffffffff)" and generated in lpc17xx_40xx_emac.c around
>>> like 256. It seems that the error code is the same as the init value. (I
>>> also shifted the error message printing up a few lines to avoid
>>> resetting the value before printing, with same results.)
>>> My code is based on the LPCexpresso example with LwIP 1.4.1 and
>>> FreeRTOS (7.x). I upgraded the RTOS to 8.1.2 and stick with
>>> enet_17xx_40xx.c and lpc17xx_40xx_emac.c from the original example. The
>>> code uses four threads, lowlevel rx and tx-cleanup, tcpip and one for
>>> start and control. This fouth thread calls tcpip_init(), netif_add() and
>>> polls the link state. On link detection it calls netif_set_link_up() and
>>> dhcp_add(), both via tcpip_callback_with_block() (the original code
>>> called dhcp_add() directly, but I had the problem that dhcp offers are
>>> not handled if called directly). Once an IP address is assigned, I'm
>>> using netcon to connect to a server.
>>> Can anyone explain whats going wrong or point me to where to continue
>>> searching? Thank You!
>>>
>>> Jan
>>>
>>> _______________________________________________
>>> lwip-users mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/lwip-users 
>>
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>