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 |
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 |
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 |
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. Best, On Jun 29, 2012 4:09 PM, "pito" <[hidden email]> wrote:
I had 74880 limit as well, where I succesively changed the file size _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
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 |
On Sat, Jun 30, 2012 at 3:31 AM, Bogdan Marinescu <[hidden email]> wrote: Hi Thiago, inc/romfs.h: u16 size in the struct src/romfs.c: all over the place, search for fsize mkfs.py: around line 114
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
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 |
On Sat, Jun 30, 2012 at 5:27 AM, Bogdan Marinescu <[hidden email]> wrote:
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, _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
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 |
> 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 |
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 |
> 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 |
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 |
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 |
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 |
> 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 |
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 |
> 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 |
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 |
> 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 |
Free forum by Nabble | Edit this page |