STM32 Port of eLua
Locked
12
12
 
|
Brent Picasso |
Re: Enabling Lua Tiny Ram in custom Lua port
|
Thanks, James.
What I'm noticing with the patch is when optimization is enabled, the functions normally exposed in the libraries like mathlib, etc are not being found at runtime. Something is amiss here; I'm digging some more. I'm noticing the eLua runtime has a different approach for finding the rotables; a linker script defines the areas in memory where the rotables can be found. Question: could the lua folder of the eLua source be more-or-less dropped in to the src branch of the standard lua source and built like the original lua code, compiled to a static library? Brent On 04/02/2012 06:43 PM, James Snyder wrote: > On Mon, Apr 2, 2012 at 12:29 PM, Brent Picasso<[hidden email]> wrote: >> Hi Martin, >> >> Did a bit more digging- looks like the patch you provided didn't contain all >> of the optimizations described on the elua LTR page. >> >> Specifically, there were quite a few differences in lrotable.c when >> comparing the patched file to what's currently in the elua project; >> >> for example, the references to enable explicit unions is missing: >> >> /* Return 1 if the given pointer is a rotable */ >> #ifdef LUA_META_ROTABLES >> extern char stext[]; >> extern char etext[]; >> int luaR_isrotable(void *p) { >> return stext<= ( char* )p&& ( char* )p<= etext; >> } >> #endif >> >> The patch you provided for lua 5.1.4 - was it just an earlier version, or >> was it specifically limited for some reason? > The patch that was posted on the mailing list differs from what's now > in our main repository. I'm not sure if there's a convenient > broken-out version of of what's currently applied. Bogdan might be > able to answer that one. > > If someone does manage to collect this, I'd be appreciative if it gets > posted to the list as I wouldn't mind putting it on a branch on my Lua > mirror repository: > https://github.com/jsnyder/lua > >> Thanks for your help! >> >> >> Brent Picasso >> Autosport Labs >> Technology for Race and Street >> autosportlabs.com | twitter.com/AutosportLabs >> >> On 03/30/2012 03:33 PM, Brent Picasso wrote: >> >> Hi Martin, >> >> I made some progress on enabling LTR in my port. >> >> I got the patch applied and then attempted to register a test function using >> the instructions here: >> http://www.eluaproject.net/doc/v0.8/en_arch_ltr.html >> >> specifically, this code: >> >> const luaR_entry mod_map[] = // note: no static this time >> { >> { LRO_STRKEY( "f" ), LRO_FUNCVAL( f_implementation ) }, >> { LRO_NILKEY, LRO_NILVAL } >> }; >> >> // note: in this case the "luaopen_mod" function isn't really needed anymore >> LUALIB_API int luaopen_mod( lua_State *L ) >> { >> return 0; >> } >> >> declaring my function this way didn't seem to register it correctly with >> lua; I felt something was missing. So I dug into the implementation of >> luaI_openlib(). >> >> Inspecting this function I then came up with a way to manually register >> functions in a 'light' way using the following macro: >> >> #define lua_registerlight(L,n,f) (lua_pushlightfunction(L, (f)), >> lua_setglobal(L, (n))) >> >> I have about 125 functions registered using the standard lua_register() ; >> switching to lua_registerlight() netted me a memory usage savings before >> LTR of >> >> 23K to 13K usage as reported by print(collectgarbage("count")). About 10K >> savings. >> >> However, I'm not sure if I'm really using the full capability of the LTR >> patch. >> >> Is the above approach still using RAM for each function registration? Is >> there a better way to register my C functions with no memory usage? >> >> Thank you, >> >> Brent Picasso >> Autosport Labs >> Technology for Race and Street >> autosportlabs.com | twitter.com/AutosportLabs >> >> On 03/30/2012 06:37 AM, Martin Guy wrote: >> >> hi >> The Lua tiny ram patch as applicable to plain lua-5.1.4 is attached >> >> M >> >> >> >> _______________________________________________ >> 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 > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
On Tue, Apr 3, 2012 at 8:03 AM, Brent Picasso <[hidden email]> wrote: > Thanks, James. > > What I'm noticing with the patch is when optimization is enabled, the > functions normally exposed in the libraries like mathlib, etc are not being > found at runtime. Something is amiss here; I'm digging some more. The version that Martin sent you is an old, outdated one. Unfortunately, I wasn't smart enough to update the patch as I updated the eLua source tree. I know I should do that. > > I'm noticing the eLua runtime has a different approach for finding the > rotables; a linker script defines the areas in memory where the rotables can > be found. Yes. This approach will be removed somewhere in the near future, but until then you need to define two symbols (stext and etext) in your linker command file (at the beginning and at the end of the .text region (which must also include your program constants) respectively). > > Question: could the lua folder of the eLua source be more-or-less dropped in > to the src branch of the standard lua source and built like the original lua > code, compiled to a static library? I would be surprised if this worked, but if you're brave enough give it a try and let us know how it works :) Best, Bogdan > > Brent > > > > On 04/02/2012 06:43 PM, James Snyder wrote: >> >> On Mon, Apr 2, 2012 at 12:29 PM, Brent Picasso<[hidden email]> >> wrote: >>> >>> Hi Martin, >>> >>> Did a bit more digging- looks like the patch you provided didn't contain >>> all >>> of the optimizations described on the elua LTR page. >>> >>> Specifically, there were quite a few differences in lrotable.c when >>> comparing the patched file to what's currently in the elua project; >>> >>> for example, the references to enable explicit unions is missing: >>> >>> /* Return 1 if the given pointer is a rotable */ >>> #ifdef LUA_META_ROTABLES >>> extern char stext[]; >>> extern char etext[]; >>> int luaR_isrotable(void *p) { >>> return stext<= ( char* )p&& ( char* )p<= etext; >>> >>> } >>> #endif >>> >>> The patch you provided for lua 5.1.4 - was it just an earlier version, or >>> was it specifically limited for some reason? >> >> The patch that was posted on the mailing list differs from what's now >> in our main repository. I'm not sure if there's a convenient >> broken-out version of of what's currently applied. Bogdan might be >> able to answer that one. >> >> If someone does manage to collect this, I'd be appreciative if it gets >> posted to the list as I wouldn't mind putting it on a branch on my Lua >> mirror repository: >> https://github.com/jsnyder/lua >> >>> Thanks for your help! >>> >>> >>> Brent Picasso >>> Autosport Labs >>> Technology for Race and Street >>> autosportlabs.com | twitter.com/AutosportLabs >>> >>> On 03/30/2012 03:33 PM, Brent Picasso wrote: >>> >>> Hi Martin, >>> >>> I made some progress on enabling LTR in my port. >>> >>> I got the patch applied and then attempted to register a test function >>> using >>> the instructions here: >>> http://www.eluaproject.net/doc/v0.8/en_arch_ltr.html >>> >>> specifically, this code: >>> >>> const luaR_entry mod_map[] = // note: no static this time >>> { >>> { LRO_STRKEY( "f" ), LRO_FUNCVAL( f_implementation ) }, >>> { LRO_NILKEY, LRO_NILVAL } >>> }; >>> >>> // note: in this case the "luaopen_mod" function isn't really needed >>> anymore >>> LUALIB_API int luaopen_mod( lua_State *L ) >>> { >>> return 0; >>> } >>> >>> declaring my function this way didn't seem to register it correctly with >>> lua; I felt something was missing. So I dug into the implementation of >>> luaI_openlib(). >>> >>> Inspecting this function I then came up with a way to manually register >>> functions in a 'light' way using the following macro: >>> >>> #define lua_registerlight(L,n,f) (lua_pushlightfunction(L, (f)), >>> lua_setglobal(L, (n))) >>> >>> I have about 125 functions registered using the standard lua_register() ; >>> switching to lua_registerlight() netted me a memory usage savings before >>> LTR of >>> >>> 23K to 13K usage as reported by print(collectgarbage("count")). About >>> 10K >>> savings. >>> >>> However, I'm not sure if I'm really using the full capability of the LTR >>> patch. >>> >>> Is the above approach still using RAM for each function registration? Is >>> there a better way to register my C functions with no memory usage? >>> >>> Thank you, >>> >>> Brent Picasso >>> Autosport Labs >>> Technology for Race and Street >>> autosportlabs.com | twitter.com/AutosportLabs >>> >>> On 03/30/2012 06:37 AM, Martin Guy wrote: >>> >>> hi >>> The Lua tiny ram patch as applicable to plain lua-5.1.4 is attached >>> >>> M >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> > _______________________________________________ > 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 |
|
|
Brent Picasso |
Re: Enabling Lua Tiny Ram in custom Lua port
|
|
Thanks!
We're working on firmware for an existing system (Data Acquisition for Race Car applications) where lua needs to be embedded as a library - that's why I'm going down this route. target is a AT91 SAM7s. However, we are working on a completely different project that we want to use eLua as a centerpiece; we're quite excited about it! I will make a brief presentation in a separate email. In the meantime, I'm working to get the eLua source compiling under the original 5.1.4 project. Here's what I have so far as a compiler output, without any attempts to fix up the code. Actually looks promising! make generic cd src && make generic make[1]: Entering directory `/home/brent/git-projects/lua-5.1.4.patched/src' make all MYCFLAGS= make[2]: Entering directory `/home/brent/git-projects/lua-5.1.4.patched/src' arm-elf-gcc -mcpu=arm7tdmi -mthumb -mthumb-interwork -Os -Wall -DLUA_OPTIMIZE_MEMORY=2 -c -o lapi.o lapi.c arm-elf-gcc -mcpu=arm7tdmi -mthumb -mthumb-interwork -Os -Wall -DLUA_OPTIMIZE_MEMORY=2 -c -o lcode.o lcode.c arm-elf-gcc -mcpu=arm7tdmi -mthumb -mthumb-interwork -Os -Wall -DLUA_OPTIMIZE_MEMORY=2 -c -o ldebug.o ldebug.c arm-elf-gcc -mcpu=arm7tdmi -mthumb -mthumb-interwork -Os -Wall -DLUA_OPTIMIZE_MEMORY=2 -c -o ldo.o ldo.c arm-elf-gcc -mcpu=arm7tdmi -mthumb -mthumb-interwork -Os -Wall -DLUA_OPTIMIZE_MEMORY=2 -c -o ldump.o ldump.c arm-elf-gcc -mcpu=arm7tdmi -mthumb -mthumb-interwork -Os -Wall -DLUA_OPTIMIZE_MEMORY=2 -c -o lfunc.o lfunc.c arm-elf-gcc -mcpu=arm7tdmi -mthumb -mthumb-interwork -Os -Wall -DLUA_OPTIMIZE_MEMORY=2 -c -o lgc.o lgc.c arm-elf-gcc -mcpu=arm7tdmi -mthumb -mthumb-interwork -Os -Wall -DLUA_OPTIMIZE_MEMORY=2 -c -o llex.o llex.c arm-elf-gcc -mcpu=arm7tdmi -mthumb -mthumb-interwork -Os -Wall -DLUA_OPTIMIZE_MEMORY=2 -c -o lmem.o lmem.c arm-elf-gcc -mcpu=arm7tdmi -mthumb -mthumb-interwork -Os -Wall -DLUA_OPTIMIZE_MEMORY=2 -c -o lobject.o lobject.c arm-elf-gcc -mcpu=arm7tdmi -mthumb -mthumb-interwork -Os -Wall -DLUA_OPTIMIZE_MEMORY=2 -c -o lopcodes.o lopcodes.c arm-elf-gcc -mcpu=arm7tdmi -mthumb -mthumb-interwork -Os -Wall -DLUA_OPTIMIZE_MEMORY=2 -c -o lparser.o lparser.c arm-elf-gcc -mcpu=arm7tdmi -mthumb -mthumb-interwork -Os -Wall -DLUA_OPTIMIZE_MEMORY=2 -c -o lstate.o lstate.c lstate.c:25:27: error: platform_conf.h: No such file or directory lstate.c:28:22: error: elua_int.h: No such file or directory lstate.c:29:22: error: platform.h: No such file or directory lstate.c:32:23: error: linenoise.h: No such file or directory lstate.c: In function ‘lua_close’: lstate.c:235: warning: implicit declaration of function ‘platform_cpu_set_global_interrupts’ lstate.c:235: error: ‘PLATFORM_CPU_DISABLE’ undeclared (first use in this function) lstate.c:235: error: (Each undeclared identifier is reported only once lstate.c:235: error: for each function it appears in.) lstate.c:239: error: ‘LUA_INT_HANDLER_KEY’ undeclared (first use in this function) lstate.c:240: warning: implicit declaration of function ‘elua_int_cleanup’ lstate.c:242: warning: implicit declaration of function ‘linenoise_cleanup’ lstate.c:242: error: ‘LINENOISE_ID_LUA’ undeclared (first use in this function) make[2]: *** [lstate.o] Error 1 make[2]: Leaving directory `/home/brent/git-projects/lua-5.1.4.patched/src' make[1]: *** [generic] Error 2 make[1]: Leaving directory `/home/brent/git-projects/lua-5.1.4.patched/src' make: *** [generic] Error 2 [brent@asldev lua-5.1.4.patched]$
Brent Picasso
Autosport Labs Technology for Race and Street autosportlabs.com | twitter.com/AutosportLabs On 04/03/2012 12:44 AM, Bogdan Marinescu wrote: Hi, On Tue, Apr 3, 2012 at 8:03 AM, Brent Picasso [hidden email] wrote:Thanks, James. What I'm noticing with the patch is when optimization is enabled, the functions normally exposed in the libraries like mathlib, etc are not being found at runtime. Something is amiss here; I'm digging some more.The version that Martin sent you is an old, outdated one. Unfortunately, I wasn't smart enough to update the patch as I updated the eLua source tree. I know I should do that.I'm noticing the eLua runtime has a different approach for finding the rotables; a linker script defines the areas in memory where the rotables can be found.Yes. This approach will be removed somewhere in the near future, but until then you need to define two symbols (stext and etext) in your linker command file (at the beginning and at the end of the .text region (which must also include your program constants) respectively).Question: could the lua folder of the eLua source be more-or-less dropped in to the src branch of the standard lua source and built like the original lua code, compiled to a static library?I would be surprised if this worked, but if you're brave enough give it a try and let us know how it works :) Best, BogdanBrent On 04/02/2012 06:43 PM, James Snyder wrote:On Mon, Apr 2, 2012 at 12:29 PM, Brent Picasso[hidden email] wrote: _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Brent Picasso |
New STM32 eLua platform / getting eLua binary working
|
|
Hello,
We're working on a new development board/platform using the STM32F103RE which will feature eLua as it's operating environment. Here's a rather fuzzy picture of our Rev A test board with Jtag connected: http://i.imgur.com/3cdSY.jpg We just got this board up and running; tested some non eLua sample projects to verify the processor is alive and a few peripherals can be controlled; like USART1 comms; SD card via SPI; LEDs and so on. Working with the eLua binary we're seeing a peculiar error; when processor comes out of reset, we see the eLua prompt on USART1, but we cannot interact with it - it does not respond to keyboard input from the terminal. When debugging the target running eLua it seems to be hanging in a polling loop for the console, and never seems to pick up the incoming data. At first I thought it was a hardware issue, but we've verified serial I/O works with USART1 via separate test firmware. for the console, does the eLua firmware rely somehow on a running real time clock? I have inspected the code around that area and wasn't exactly sure what it was doing in the serial polling / processing routine. Fortunately, I can at least debug the target via jtag so I will be digging into it some more. Thank you for any help! If there's any output / data dumps I can provide please let me know. I'm running the latest eLua source compiled for STM32 using the ET-STM32 stamp board target.
Brent Picasso
Autosport Labs Technology for Race and Street autosportlabs.com | twitter.com/AutosportLabs _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: New STM32 eLua platform / getting eLua binary working
|
|
On 5 April 2012 02:21, Brent Picasso <[hidden email]> wrote:
> We're working on a new development board/platform using tere hhe STM32F103RE > which will feature eLua as it's operating environment. > when processor > comes out of reset, we see the eLua prompt on USART1, but we cannot interact > with it - it does not respond to keyboard input from the terminal. I haven't had this exact problem, but there are two ways that the USART is driven. When BUF_ENABLE UART is undefined, it is polled, and when BUF_ENABLE_UART is on and CON_BUF_SIZE > 0, it is interrupt-driven. Maybe trying the other of these options compared to what you're using might help home in on the problem. Good luck! M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Thu, Apr 5, 2012 at 4:24 AM, Martin Guy <[hidden email]> wrote:
> On 5 April 2012 02:21, Brent Picasso <[hidden email]> wrote: >> We're working on a new development board/platform using tere hhe STM32F103RE >> which will feature eLua as it's operating environment. >> when processor >> comes out of reset, we see the eLua prompt on USART1, but we cannot interact >> with it - it does not respond to keyboard input from the terminal. > > I haven't had this exact problem, but there are two ways that the > USART is driven. When BUF_ENABLE UART is undefined, it is polled, and > when BUF_ENABLE_UART is on and CON_BUF_SIZE > 0, it is > interrupt-driven. > Maybe trying the other of these options compared to what you're > using might help home in on the problem. I would suggest looking in this direction as well. Is a completely unmodified port? Does it ever work over that USART or is it only under certain conditions. One other thing could be related to pin configurations if you've perhaps modified which pins the USART is available on and/or perform some reconfiguration of pins during startup (perhaps one thing is overriding another?) As I recall, the console may use some timer related facilities, but at least the last time I had a platform where the timer wasn't configured or available the main problem was that our code to try and handle different platforms' newline handling (\r, \n or \r\n) wouldn't work correctly, but it was still usable. > > Good luck! > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev -- James Snyder Biomedical Engineering Northwestern University http://fanplastic.org/key.txt ph: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Brent Picasso |
Re: New STM32 eLua platform / getting eLua binary working
|
|
On 04/05/2012 04:51 PM, James Snyder wrote: Hi James/ Martin -On Thu, Apr 5, 2012 at 4:24 AM, Martin Guy [hidden email] wrote:On 5 April 2012 02:21, Brent Picasso [hidden email] wrote:We're working on a new development board/platform using tere hhe STM32F103RE which will feature eLua as it's operating environment. when processor comes out of reset, we see the eLua prompt on USART1, but we cannot interact with it - it does not respond to keyboard input from the terminal.I haven't had this exact problem, but there are two ways that the USART is driven. When BUF_ENABLE UART is undefined, it is polled, and when BUF_ENABLE_UART is on and CON_BUF_SIZE > 0, it is interrupt-driven. Maybe trying the other of these options compared to what you're using might help home in on the problem.I would suggest looking in this direction as well. Is a completely unmodified port? Does it ever work over that USART or is it only under certain conditions. One other thing could be related to pin configurations if you've perhaps modified which pins the USART is available on and/or perform some reconfiguration of pins during startup (perhaps one thing is overriding another?) As I recall, the console may use some timer related facilities, but at least the last time I had a platform where the timer wasn't configured or available the main problem was that our code to try and handle different platforms' newline handling (\r, \n or \r\n) wouldn't work correctly, but it was still usable. It's running a completely stock eLua compiled for the ET-STM32 module. Looking at the schematics of our board, the only thing that might stick out is that we didn't bind RTS/CTS to the header for USART1- just RX/TX. Do you know if hardware flow control is enabled for the console? I will certainly look in the code as well. The other sample code we used that worked correctly was not using RTS/CTS. Thanks for your help so far! Brent Good luck! M _______________________________________________ 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 |
|
|
In reply to this post by jbsnyder
_______________________________________________
eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Brent Picasso
On Thu, Apr 5, 2012 at 7:58 PM, Brent Picasso <[hidden email]> wrote:
> > On 04/05/2012 04:51 PM, James Snyder wrote: > > On Thu, Apr 5, 2012 at 4:24 AM, Martin Guy <[hidden email]> wrote: > > On 5 April 2012 02:21, Brent Picasso <[hidden email]> wrote: > > We're working on a new development board/platform using tere hhe STM32F103RE > which will feature eLua as it's operating environment. > when processor > comes out of reset, we see the eLua prompt on USART1, but we cannot interact > with it - it does not respond to keyboard input from the terminal. > > I haven't had this exact problem, but there are two ways that the > USART is driven. When BUF_ENABLE UART is undefined, it is polled, and > when BUF_ENABLE_UART is on and CON_BUF_SIZE > 0, it is > interrupt-driven. > Maybe trying the other of these options compared to what you're > using might help home in on the problem. > > I would suggest looking in this direction as well. > > Is a completely unmodified port? Does it ever work over that USART or > is it only under certain conditions. One other thing could be related > to pin configurations if you've perhaps modified which pins the USART > is available on and/or perform some reconfiguration of pins during > startup (perhaps one thing is overriding another?) > > As I recall, the console may use some timer related facilities, but at > least the last time I had a platform where the timer wasn't configured > or available the main problem was that our code to try and handle > different platforms' newline handling (\r, \n or \r\n) wouldn't work > correctly, but it was still usable. > > Hi James/ Martin - > It's running a completely stock eLua compiled for the ET-STM32 module. > > Looking at the schematics of our board, the only thing that might stick out > is that we didn't bind RTS/CTS to the header for USART1- just RX/TX. Do you > know if hardware flow control is enabled for the console? I will certainly > look in the code as well. It shouldn't be unless "CON_FLOW_TYPE" is defined. I'm wondering if something else strange might be going on. I have an ET-STM32 stamp and just tried loading an image on and it seems to work. Images here: http://dl.dropbox.com/u/169337/elua_et_stm32/elua_lua_stm32f103re.bin http://dl.dropbox.com/u/169337/elua_et_stm32/elua_lua_stm32f103re.elf http://dl.dropbox.com/u/169337/elua_et_stm32/elua_lua_stm32f103re.hex Those are stock builds for what I have on the master branch with the exception that I left sieve.lua on ROMFS. I'd be interested in knowing if those have any difference, since they work for me. I know you mentioned that you ruled out hardware, but I'll mention this just in case it might be related: One other thing about that particular board that might be of importance is whether you're using the pins on the side of the board with a TTL-level serial device (connected to PA9/10 or you're going through the built-in RS-232 level shifter. The level shifter at least on the boards I have isn't one of the ones that automatically shuts down when nothing is connected to it on the serial side. At least on mine there's a 100 Ohm resistor between the ICL level shifter and the RX pin on the MCU, I believe in the mode it likely would be defaulting to with no RS-323 connection it tries to pull this pin down. If you have an adapter that doesn't have enough current to exceed the pulldown, you could end up with issues like what you're describing. We had a discussion starting about this last year starting here: http://elua-development.2368040.n2.nabble.com/ET-STM32-program-via-TTL-or-suggest-me-a-USB-to-serial-converter-cable-tt6128274.html#a6145330 One other thing: If you have a scope around, that would also let you know what's happening here. A permanent workaround to the issue, as I recall is removing that resistor (or cutting the trace) or replacing it with a higher resistance part. > > The other sample code we used that worked correctly was not using RTS/CTS. > > Thanks for your help so far! > Brent > > > Good luck! > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > > Brent Picasso > Autosport Labs > Technology for Race and Street > autosportlabs.com | twitter.com/AutosportLabs > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev -- James Snyder Biomedical Engineering Northwestern University http://fanplastic.org/key.txt ph: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Brent Picasso |
Re: New STM32 eLua platform / getting eLua binary working
|
|
Good news!
I pulled a fresh source branch, compiled it for the STM32 stamp using scons board=ET-STM32 toolchain=codesourcery and programmed it via JTAG. I disconnected the JTAG connection, powered it via the FTDI-USB adapter (which supplies 5v to the board) - and the console was responsive! As a bonus, I recompiled with MMC support and was able to read card contents as well. I believe the key was completely disconnecting the JTAG device; after writing the flash with openocd, it reset and outputted the eLua prompt, but immediately halted right after. Now I'm on to troubleshooting openocd with the codesourcery gdb; I'm seeing Hard Fault errors when attempting to reset and then continue using gdb. Anyone out there using openocd with the STM32 target? Thanks again!
Brent Picasso
Autosport Labs Technology for Race and Street autosportlabs.com | twitter.com/AutosportLabs On 04/05/2012 08:27 PM, James Snyder wrote: On Thu, Apr 5, 2012 at 7:58 PM, Brent Picasso [hidden email] wrote:On 04/05/2012 04:51 PM, James Snyder wrote: On Thu, Apr 5, 2012 at 4:24 AM, Martin Guy [hidden email] wrote: On 5 April 2012 02:21, Brent Picasso [hidden email] wrote: We're working on a new development board/platform using tere hhe STM32F103RE which will feature eLua as it's operating environment. when processor comes out of reset, we see the eLua prompt on USART1, but we cannot interact with it - it does not respond to keyboard input from the terminal. I haven't had this exact problem, but there are two ways that the USART is driven. When BUF_ENABLE UART is undefined, it is polled, and when BUF_ENABLE_UART is on and CON_BUF_SIZE > 0, it is interrupt-driven. Maybe trying the other of these options compared to what you're using might help home in on the problem. I would suggest looking in this direction as well. Is a completely unmodified port? Does it ever work over that USART or is it only under certain conditions. One other thing could be related to pin configurations if you've perhaps modified which pins the USART is available on and/or perform some reconfiguration of pins during startup (perhaps one thing is overriding another?) As I recall, the console may use some timer related facilities, but at least the last time I had a platform where the timer wasn't configured or available the main problem was that our code to try and handle different platforms' newline handling (\r, \n or \r\n) wouldn't work correctly, but it was still usable. Hi James/ Martin - It's running a completely stock eLua compiled for the ET-STM32 module. Looking at the schematics of our board, the only thing that might stick out is that we didn't bind RTS/CTS to the header for USART1- just RX/TX. Do you know if hardware flow control is enabled for the console? I will certainly look in the code as well.It shouldn't be unless "CON_FLOW_TYPE" is defined. I'm wondering if something else strange might be going on. I have an ET-STM32 stamp and just tried loading an image on and it seems to work. Images here: http://dl.dropbox.com/u/169337/elua_et_stm32/elua_lua_stm32f103re.bin http://dl.dropbox.com/u/169337/elua_et_stm32/elua_lua_stm32f103re.elf http://dl.dropbox.com/u/169337/elua_et_stm32/elua_lua_stm32f103re.hex Those are stock builds for what I have on the master branch with the exception that I left sieve.lua on ROMFS. I'd be interested in knowing if those have any difference, since they work for me. I know you mentioned that you ruled out hardware, but I'll mention this just in case it might be related: One other thing about that particular board that might be of importance is whether you're using the pins on the side of the board with a TTL-level serial device (connected to PA9/10 or you're going through the built-in RS-232 level shifter. The level shifter at least on the boards I have isn't one of the ones that automatically shuts down when nothing is connected to it on the serial side. At least on mine there's a 100 Ohm resistor between the ICL level shifter and the RX pin on the MCU, I believe in the mode it likely would be defaulting to with no RS-323 connection it tries to pull this pin down. If you have an adapter that doesn't have enough current to exceed the pulldown, you could end up with issues like what you're describing. We had a discussion starting about this last year starting here: http://elua-development.2368040.n2.nabble.com/ET-STM32-program-via-TTL-or-suggest-me-a-USB-to-serial-converter-cable-tt6128274.html#a6145330 One other thing: If you have a scope around, that would also let you know what's happening here. A permanent workaround to the issue, as I recall is removing that resistor (or cutting the trace) or replacing it with a higher resistance part.The other sample code we used that worked correctly was not using RTS/CTS. Thanks for your help so far! Brent Good luck! M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev Brent Picasso Autosport Labs Technology for Race and Street autosportlabs.com | twitter.com/AutosportLabs _______________________________________________ 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 |
|
|
Marcelo Politzer |
Re: New STM32 eLua platform / getting eLua binary working
|
|
I'm currently using other non-eLua chip but it seems that the scripts work for any stm32f10x. You may need to change the WORKAREASIZE, and the interface.
Anyways here it goes:
################################################### # FLASHING ################################################### # stm32f103vct6 256K / 48K interface jlink
source [find target/stm32f1x.cfg] adapter_khz 500 echo --------------------------------------------------------------------------- echo flash
echo --------------------------------------------------------------------------- init halt echo --------------------------------------------------------------------------- stm32f1x unlock 0
echo --------------------------------------------------------------------------- stm32f1x mass_erase 0 echo --------------------------------------------------------------------------- reset halt
echo --------------------------------------------------------------------------- flash write_image main.elf reset shutdown ###################################################
################################################### # DEBUG ###################################################
# stm32f103vct6 256K / 48K interface jlink source [find target/stm32f1x.cfg] set WORKAREASIZE 0x2000 adapter_khz 500
gdb_port 2332 echo --------------------------------------------------------------------------- echo debug echo ---------------------------------------------------------------------------
init halt reset halt ################################################### 2012/4/6 Brent Picasso <[hidden email]>
[]s, Marcelo
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Thiago Naves |
Re: New STM32 eLua platform / getting eLua binary working
|
|
I have had weird problems regarding interrupts when running the board with the JTAG plugged...
It was with the STR-E912 board, not STM32, but just something to keep an eye on. In my case it made things break in very subtle ways like some interrupts work and others don't ( which is quite troublesome when trying to write code for a new interrupt source ). I've never had issues with the terminal... Funny thing is that I work with 3 different boards with the same IC but only one appears to have this problem. If I find the exact source of the problem I'll post here. -- Thiago On Fri, Apr 6, 2012 at 2:11 AM, Marcelo Politzer <[hidden email]> wrote: I'm currently using other non-eLua chip but it seems that the scripts work for any stm32f10x. You may need to change the WORKAREASIZE, and the interface. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Apr 6, 2012 at 9:37 AM, Thiago Naves <[hidden email]> wrote:
> I have had weird problems regarding interrupts when running the board with > the JTAG plugged... Long story short: no matter what board/CPU you use, unplug your JTAG cable whenever you notice something that might be categorized as "weird behaviour". I've had countless problems with this. Best, Bogdan > > It was with the STR-E912 board, not STM32, but just something to keep an eye > on. > In my case it made things break in very subtle ways like some interrupts > work and others don't ( which is quite troublesome when trying to write code > for a new interrupt source ). > > I've never had issues with the terminal... > > Funny thing is that I work with 3 different boards with the same IC but only > one appears to have this problem. > If I find the exact source of the problem I'll post here. > > -- > Thiago > > > > On Fri, Apr 6, 2012 at 2:11 AM, Marcelo Politzer <[hidden email]> > wrote: >> >> I'm currently using other non-eLua chip but it seems that the scripts work >> for any stm32f10x. You may need to change the WORKAREASIZE, and the >> interface. >> >> Anyways here it goes: >> >> ################################################### >> # FLASHING >> ################################################### >> # stm32f103vct6 256K / 48K >> >> interface jlink >> source [find target/stm32f1x.cfg] >> >> adapter_khz 500 >> >> >> echo >> --------------------------------------------------------------------------- >> echo flash >> echo >> --------------------------------------------------------------------------- >> init >> halt >> echo >> --------------------------------------------------------------------------- >> stm32f1x unlock 0 >> echo >> --------------------------------------------------------------------------- >> stm32f1x mass_erase 0 >> echo >> --------------------------------------------------------------------------- >> reset halt >> echo >> --------------------------------------------------------------------------- >> flash write_image main.elf >> reset >> shutdown >> ################################################### >> >> ################################################### >> # DEBUG >> ################################################### >> # stm32f103vct6 256K / 48K >> >> interface jlink >> source [find target/stm32f1x.cfg] >> >> set WORKAREASIZE 0x2000 >> adapter_khz 500 >> gdb_port 2332 >> >> echo >> --------------------------------------------------------------------------- >> echo debug >> echo >> --------------------------------------------------------------------------- >> init >> halt >> reset halt >> >> ################################################### >> >> 2012/4/6 Brent Picasso <[hidden email]> >>> >>> Good news! >>> >>> I pulled a fresh source branch, compiled it for the STM32 stamp using >>> >>> scons board=ET-STM32 toolchain=codesourcery >>> >>> and programmed it via JTAG. I disconnected the JTAG connection, powered >>> it via the FTDI-USB adapter (which supplies 5v to the board) - and the >>> console was responsive! As a bonus, I recompiled with MMC support and was >>> able to read card contents as well. >>> >>> I believe the key was completely disconnecting the JTAG device; after >>> writing the flash with openocd, it reset and outputted the eLua prompt, but >>> immediately halted right after. >>> >>> Now I'm on to troubleshooting openocd with the codesourcery gdb; I'm >>> seeing Hard Fault errors when attempting to reset and then continue using >>> gdb. Anyone out there using openocd with the STM32 target? >>> >>> Thanks again! >>> >>> Brent Picasso >>> Autosport Labs >>> Technology for Race and Street >>> autosportlabs.com | twitter.com/AutosportLabs >>> >>> On 04/05/2012 08:27 PM, James Snyder wrote: >>> >>> On Thu, Apr 5, 2012 at 7:58 PM, Brent Picasso <[hidden email]> >>> wrote: >>> >>> On 04/05/2012 04:51 PM, James Snyder wrote: >>> >>> On Thu, Apr 5, 2012 at 4:24 AM, Martin Guy <[hidden email]> wrote: >>> >>> On 5 April 2012 02:21, Brent Picasso <[hidden email]> wrote: >>> >>> We're working on a new development board/platform using tere hhe >>> STM32F103RE >>> which will feature eLua as it's operating environment. >>> when processor >>> comes out of reset, we see the eLua prompt on USART1, but we cannot >>> interact >>> with it - it does not respond to keyboard input from the terminal. >>> >>> I haven't had this exact problem, but there are two ways that the >>> USART is driven. When BUF_ENABLE UART is undefined, it is polled, and >>> when BUF_ENABLE_UART is on and CON_BUF_SIZE > 0, it is >>> interrupt-driven. >>> Maybe trying the other of these options compared to what you're >>> using might help home in on the problem. >>> >>> I would suggest looking in this direction as well. >>> >>> Is a completely unmodified port? Does it ever work over that USART or >>> is it only under certain conditions. One other thing could be related >>> to pin configurations if you've perhaps modified which pins the USART >>> is available on and/or perform some reconfiguration of pins during >>> startup (perhaps one thing is overriding another?) >>> >>> As I recall, the console may use some timer related facilities, but at >>> least the last time I had a platform where the timer wasn't configured >>> or available the main problem was that our code to try and handle >>> different platforms' newline handling (\r, \n or \r\n) wouldn't work >>> correctly, but it was still usable. >>> >>> Hi James/ Martin - >>> It's running a completely stock eLua compiled for the ET-STM32 module. >>> >>> Looking at the schematics of our board, the only thing that might stick >>> out >>> is that we didn't bind RTS/CTS to the header for USART1- just RX/TX. Do >>> you >>> know if hardware flow control is enabled for the console? I will >>> certainly >>> look in the code as well. >>> >>> It shouldn't be unless "CON_FLOW_TYPE" is defined. I'm wondering if >>> something else strange might be going on. I have an ET-STM32 stamp >>> and just tried loading an image on and it seems to work. >>> >>> Images here: >>> http://dl.dropbox.com/u/169337/elua_et_stm32/elua_lua_stm32f103re.bin >>> http://dl.dropbox.com/u/169337/elua_et_stm32/elua_lua_stm32f103re.elf >>> http://dl.dropbox.com/u/169337/elua_et_stm32/elua_lua_stm32f103re.hex >>> >>> Those are stock builds for what I have on the master branch with the >>> exception that I left sieve.lua on ROMFS. I'd be interested in >>> knowing if those have any difference, since they work for me. >>> >>> I know you mentioned that you ruled out hardware, but I'll mention >>> this just in case it might be related: >>> One other thing about that particular board that might be of >>> importance is whether you're using the pins on the side of the board >>> with a TTL-level serial device (connected to PA9/10 or you're going >>> through the built-in RS-232 level shifter. The level shifter at least >>> on the boards I have isn't one of the ones that automatically shuts >>> down when nothing is connected to it on the serial side. At least on >>> mine there's a 100 Ohm resistor between the ICL level shifter and the >>> RX pin on the MCU, I believe in the mode it likely would be defaulting >>> to with no RS-323 connection it tries to pull this pin down. If you >>> have an adapter that doesn't have enough current to exceed the >>> pulldown, you could end up with issues like what you're describing. >>> We had a discussion starting about this last year starting here: >>> >>> http://elua-development.2368040.n2.nabble.com/ET-STM32-program-via-TTL-or-suggest-me-a-USB-to-serial-converter-cable-tt6128274.html#a6145330 >>> >>> One other thing: If you have a scope around, that would also let you >>> know what's happening here. A permanent workaround to the issue, as I >>> recall is removing that resistor (or cutting the trace) or replacing >>> it with a higher resistance part. >>> >>> The other sample code we used that worked correctly was not using >>> RTS/CTS. >>> >>> Thanks for your help so far! >>> Brent >>> >>> >>> Good luck! >>> >>> M >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >>> >>> >>> Brent Picasso >>> Autosport Labs >>> Technology for Race and Street >>> autosportlabs.com | twitter.com/AutosportLabs >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> >> -- >> []s, >> Marcelo >> >> >> _______________________________________________ >> 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 eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |