Hi all,
after porting to v2.0.0 and reducing the cunks to 16kB everything works
fine. Seems like the limited S-RAM and Frequency of the Mikrocontroller
couldn't handle chunks this large.
Thanks for all your help.
Regards,
Norbert
Am 07.08.2016 um 11:57 schrieb Norbert Kleber:
Hi Noam,
if the connection is dropped midway the controller will not leave the
bootloader. The controller boards will be connected to a switch and if
the firmware should be updated a laptop with a c++ program that
manages the transmission of the image. The C++ program will warn the
service technician about the failed update if it is not able to finish
after a cetain number of tries. Therefore it shouldn't be possible to
enter an uncomplete image. Each transmitted part will be checked after
being burned into FLASH via an additional Checksum transmitted over
controlconnection, that also applies for the whole file after
completion. As soon as the controller had Flashed the last part and
evaluated the checksum it sends a command on the controll connection
to signal the completion of the process.
The 64k are not a necassity but were an idea as i said i missread the
amount of RAM memory. I will reduce that amount.
sincerly,
Norbert
Am 07.08.2016 um 09:39 schrieb Noam Weissman:
Hi Norbert,
I am sorry but I did not understood that you are trying to burn the
internal FLASH.
We normally use a small extern SPI FLASH so we first transfer the
binary to the external
FLASH and only after we have the file and that it is OK (CRC OK) we
delete the CPU application
area and burn the new FW.
What you are doing is dangerous. If for some reason connection
dropped or the transferred file
Is corrupted you are left with a device that is not working.
You must think on a 100% safe way to upgrade your device.
Why do you need 64K for BL ? our average serial BL is 16-20K … ST
has an ETH BL example that is smallcheck it as well.
BR,
Noam.
*From:*lwip-users
[mailto:lwip-users-bounces+noam=silrd....@nongnu.org] *On Behalf Of
*Norbert Kleber
*Sent:* Sunday, August 07, 2016 9:00 AM
*To:* lwip-users@nongnu.org
*Subject:* Re: [lwip-users] Connection freeze after 29200 Bytes
Hi everyone,
first of all i'ld like to thank you for your fast responds.
@Noam:
I will try the suggested LwIP 1.41 on Monday.
The FLASH size is 1 MB and the sectors are 0-3 16kB, 4 64kB, 5-11
128kB.
Since my Bootloader application will occupy at least the sectors
0-3 I thought using 64kB.
The S-RAM are 192kB including the 64kB of the CCM. Now that I
think about it i was under the impression of having 512kB RAM
guess i missread something. I will try reducing the chunks of
data I send.
@Jan:
Might very well be. I took the freeing of the pbuf out of an example
as well:
u16_t plen;
plen = ptr->len;
/* continue with next pbuf in chain (if any) */
p = ptr->next;
if (p != NULL)
{
/* increment reference count for es->p */
pbuf_ref(p);
}
/* free pbuf: will free pbufs up to es->p (because es->p has a
reference count > 0) */
pbuf_free(ptr);
sincerly,
Norbert
Am 06.08.2016 um 17:36 schrieb Noam Weissman:
Hi,
STM32F4 is a micro processor and not a processor with huge amount
of RAM !
First of all I suggest using LwIP 1.41 and not the older 1.32
that has bugs.
Secondly do not use such large buffers there is no reasoning for
that. Use the LwIP default
536 bytes or standard TCP size 1460 or similar.
If you define a large window that means you need to set a few
buffer with that size and that's a big
issue. My default MSS size is 536 bytes and I have no problems
sending or receiving large files 600-800K
The reason for using a small MSS size is that I also use a TCP
server (telnet) like and I do not want
to use large buffers in order to send small chunks of data. This
compromise is good for me.
Depending on the FLASH size you use. Normally FLASH uses a page
size of 256 bytes and a sub sector
or sector that has 4K bytes. I do not see why you need to collect
64K bytes before you burn it to FLASH.
At maximum I think you need 4K, but again it depends on the FLASH
itself.
If you can burn pages of 256 bytes what I will do is collect data
into a 256 byte buffer and once I have
256 I will write that page. Take more data from the TCP packet
and if it does not fill the 256 byte buffer
wait for the next TCP packet and add the fragmented data...
Once you get the last packet write what ever is left in the
temporary buffer.
If you use a large FLASH (more then 2M byte) that need to erase a
sub sector of 4K at most I would
define a 4K buffer and do the above.
BR,
Noam.
------------------------------------------------------------------------
*From:*lwip-users <lwip-users-bounces+noam=silrd....@nongnu.org>
<mailto:lwip-users-bounces+noam=silrd....@nongnu.org> on behalf
of Norbert Kleber <nubsi...@arcor.de> <mailto:nubsi...@arcor.de>
*Sent:* Saturday, August 6, 2016 2:03 PM
*To:* lwip-users@nongnu.org <mailto:lwip-users@nongnu.org>
*Subject:* [lwip-users] Connection freeze after 29200 Bytes
Hello everyone,
I ran into a problem while implementing the LwIP stack v1.3.2
onto the STM32F4 Evalboard.
My Intention is to build a bootloader application while using Raw
API. I want to transmit the .bin file in Parts of 64kB (matching
the CCM) to the microcontroller, put it into the CCM and after
that is filled or all data is transmitted to write the data into
the FLASH. As long the file to transfer is smaller than this
magical 29200 Bytes every thing works fine, but if it exceeds
that limit the TCP connection freezes after transmitting the
29200Bytes. Wireshark didn't see any messages following that
freeze not even a keep alive message. If i stop my terminal
program that is sending the data the frame for closing the
connection is send and answered. To control the data transmission
i have a second tcp connection to another port where i am sending
control instructions like how many bytes to expect. The
acknowledgements to these frames had somehow a decreasing window
size.
That happens as follows:
1. frame window is 2920
2. receive frame length 13
3. ack frame window 2907
Is there a mistake in interfacing the lwIP stack? The windowsize
update function is disabled.
I took the driver as well as the interface out of the ethernet
example for STM32F4Evalboar + STM32F4DIS-BB from element 14.
i would be grateful for any hint.
sincerly,
Norbert
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org <mailto:lwip-users@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
