topic Re: LPC1788 Ethernet Bootloader via Flash Magic in LPCXpresso IDE

LPC1788 Ethernet Bootloader via Flash Magic

lpcware — Wed, 15 Jun 2016 23:21:15 GMT

Content originally posted in LPCWare by irvind on Thu Nov 08 22:26:50 MST 2012
Hi all,

I am working on LPC1788 ethernet bootloader, firmware flashed with flash magic application.

So far everthing working fine like erase flash, blank check, read ID and security etc.

But when I start to program blinky.hex. I feel that flash magic was sending data packet faster than my board can receive it(checked with wireshark FM sending 12-14 data packet without delay).

Most of the time my board receive 4 packets and I check these EMAC index(LPC_EMAC->RxConsumeIndex,LPC_EMAC->RxProduceIndex) shown that no more data in the network.

Is there anyone who facing this problem or some suggestion how to overcome this?

Thanks.

Re: LPC1788 Ethernet Bootloader via Flash Magic

lpcware — Wed, 15 Jun 2016 23:21:16 GMT

Content originally posted in LPCWare by irvind on Sun Nov 11 22:56:39 MST 2012
can anyone give some advice on this problem?

Re: LPC1788 Ethernet Bootloader via Flash Magic

lpcware — Wed, 15 Jun 2016 23:21:17 GMT

Content originally posted in LPCWare by ex-kayoda on Mon Nov 12 06:09:02 MST 2012
You're not giving us a lot of information about software (code?) and hardware (Board? PHY?) ;)

Re: LPC1788 Ethernet Bootloader via Flash Magic

lpcware — Wed, 15 Jun 2016 23:21:17 GMT

Content originally posted in LPCWare by research on Wed May 22 02:52:38 MST 2013
Hi,

we are also working in LPC1788 Ethernet Bootloader. can you share sample code for Ethernet bootloader with us..

Thanks & Regards
Research

Re: LPC1788 Ethernet Bootloader via Flash Magic

lpcware — Wed, 15 Jun 2016 23:21:18 GMT

Content originally posted in LPCWare by research on Wed May 22 03:51:54 MST 2013
Hi,

Can you share with emac.c for LPC1788 Ethernet Boot loader

Regards
Research

Re: LPC1788 Ethernet Bootloader via Flash Magic

lpcware — Wed, 15 Jun 2016 23:21:18 GMT

Content originally posted in LPCWare by nil on Thu Jan 29 09:05:40 MST 2015
Hi,

I am also working on the same thing can you share any sample code of boot loader.

Re: LPC1788 Ethernet Bootloader via Flash Magic

lpcware — Wed, 15 Jun 2016 23:21:19 GMT

Content originally posted in LPCWare by MikeSimmonds on Sat Jan 31 20:33:03 MST 2015
This looks like it may be a problem with the implementation of the TCP stack -- you didn't say if it was roll your own,
(LPCOpen) LWIP or what.

When TCP has received enough to momentarily fill it's buffers (i.e doesn't want any more for a bit) a field in the TCP
packet header for the ACK (or ACKS) called 'window' is decreased to indicate how much more data (i.e input packets)
can be handled. This is even allowd to reduce to zero. When the application has emptied (i.e retrieved) enough data to
free up some the TCP stack's buffer space, this window field will be increased. [This is a simplification].

Also, if packets arrive that cannot be handled, the ACK number doesn't acknowledge anything out side the so called
receive window. But then the other end will re-send them assuming that they were lost.

This suggests that the TCP stack on the 1778 is not fully complient, or that Flash Magic is ignoring the window
advertisement (or at least Window's error response from a 'send' call).

See "RFC 793" (Google, freely available, for the 'Standard' description of TCP) or (again Google) any TCP info
website. This is obviously somewhat technical, and may be more than you wanted to know.

Your Wireshark logs will show if this (guess) is true or not when you inspect the packet headers (from the 1778).

I hope that this will point you in the right direction.

Regards, Mike

Re: LPC1788 Ethernet Bootloader via Flash Magic

lpcware — Wed, 15 Jun 2016 23:21:20 GMT

Content originally posted in LPCWare by MikeSimmonds on Sat Jan 31 20:53:37 MST 2015
Also, specifically for the 1778 EMAC, if there are no buffers (as indicated by RxProduce/RxComsume) then any
input packets will be simply discarded and will not make it to the TCP stack.

As you probably know, after a packet has been copied to the TCP stack, the RxConsume index has to be advanced
to free up another DMA buffer for the EMAC controller.

As mentioned previously, Flash Magic should not even attempt to send more packets than fit in the latest ack packet's
window size (starting with the ack for the syn packet that opened the connection). So running out of (receiving too many)
DMA buffers should not be an issue.

But perhaps you input packet handler takes to long to process them before 'releasing' the DMA buffers. Maybe the TCP
stack code need to copy and then release the (DMA) buffers earlier in the processing.

Edit: Your code should receive the entire download before erasing/writing to flash. It should definitely NOT be burning
each section as it comes in.

Again, just guesses, Mike.