Xmodem transfer - issue

classic Classic list List threaded Threaded
27 messages Options
12
Pito Pito
Reply | Threaded
Open this post in threaded view
|

Xmodem transfer - issue

Hi, this has been discussed in past but let me ask again:
When transfering ie text file (recv /mmc/test.txt), the transfer
stops always at certain point ie: 65664bytes, packet#513. I tried
with BT as well as rs232. I tackled the xmodemtimeout in xmodem.h,
with large values the transfer does not start, but I did not found a
magic value where it works over 60-70kbytes transferred. You may get
other point where it stops. I did it at 115k 8n1, with teraterm,
stm32f4discovery board, bike-nomad distro, codesourcery toolchain.
Is there somebody who is able to transfer larger files
successfully??
p.

--
- - Reklama - - - - - - - - - - - - - -
Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
http://bit.ly/LfImCR

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

On Fri, Jun 29, 2012 at 8:37 PM, pito <[hidden email]> wrote:
> Hi, this has been discussed in past but let me ask again:
> When transfering ie text file (recv /mmc/test.txt), the transfer
> stops always at certain point ie: 65664bytes, packet#513. I tried

The first thing that comes to mind immediately after this is an
overflow on an u16 variable. Please open a bug on our tracker..

Best,
Bogdan

> with BT as well as rs232. I tackled the xmodemtimeout in xmodem.h,
> with large values the transfer does not start, but I did not found a
> magic value where it works over 60-70kbytes transferred. You may get
> other point where it stops. I did it at 115k 8n1, with teraterm,
> stm32f4discovery board, bike-nomad distro, codesourcery toolchain.
> Is there somebody who is able to transfer larger files
> successfully??
> p.
>
> --
> - - Reklama - - - - - - - - - - - - - -
> Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
> studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
> http://bit.ly/LfImCR
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Pito Pito
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

I had 74880 limit as well, where I succesively changed the file size
and ie 74675 was transfered ok. Waht is interesting is when you
rebuild, reset, restart everything you may get another number. I've
tried other files to transfer (ie binaries) but it stops at  the
same point.  So not sure whether volume around ~65536 is the u16
overflow indication

----- PŮVODNÍ ZPRÁVA -----
Od: "Bogdan Marinescu" <[hidden email]>
Komu: "eLua Users and Development List (www.eluaproject.net)"
<[hidden email]>
Předmět: Re: [eLua-dev] Xmodem transfer - issue
Datum: 29.6.2012 - 19:46:12

> On Fri, Jun 29, 2012 at 8:37 PM, pito
> <[hidden email]> wrote:
> > Hi, this has been discussed in past but let me
> > ask again:
> > > When transfering ie text file (recv
> > /mmc/test.txt), the transfer
> > > stops always at certain point ie: 65664bytes,
> > packet#513. I tried
> >
> The first thing that comes to mind immediately
> after this is an
> overflow on an u16 variable. Please open a bug on
> our tracker..
>
> Best,
> Bogdan
>
> > with BT as well as rs232. I tackled the
> > xmodemtimeout in xmodem.h,
> > > with large values the transfer does not start,
> > but I did not found a
> > > magic value where it works over 60-70kbytes
> > transferred. You may get
> > > other point where it stops. I did it at 115k
> > 8n1, with teraterm,
> > > stm32f4discovery board, bike-nomad distro,
> > codesourcery toolchain.
> > > Is there somebody who is able to transfer larger
> > files
> > > successfully??
> > p.
> >
> > --
> > - - Reklama - - - - - - - - - - - - - -
> > Maturity, přijímací zkoušky, státnice,
> > diplomky... Vše o závěru
> > > studia na středních a vysokých školách čtěte na
> > portálu VOLNÝ.cz na
> > > http://bit.ly/LfImCR
> >
> > _______________________________________________
> > eLua-dev mailing list
> > [hidden email]
> > https://lists.berlios.de/mailman/listinfo/elua-dev
> > _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

--
- - Reklama - - - - - - - - - - - - - -
Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
http://bit.ly/LfImCR

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Thiago Naves Thiago Naves
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

We had that same issue @led-lab and after looking at the code I could see it's indeed an int16 overflow. The fix did not seem to be easy. There are various chucks of code doing bit manipulation with that file size. Changing the variable type to int32 does nothing.
We don't have a fix, btw.

Best,
Thiago

On Jun 29, 2012 4:09 PM, "pito" <[hidden email]> wrote:
I had 74880 limit as well, where I succesively changed the file size
and ie 74675 was transfered ok. Waht is interesting is when you
rebuild, reset, restart everything you may get another number. I've
tried other files to transfer (ie binaries) but it stops at  the
same point.  So not sure whether volume around ~65536 is the u16
overflow indication

----- PŮVODNÍ ZPRÁVA -----
Od: "Bogdan Marinescu" <[hidden email]>
Komu: "eLua Users and Development List (www.eluaproject.net)"
<[hidden email]>
Předmět: Re: [eLua-dev] Xmodem transfer - issue
Datum: 29.6.2012 - 19:46:12

> On Fri, Jun 29, 2012 at 8:37 PM, pito
> <[hidden email]> wrote:
> > Hi, this has been discussed in past but let me
> > ask again:
> > > When transfering ie text file (recv
> > /mmc/test.txt), the transfer
> > > stops always at certain point ie: 65664bytes,
> > packet#513. I tried
> >
> The first thing that comes to mind immediately
> after this is an
> overflow on an u16 variable. Please open a bug on
> our tracker..
>
> Best,
> Bogdan
>
> > with BT as well as rs232. I tackled the
> > xmodemtimeout in xmodem.h,
> > > with large values the transfer does not start,
> > but I did not found a
> > > magic value where it works over 60-70kbytes
> > transferred. You may get
> > > other point where it stops. I did it at 115k
> > 8n1, with teraterm,
> > > stm32f4discovery board, bike-nomad distro,
> > codesourcery toolchain.
> > > Is there somebody who is able to transfer larger
> > files
> > > successfully??
> > p.
> >
> > --
> > - - Reklama - - - - - - - - - - - - - -
> > Maturity, přijímací zkoušky, státnice,
> > diplomky... Vše o závěru
> > > studia na středních a vysokých školách čtěte na
> > portálu VOLNÝ.cz na
> > > http://bit.ly/LfImCR
> >
> > _______________________________________________
> > eLua-dev mailing list
> > [hidden email]
> > https://lists.berlios.de/mailman/listinfo/elua-dev
> > _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

--
- - Reklama - - - - - - - - - - - - - -
Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
http://bit.ly/LfImCR

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

Hi Thiago,

On Sat, Jun 30, 2012 at 6:32 AM, Thiago Naves <[hidden email]> wrote:
> We had that same issue @led-lab and after looking at the code I could see
> it's indeed an int16 overflow. The fix did not seem to be easy. There are
> various chucks of code doing bit manipulation with that file size. Changing
> the variable type to int32 does nothing.
> We don't have a fix, btw.

Do you remember where you spotted this problem in the code?

Best,
Bogdan

>
> Best,
> Thiago
>
> On Jun 29, 2012 4:09 PM, "pito" <[hidden email]> wrote:
>>
>> I had 74880 limit as well, where I succesively changed the file size
>> and ie 74675 was transfered ok. Waht is interesting is when you
>> rebuild, reset, restart everything you may get another number. I've
>> tried other files to transfer (ie binaries) but it stops at  the
>> same point.  So not sure whether volume around ~65536 is the u16
>> overflow indication
>>
>> ----- PŮVODNÍ ZPRÁVA -----
>> Od: "Bogdan Marinescu" <[hidden email]>
>> Komu: "eLua Users and Development List (www.eluaproject.net)"
>> <[hidden email]>
>> Předmět: Re: [eLua-dev] Xmodem transfer - issue
>> Datum: 29.6.2012 - 19:46:12
>>
>> > On Fri, Jun 29, 2012 at 8:37 PM, pito
>> > <[hidden email]> wrote:
>> > > Hi, this has been discussed in past but let me
>> > > ask again:
>> > > > When transfering ie text file (recv
>> > > /mmc/test.txt), the transfer
>> > > > stops always at certain point ie: 65664bytes,
>> > > packet#513. I tried
>> > >
>> > The first thing that comes to mind immediately
>> > after this is an
>> > overflow on an u16 variable. Please open a bug on
>> > our tracker..
>> >
>> > Best,
>> > Bogdan
>> >
>> > > with BT as well as rs232. I tackled the
>> > > xmodemtimeout in xmodem.h,
>> > > > with large values the transfer does not start,
>> > > but I did not found a
>> > > > magic value where it works over 60-70kbytes
>> > > transferred. You may get
>> > > > other point where it stops. I did it at 115k
>> > > 8n1, with teraterm,
>> > > > stm32f4discovery board, bike-nomad distro,
>> > > codesourcery toolchain.
>> > > > Is there somebody who is able to transfer larger
>> > > files
>> > > > successfully??
>> > > p.
>> > >
>> > > --
>> > > - - Reklama - - - - - - - - - - - - - -
>> > > Maturity, přijímací zkoušky, státnice,
>> > > diplomky... Vše o závěru
>> > > > studia na středních a vysokých školách čtěte na
>> > > portálu VOLNÝ.cz na
>> > > > http://bit.ly/LfImCR
>> > >
>> > > _______________________________________________
>> > > eLua-dev mailing list
>> > > [hidden email]
>> > > https://lists.berlios.de/mailman/listinfo/elua-dev
>> > > _______________________________________________
>> > eLua-dev mailing list
>> > [hidden email]
>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>> >
>>
>> --
>> - - Reklama - - - - - - - - - - - - - -
>> Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
>> studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
>> http://bit.ly/LfImCR
>>
>> _______________________________________________
>> eLua-dev mailing list
>> [hidden email]
>> https://lists.berlios.de/mailman/listinfo/elua-dev
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Thiago Naves Thiago Naves
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue



On Sat, Jun 30, 2012 at 3:31 AM, Bogdan Marinescu <[hidden email]> wrote:
Hi Thiago,

On Sat, Jun 30, 2012 at 6:32 AM, Thiago Naves <[hidden email]> wrote:
> We had that same issue @led-lab and after looking at the code I could see
> it's indeed an int16 overflow. The fix did not seem to be easy. There are
> various chucks of code doing bit manipulation with that file size. Changing
> the variable type to int32 does nothing.
> We don't have a fix, btw.

Do you remember where you spotted this problem in the code?

inc/romfs.h:
u16 size in the struct

src/romfs.c:
all over the place, search for fsize

mkfs.py:
around line 114
 

Best,
Bogdan

>
> Best,
> Thiago
>
> On Jun 29, 2012 4:09 PM, "pito" <[hidden email]> wrote:
>>
>> I had 74880 limit as well, where I succesively changed the file size
>> and ie 74675 was transfered ok. Waht is interesting is when you
>> rebuild, reset, restart everything you may get another number. I've
>> tried other files to transfer (ie binaries) but it stops at  the
>> same point.  So not sure whether volume around ~65536 is the u16
>> overflow indication
>>
>> ----- PŮVODNÍ ZPRÁVA -----
>> Od: "Bogdan Marinescu" <[hidden email]>
>> Komu: "eLua Users and Development List (www.eluaproject.net)"
>> <[hidden email]>
>> Předmět: Re: [eLua-dev] Xmodem transfer - issue
>> Datum: 29.6.2012 - 19:46:12
>>
>> > On Fri, Jun 29, 2012 at 8:37 PM, pito
>> > <[hidden email]> wrote:
>> > > Hi, this has been discussed in past but let me
>> > > ask again:
>> > > > When transfering ie text file (recv
>> > > /mmc/test.txt), the transfer
>> > > > stops always at certain point ie: 65664bytes,
>> > > packet#513. I tried
>> > >
>> > The first thing that comes to mind immediately
>> > after this is an
>> > overflow on an u16 variable. Please open a bug on
>> > our tracker..
>> >
>> > Best,
>> > Bogdan
>> >
>> > > with BT as well as rs232. I tackled the
>> > > xmodemtimeout in xmodem.h,
>> > > > with large values the transfer does not start,
>> > > but I did not found a
>> > > > magic value where it works over 60-70kbytes
>> > > transferred. You may get
>> > > > other point where it stops. I did it at 115k
>> > > 8n1, with teraterm,
>> > > > stm32f4discovery board, bike-nomad distro,
>> > > codesourcery toolchain.
>> > > > Is there somebody who is able to transfer larger
>> > > files
>> > > > successfully??
>> > > p.
>> > >
>> > > --
>> > > - - Reklama - - - - - - - - - - - - - -
>> > > Maturity, přijímací zkoušky, státnice,
>> > > diplomky... Vše o závěru
>> > > > studia na středních a vysokých školách čtěte na
>> > > portálu VOLNÝ.cz na
>> > > > http://bit.ly/LfImCR
>> > >
>> > > _______________________________________________
>> > > eLua-dev mailing list
>> > > [hidden email]
>> > > https://lists.berlios.de/mailman/listinfo/elua-dev
>> > > _______________________________________________
>> > eLua-dev mailing list
>> > [hidden email]
>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>> >
>>
>> --
>> - - Reklama - - - - - - - - - - - - - -
>> Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
>> studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
>> http://bit.ly/LfImCR
>>
>> _______________________________________________
>> eLua-dev mailing list
>> [hidden email]
>> https://lists.berlios.de/mailman/listinfo/elua-dev


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

On Sat, Jun 30, 2012 at 10:23 AM, Thiago Naves <[hidden email]> wrote:

>
>
> On Sat, Jun 30, 2012 at 3:31 AM, Bogdan Marinescu
> <[hidden email]> wrote:
>>
>> Hi Thiago,
>>
>> On Sat, Jun 30, 2012 at 6:32 AM, Thiago Naves <[hidden email]>
>> wrote:
>> > We had that same issue @led-lab and after looking at the code I could
>> > see
>> > it's indeed an int16 overflow. The fix did not seem to be easy. There
>> > are
>> > various chucks of code doing bit manipulation with that file size.
>> > Changing
>> > the variable type to int32 does nothing.
>> > We don't have a fix, btw.
>>
>> Do you remember where you spotted this problem in the code?
>
>
> inc/romfs.h:
> u16 size in the struct
>
> src/romfs.c:
> all over the place, search for fsize
>
> mkfs.py:
> around line 114

You are talking about the 64k file size limitation in ROMFS (something
that was fixed a while ago, BTW). The original thread is about a
XMODEM transfer limitation. I fail to see the connection.

Best,
Bogdan

>
>>
>>
>> Best,
>> Bogdan
>>
>> >
>> > Best,
>> > Thiago
>> >
>> > On Jun 29, 2012 4:09 PM, "pito" <[hidden email]> wrote:
>> >>
>> >> I had 74880 limit as well, where I succesively changed the file size
>> >> and ie 74675 was transfered ok. Waht is interesting is when you
>> >> rebuild, reset, restart everything you may get another number. I've
>> >> tried other files to transfer (ie binaries) but it stops at  the
>> >> same point.  So not sure whether volume around ~65536 is the u16
>> >> overflow indication
>> >>
>> >> ----- PŮVODNÍ ZPRÁVA -----
>> >> Od: "Bogdan Marinescu" <[hidden email]>
>> >> Komu: "eLua Users and Development List (www.eluaproject.net)"
>> >> <[hidden email]>
>> >> Předmět: Re: [eLua-dev] Xmodem transfer - issue
>> >> Datum: 29.6.2012 - 19:46:12
>> >>
>> >> > On Fri, Jun 29, 2012 at 8:37 PM, pito
>> >> > <[hidden email]> wrote:
>> >> > > Hi, this has been discussed in past but let me
>> >> > > ask again:
>> >> > > > When transfering ie text file (recv
>> >> > > /mmc/test.txt), the transfer
>> >> > > > stops always at certain point ie: 65664bytes,
>> >> > > packet#513. I tried
>> >> > >
>> >> > The first thing that comes to mind immediately
>> >> > after this is an
>> >> > overflow on an u16 variable. Please open a bug on
>> >> > our tracker..
>> >> >
>> >> > Best,
>> >> > Bogdan
>> >> >
>> >> > > with BT as well as rs232. I tackled the
>> >> > > xmodemtimeout in xmodem.h,
>> >> > > > with large values the transfer does not start,
>> >> > > but I did not found a
>> >> > > > magic value where it works over 60-70kbytes
>> >> > > transferred. You may get
>> >> > > > other point where it stops. I did it at 115k
>> >> > > 8n1, with teraterm,
>> >> > > > stm32f4discovery board, bike-nomad distro,
>> >> > > codesourcery toolchain.
>> >> > > > Is there somebody who is able to transfer larger
>> >> > > files
>> >> > > > successfully??
>> >> > > p.
>> >> > >
>> >> > > --
>> >> > > - - Reklama - - - - - - - - - - - - - -
>> >> > > Maturity, přijímací zkoušky, státnice,
>> >> > > diplomky... Vše o závěru
>> >> > > > studia na středních a vysokých školách čtěte na
>> >> > > portálu VOLNÝ.cz na
>> >> > > > http://bit.ly/LfImCR
>> >> > >
>> >> > > _______________________________________________
>> >> > > eLua-dev mailing list
>> >> > > [hidden email]
>> >> > > https://lists.berlios.de/mailman/listinfo/elua-dev
>> >> > > _______________________________________________
>> >> > eLua-dev mailing list
>> >> > [hidden email]
>> >> > https://lists.berlios.de/mailman/listinfo/elua-dev
>> >> >
>> >>
>> >> --
>> >> - - Reklama - - - - - - - - - - - - - -
>> >> Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
>> >> studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
>> >> http://bit.ly/LfImCR
>> >>
>> >> _______________________________________________
>> >> eLua-dev mailing list
>> >> [hidden email]
>> >> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Thiago Naves Thiago Naves
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue



On Sat, Jun 30, 2012 at 5:27 AM, Bogdan Marinescu <[hidden email]> wrote:
On Sat, Jun 30, 2012 at 10:23 AM, Thiago Naves <[hidden email]> wrote:
>
>
> On Sat, Jun 30, 2012 at 3:31 AM, Bogdan Marinescu
> <[hidden email]> wrote:
>>
>> Hi Thiago,
>>
>> On Sat, Jun 30, 2012 at 6:32 AM, Thiago Naves <[hidden email]>
>> wrote:
>> > We had that same issue @led-lab and after looking at the code I could
>> > see
>> > it's indeed an int16 overflow. The fix did not seem to be easy. There
>> > are
>> > various chucks of code doing bit manipulation with that file size.
>> > Changing
>> > the variable type to int32 does nothing.
>> > We don't have a fix, btw.
>>
>> Do you remember where you spotted this problem in the code?
>
>
> inc/romfs.h:
> u16 size in the struct
>
> src/romfs.c:
> all over the place, search for fsize
>
> mkfs.py:
> around line 114

You are talking about the 64k file size limitation in ROMFS (something
that was fixed a while ago, BTW). The original thread is about a
XMODEM transfer limitation. I fail to see the connection.


Sorry for the noise, totally misread it.

But xmodem was working for us with a file of about 67k I think.
That was on the str9 platform with external ram.
I was not the one actually using it, but I can check with the guys at the lab.

Getting different stop points in transfer leads me to think it might be a ram issue...

Best,
Thiago

 
Best,
Bogdan

>
>>
>>
>> Best,
>> Bogdan
>>
>> >
>> > Best,
>> > Thiago
>> >
>> > On Jun 29, 2012 4:09 PM, "pito" <[hidden email]> wrote:
>> >>
>> >> I had 74880 limit as well, where I succesively changed the file size
>> >> and ie 74675 was transfered ok. Waht is interesting is when you
>> >> rebuild, reset, restart everything you may get another number. I've
>> >> tried other files to transfer (ie binaries) but it stops at  the
>> >> same point.  So not sure whether volume around ~65536 is the u16
>> >> overflow indication
>> >>
>> >> ----- PŮVODNÍ ZPRÁVA -----
>> >> Od: "Bogdan Marinescu" <[hidden email]>
>> >> Komu: "eLua Users and Development List (www.eluaproject.net)"
>> >> <[hidden email]>
>> >> Předmět: Re: [eLua-dev] Xmodem transfer - issue
>> >> Datum: 29.6.2012 - 19:46:12
>> >>
>> >> > On Fri, Jun 29, 2012 at 8:37 PM, pito
>> >> > <[hidden email]> wrote:
>> >> > > Hi, this has been discussed in past but let me
>> >> > > ask again:
>> >> > > > When transfering ie text file (recv
>> >> > > /mmc/test.txt), the transfer
>> >> > > > stops always at certain point ie: 65664bytes,
>> >> > > packet#513. I tried
>> >> > >
>> >> > The first thing that comes to mind immediately
>> >> > after this is an
>> >> > overflow on an u16 variable. Please open a bug on
>> >> > our tracker..
>> >> >
>> >> > Best,
>> >> > Bogdan
>> >> >
>> >> > > with BT as well as rs232. I tackled the
>> >> > > xmodemtimeout in xmodem.h,
>> >> > > > with large values the transfer does not start,
>> >> > > but I did not found a
>> >> > > > magic value where it works over 60-70kbytes
>> >> > > transferred. You may get
>> >> > > > other point where it stops. I did it at 115k
>> >> > > 8n1, with teraterm,
>> >> > > > stm32f4discovery board, bike-nomad distro,
>> >> > > codesourcery toolchain.
>> >> > > > Is there somebody who is able to transfer larger
>> >> > > files
>> >> > > > successfully??
>> >> > > p.
>> >> > >
>> >> > > --
>> >> > > - - Reklama - - - - - - - - - - - - - -
>> >> > > Maturity, přijímací zkoušky, státnice,
>> >> > > diplomky... Vše o závěru
>> >> > > > studia na středních a vysokých školách čtěte na
>> >> > > portálu VOLNÝ.cz na
>> >> > > > http://bit.ly/LfImCR
>> >> > >
>> >> > > _______________________________________________
>> >> > > eLua-dev mailing list
>> >> > > [hidden email]
>> >> > > https://lists.berlios.de/mailman/listinfo/elua-dev
>> >> > > _______________________________________________
>> >> > eLua-dev mailing list
>> >> > [hidden email]
>> >> > https://lists.berlios.de/mailman/listinfo/elua-dev
>> >> >
>> >>
>> >> --
>> >> - - Reklama - - - - - - - - - - - - - -
>> >> Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
>> >> studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
>> >> http://bit.ly/LfImCR
>> >>
>> >> _______________________________________________
>> >> eLua-dev mailing list
>> >> [hidden email]
>> >> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>


_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

On Sat, Jun 30, 2012 at 12:06 PM, Thiago Naves <[hidden email]> wrote:

>
>
> On Sat, Jun 30, 2012 at 5:27 AM, Bogdan Marinescu
> <[hidden email]> wrote:
>>
>> On Sat, Jun 30, 2012 at 10:23 AM, Thiago Naves <[hidden email]>
>> wrote:
>> >
>> >
>> > On Sat, Jun 30, 2012 at 3:31 AM, Bogdan Marinescu
>> > <[hidden email]> wrote:
>> >>
>> >> Hi Thiago,
>> >>
>> >> On Sat, Jun 30, 2012 at 6:32 AM, Thiago Naves <[hidden email]>
>> >> wrote:
>> >> > We had that same issue @led-lab and after looking at the code I could
>> >> > see
>> >> > it's indeed an int16 overflow. The fix did not seem to be easy. There
>> >> > are
>> >> > various chucks of code doing bit manipulation with that file size.
>> >> > Changing
>> >> > the variable type to int32 does nothing.
>> >> > We don't have a fix, btw.
>> >>
>> >> Do you remember where you spotted this problem in the code?
>> >
>> >
>> > inc/romfs.h:
>> > u16 size in the struct
>> >
>> > src/romfs.c:
>> > all over the place, search for fsize
>> >
>> > mkfs.py:
>> > around line 114
>>
>> You are talking about the 64k file size limitation in ROMFS (something
>> that was fixed a while ago, BTW). The original thread is about a
>> XMODEM transfer limitation. I fail to see the connection.
>>
>
> Sorry for the noise, totally misread it.

No problem. I actually thought I was missing something :)

>
> But xmodem was working for us with a file of about 67k I think.
> That was on the str9 platform with external ram.
> I was not the one actually using it, but I can check with the guys at the
> lab.
>
> Getting different stop points in transfer leads me to think it might be a
> ram issue...

I tend to believe that too ... Currently, XMODEM reads everything in a
buffer and saves the buffer on disk at the end.
Pito, does your board have more than 64k of free memory when you do 'recv' ?

Thanks,
Bogdan

>
> Best,
> Thiago
>
>
>>
>> Best,
>> Bogdan
>>
>> >
>> >>
>> >>
>> >> Best,
>> >> Bogdan
>> >>
>> >> >
>> >> > Best,
>> >> > Thiago
>> >> >
>> >> > On Jun 29, 2012 4:09 PM, "pito" <[hidden email]> wrote:
>> >> >>
>> >> >> I had 74880 limit as well, where I succesively changed the file size
>> >> >> and ie 74675 was transfered ok. Waht is interesting is when you
>> >> >> rebuild, reset, restart everything you may get another number. I've
>> >> >> tried other files to transfer (ie binaries) but it stops at  the
>> >> >> same point.  So not sure whether volume around ~65536 is the u16
>> >> >> overflow indication
>> >> >>
>> >> >> ----- PŮVODNÍ ZPRÁVA -----
>> >> >> Od: "Bogdan Marinescu" <[hidden email]>
>> >> >> Komu: "eLua Users and Development List (www.eluaproject.net)"
>> >> >> <[hidden email]>
>> >> >> Předmět: Re: [eLua-dev] Xmodem transfer - issue
>> >> >> Datum: 29.6.2012 - 19:46:12
>> >> >>
>> >> >> > On Fri, Jun 29, 2012 at 8:37 PM, pito
>> >> >> > <[hidden email]> wrote:
>> >> >> > > Hi, this has been discussed in past but let me
>> >> >> > > ask again:
>> >> >> > > > When transfering ie text file (recv
>> >> >> > > /mmc/test.txt), the transfer
>> >> >> > > > stops always at certain point ie: 65664bytes,
>> >> >> > > packet#513. I tried
>> >> >> > >
>> >> >> > The first thing that comes to mind immediately
>> >> >> > after this is an
>> >> >> > overflow on an u16 variable. Please open a bug on
>> >> >> > our tracker..
>> >> >> >
>> >> >> > Best,
>> >> >> > Bogdan
>> >> >> >
>> >> >> > > with BT as well as rs232. I tackled the
>> >> >> > > xmodemtimeout in xmodem.h,
>> >> >> > > > with large values the transfer does not start,
>> >> >> > > but I did not found a
>> >> >> > > > magic value where it works over 60-70kbytes
>> >> >> > > transferred. You may get
>> >> >> > > > other point where it stops. I did it at 115k
>> >> >> > > 8n1, with teraterm,
>> >> >> > > > stm32f4discovery board, bike-nomad distro,
>> >> >> > > codesourcery toolchain.
>> >> >> > > > Is there somebody who is able to transfer larger
>> >> >> > > files
>> >> >> > > > successfully??
>> >> >> > > p.
>> >> >> > >
>> >> >> > > --
>> >> >> > > - - Reklama - - - - - - - - - - - - - -
>> >> >> > > Maturity, přijímací zkoušky, státnice,
>> >> >> > > diplomky... Vše o závěru
>> >> >> > > > studia na středních a vysokých školách čtěte na
>> >> >> > > portálu VOLNÝ.cz na
>> >> >> > > > http://bit.ly/LfImCR
>> >> >> > >
>> >> >> > > _______________________________________________
>> >> >> > > eLua-dev mailing list
>> >> >> > > [hidden email]
>> >> >> > > https://lists.berlios.de/mailman/listinfo/elua-dev
>> >> >> > > _______________________________________________
>> >> >> > eLua-dev mailing list
>> >> >> > [hidden email]
>> >> >> > https://lists.berlios.de/mailman/listinfo/elua-dev
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> - - Reklama - - - - - - - - - - - - - -
>> >> >> Maturity, přijímací zkoušky, státnice, diplomky... Vše o závěru
>> >> >> studia na středních a vysokých školách čtěte na portálu VOLNÝ.cz na
>> >> >> http://bit.ly/LfImCR
>> >> >>
>> >> >> _______________________________________________
>> >> >> eLua-dev mailing list
>> >> >> [hidden email]
>> >> >> https://lists.berlios.de/mailman/listinfo/elua-dev
>> >
>> >
>
>
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Pito Pito
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

> I tend to believe that too ... Currently, XMODEM
> reads everything in a
> buffer and saves the buffer on disk at the end.
> Pito, does your board have more than 64k of free
> memory when you do 'recv' ?
My stm32f4disco board has 192kB internal sram available for eLua
(two segments in allocator - 128kB and 64kB) so hopefully it has got
64kB free. I do not know how the Xmodem implementation works, but
the information it receives data in a buffer and when done it stores
it somewhere is of course shocking to me :). That could be reason
for the ~60-70kB limit.
I am doing the recv immediately after the reset, maybe there garbage
collector does not work correctly at that stage. When running ie.
life(65,50) the GC shows ~150kB, so the memory is there and
allocated for eLua.
P.

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

On Sat, Jun 30, 2012 at 1:55 PM, pito <[hidden email]> wrote:

>> I tend to believe that too ... Currently, XMODEM
>> reads everything in a
>> buffer and saves the buffer on disk at the end.
>> Pito, does your board have more than 64k of free
>> memory when you do 'recv' ?
> My stm32f4disco board has 192kB internal sram available for eLua
> (two segments in allocator - 128kB and 64kB) so hopefully it has got
> 64kB free. I do not know how the Xmodem implementation works, but
> the information it receives data in a buffer and when done it stores
> it somewhere is of course shocking to me :).

Initially, 'recv' was not designed to store anything. It would just
get some data via XMODEM and call the Lua interpreter to execute this
data. In this mode, all the data must be in a contiguous area of
memory, otherwise Lua wouldn't be able to execute it. When the option
to save the data received via XMODEM was added, the only modification
was made to the shell code (to actually write the data to a file), but
the data is still read as a single big chunk. Of course, we can modify
this so that XMODEM saves every block that it receives (or every N
blocks) in "save to file" mode.

> That could be reason
> for the ~60-70kB limit.

It definitely could. It's still strange though, you should have
received an "out of memory" error. How exactly does the transfer stop?
Does it give an error or simply hang?

> I am doing the recv immediately after the reset, maybe there garbage
> collector does not work correctly at that stage.

Nope, it should work exactly the same at every stage.

Best,
Bogdan

> When running ie.
> life(65,50) the GC shows ~150kB, so the memory is there and
> allocated for eLua.
> P.
>
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Pito Pito
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

> course, we can modify
> this so that XMODEM saves every block that it
> receives (or every N
> blocks) in "save to file" mode.
that would be great - ie 4kb chunks, each written to ie mmc, sdcard
latency is typically max 300ms, so xmodem may wait a little bit..

> you should have
> received an "out of memory" error. How exactly
> does the transfer stop?
> Does it give an error or simply hang?
enclosed pls find the picture, yes it simply hangs as depicted (the
file to be transfered is about 73kB). p.

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

xmodemissue.jpg (32K) Download Attachment
Pito Pito
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

btw, you are allocating the xmodem buffer with malloc() in C, so pls
consider the eLua's 192kB = 128kB+64kB from C prospective..

----- PŮVODNÍ ZPRÁVA -----
Od: "pito" <[hidden email]>
Komu: [hidden email], [hidden email],
[hidden email], [hidden email]
Předmět: Re: [eLua-dev] Xmodem transfer - issue
Datum: 30.6.2012 - 14:17:12

> > course, we can modify
> > this so that XMODEM saves every block that it
> > receives (or every N
> > blocks) in "save to file" mode.
> that would be great - ie 4kb chunks, each written
> to ie mmc, sdcard
> latency is typically max 300ms, so xmodem may wait
> a little bit..
>
> > you should have
> > received an "out of memory" error. How exactly
> > does the transfer stop?
> > Does it give an error or simply hang?
> enclosed pls find the picture, yes it simply hangs
> as depicted (the
> file to be transfered is about 73kB). p.
>

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Pito Pito
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

In reply to this post by Pito
With the previous picture it stopped at 65536+128 = 513 packets.
So I changed the limit check (in xmodem.c) to a 64000 limit
(500packets):
...
if(( ( p = realloc( *dest, limit ) ) == NULL ) || ( limit > 64000 ))
{
// Not enough memory, force cancel and return
xmodem_flush( XMODEM_FLUSH_AND_XM_CAN );
return XMODEM_ERROR_OUTOFMEM;
}
...
and it stopped there and it hangs as well (see enclosed picture). So
my current understanding is:
a) in the first case the realloc had only 65536 bytes (probably in
the 64k CCM block)
b) in this case "outofmem" return does not work properly..
p.

----- PŮVODNÍ ZPRÁVA -----
Od: "pito" <[hidden email]>
Komu: [hidden email], [hidden email],
[hidden email], [hidden email]
Předmět: Re: [eLua-dev] Xmodem transfer - issue
Datum: 30.6.2012 - 14:17:12

> > course, we can modify
> > this so that XMODEM saves every block that it
> > receives (or every N
> > blocks) in "save to file" mode.
> that would be great - ie 4kb chunks, each written
> to ie mmc, sdcard
> latency is typically max 300ms, so xmodem may wait
> a little bit..
>
> > you should have
> > received an "out of memory" error. How exactly
> > does the transfer stop?
> > Does it give an error or simply hang?
> enclosed pls find the picture, yes it simply hangs
> as depicted (the
> file to be transfered is about 73kB). p.
>

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

xmodemissue1.jpg (41K) Download Attachment
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

On Sat, Jun 30, 2012 at 5:24 PM, pito <[hidden email]> wrote:

> With the previous picture it stopped at 65536+128 = 513 packets.
> So I changed the limit check (in xmodem.c) to a 64000 limit
> (500packets):
> ...
> if(( ( p = realloc( *dest, limit ) ) == NULL ) || ( limit > 64000 ))
> {
> // Not enough memory, force cancel and return
> xmodem_flush( XMODEM_FLUSH_AND_XM_CAN );
> return XMODEM_ERROR_OUTOFMEM;
> }
> ...
> and it stopped there and it hangs as well (see enclosed picture). So
> my current understanding is:
> a) in the first case the realloc had only 65536 bytes (probably in
> the 64k CCM block)
> b) in this case "outofmem" return does not work properly..
> p.

Can you please open your platform_conf.h files and list the
definitions for MEM_START_ADDRESS and MEM_END_ADDRESS from that file?

Thanks,
Bogdan

>
> ----- PŮVODNÍ ZPRÁVA -----
> Od: "pito" <[hidden email]>
> Komu: [hidden email], [hidden email],
> [hidden email], [hidden email]
> Předmět: Re: [eLua-dev] Xmodem transfer - issue
> Datum: 30.6.2012 - 14:17:12
>
>> > course, we can modify
>> > this so that XMODEM saves every block that it
>> > receives (or every N
>> > blocks) in "save to file" mode.
>> that would be great - ie 4kb chunks, each written
>> to ie mmc, sdcard
>> latency is typically max 300ms, so xmodem may wait
>> a little bit..
>>
>> > you should have
>> > received an "out of memory" error. How exactly
>> > does the transfer stop?
>> > Does it give an error or simply hang?
>> enclosed pls find the picture, yes it simply hangs
>> as depicted (the
>> file to be transfered is about 73kB). p.
>>
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Pito Pito
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

> Can you please open your platform_conf.h files and
> list the
> definitions for MEM_START_ADDRESS and
> MEM_END_ADDRESS from that file?

// Allocator data: define your free memory zones here in two arrays
// (start address and end address)
// The F4 has 196K in total, but it is split into 3 sections:
// SRAM (xrw) : ORIGIN = 0x20000000, SIZE = 128K      // Major SRAM
// CCMDATARAM (xrw) : ORIGIN = 0x10000000, SIZE = 64K    // Core
Coupled Data SRAM
// BKPSRAM, SIZE = 4K // Backup SRAM
//
#define CCMDATARAM_SIZE         ( 64 * 1024 )
#define SRAM_SIZE               ( 128 * 1024 )
#define MEM_START_ADDRESS       { ( void* )end, (void* )(
CCMDATARAM_BASE ) }
#define MEM_END_ADDRESS         { ( void* )( SRAM_BASE + SRAM_SIZE -
STACK_SIZE_TOTAL - 1 ), (void*)( CCMDATARAM_BASE + CCMDATARAM_SIZE -
1 ) }

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

On Sat, Jun 30, 2012 at 5:42 PM, pito <[hidden email]> wrote:

>> Can you please open your platform_conf.h files and
>> list the
>> definitions for MEM_START_ADDRESS and
>> MEM_END_ADDRESS from that file?
>
> // Allocator data: define your free memory zones here in two arrays
> // (start address and end address)
> // The F4 has 196K in total, but it is split into 3 sections:
> // SRAM (xrw) : ORIGIN = 0x20000000, SIZE = 128K      // Major SRAM
> // CCMDATARAM (xrw) : ORIGIN = 0x10000000, SIZE = 64K    // Core
> Coupled Data SRAM
> // BKPSRAM, SIZE = 4K // Backup SRAM
> //
> #define CCMDATARAM_SIZE         ( 64 * 1024 )
> #define SRAM_SIZE               ( 128 * 1024 )
> #define MEM_START_ADDRESS       { ( void* )end, (void* )(
> CCMDATARAM_BASE ) }
> #define MEM_END_ADDRESS         { ( void* )( SRAM_BASE + SRAM_SIZE -
> STACK_SIZE_TOTAL - 1 ), (void*)( CCMDATARAM_BASE + CCMDATARAM_SIZE -
> 1 ) }

That looks right. Does eLua end up being compiled with the 'multiple' allocator?

Best,
Bogdan

>
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Pito Pito
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

> That looks right. Does eLua end up being compiled
> with the 'multiple' allocator?

C:\ARM\eLua\elua_bike>scons board=STM32F4DSCY
scons: Reading SConscript files ...

*********************************
Compiling eLua ...
CPU:             STM32F407VG
Board:           STM32F4DSCY
Platform:        stm32f4
Allocator:       multiple
Boot Mode:       standard
Target:          lua
Toolchain:       codesourcery
ROMFS mode:      verbatim
*********************************

Building ROM File System...
Encoded file hanoi.lua (7963 bytes)
Encoded file lifebig.lua (3432 bytes)
Done, total size is 11422 bytes

scons: done reading SConscript files.
scons: Building targets ...
arm-none-eabi-gcc -o src\xmodem.o -c -mcpu=cortex-m4......

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

That also looks right. The problem is somewhere else, but I don't know
where. More debugging is needed ...

Best,
Bogdan

On Sat, Jun 30, 2012 at 5:54 PM, pito <[hidden email]> wrote:

>> That looks right. Does eLua end up being compiled
>> with the 'multiple' allocator?
>
> C:\ARM\eLua\elua_bike>scons board=STM32F4DSCY
> scons: Reading SConscript files ...
>
> *********************************
> Compiling eLua ...
> CPU:             STM32F407VG
> Board:           STM32F4DSCY
> Platform:        stm32f4
> Allocator:       multiple
> Boot Mode:       standard
> Target:          lua
> Toolchain:       codesourcery
> ROMFS mode:      verbatim
> *********************************
>
> Building ROM File System...
> Encoded file hanoi.lua (7963 bytes)
> Encoded file lifebig.lua (3432 bytes)
> Done, total size is 11422 bytes
>
> scons: done reading SConscript files.
> scons: Building targets ...
> arm-none-eabi-gcc -o src\xmodem.o -c -mcpu=cortex-m4......
>
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
Pito Pito
Reply | Threaded
Open this post in threaded view
|

Re: Xmodem transfer - issue

> That also looks right. The problem is somewhere
> else, but I don't know
> where. More debugging is needed ...

enclosed find the picture from life(65,50) where you may see the
memory used..

1. does the realloc() know where to allocate?? (in SRAM or in CCM ?)
- first issue
2. it hangs when returning via that outofmem return... - second
issue
3. when the transfered file size is small (ie 40k) it works fine
(because there is none issue N.1 and none issue N.2)..
p.

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

lifebig.jpg (29K) Download Attachment
12