Started exploring eLua since last couple of weeks, this is my first post to this list.
Here's my development host setup:
gcc-arm-none-eabi 4.7 (2012q4)
Eclipse/Juno CDT, w/Sconsolidator plugin
Trying to build standard eLua(v9) at91sam7x port as is, using -- scons cpu=at91sam7x512 prog
Build process went well, no errors
Expecting to see eLua prompt over RS232 connection, Moserial terminal on host side set to 115200, 8n1
no movement there, tried sending ENTER (0D hex) that didn't cause any response from the target either.
So, launched Eclipse in debug mode. First re-built the image with
comp.Append(CCFLAGS = ['-g']) and
comp.Append(CCFLAGS = ['-O2','-fomit-frame-pointer']) optimization changed from -Os to O2 thinking that would be better for debugging.
Again, build process went well, no errors
However what I noticed that was disconcerting -- "platform_conf.h" that included in src/main.c seems to be coming from /src/platform/sim and not /src/platform/at91sam7x I would have expected, since build messages c/p below, clearly confirm that scons recognizes it's building for at91sam7x platform.
Compiling eLua ...
Boot Mode: standard
ROMFS mode: verbatim
What could be wrong here? I can easily fix this one path issue, but my concern is, based on this instance, if there may be other places where wrong platform files/ settings may be pulled in(?) perhaps, causing my image to not showing eLua prompt (via RS232). I see console, terminal and related settings are enabled by default in src/platform/at91sam7x/platform_conf.h
Any help will be greatly appreciated. Once past this, I intent to port eLua to at91sam7s; should be easy with 7x as reference.
Thanks for any timely help.
eLua-dev mailing list
<base href="x-msg://2700/">why do you think that it is using src/platform/sim ? if it is because eclipse shows that?
I use myself some scons plugin in eclipse and it is almost always wrong about these things.
I remember that I had problem serial console with at91sam7x port, and could not figure out why.
it was because serial multiplex was enabled in eLua. to disable it you need to comment out BUILD_SERMUX in platform_conf.h
do I understand you right, that when you turn on your board with, do you see eLua prompt?
if yes, then you don't have problem with serial multiplex.
On May 1, 2013, at 20:48 PM, Ashu V. wrote:
eLua-dev mailing list
Yes, it's based on Eclipse (Open declaration) that's showing path to /src/sim
SERMUX is in fact disabled; even with that I do NOT see eLua prompt via RS232.
Here are the options selected in platform_conf.h
// Define here what components you want for this platform
Debugging (break-pointing) further I noticed, in shell.c printf which is supposed to send elua prompt doesn't appear to send it to uart. Diving deeper to understand printf is in fact bound to uart. Sounds like trouble in stdio, newlib area.
More on that soon...
my define section looks almost like yours, just I have also BUILD_XMODEM commented out, but that should not be problem.
other think that came in my mind is if you have correct CON_UART_ID. I checked in the git and it is the same as I have:
//#define CON_UART_ID ( SERMUX_SERVICE_ID_FIRST + 1 )
#define CON_UART_ID 0
you mentioned that you tried to debug shell.c, so you probably don't hang somewhere in HW initialization.
which board are you using? you could have also some HW issue.
is your serial connected to UART 0? some boards have jumpers to select what will be connected to connector and some boards like my one use DBGU instead UART.
there is small chance that you can have crystal with different freq. I don't remember from what the communication speed depends, but I guess that it could be problem. my is 18.432
if you are able to use GDB for debugging, try to put breakpoints to
src/common_uart.c line165. it should be inside function platform_uart_send
and step inside to see if it goes to src/platform/at91sam7x/platform.c and if it is doing what is expected.
if it will not break there, try breakpoint in
src/newlib/genstd.c at line 93 in function std_write. you should get in function std_send_char_func
the line numbers I get from actual git repository.
have in mind that you have limited numbers of breakpoints. (maybe just 2? don't remember.)
if you will not get to that breakpoints, something strange is happening.
try to make breakpoint on some printf. If I do step-in on my gdb-remote on printf (or some other newlib fund) it will make step-over. to do step-in, I have to make steps by instructions.
I hope that at least something will help you.
I'm just junior, so sorry If I wrote something wrong. I hope that somebody will correct me in that case.
On May 1, 2013, at 22:08 PM, Ashu wrote:
eLua-dev mailing list
Thanks Lukas; problem solved.
Your mention of DBGU (vs. UART0/1), together with suggestion of breakpoint in src/common_uart.c line165 led me to it.
Now off to exploring console, term and xmodem features...
FYI, for SAM7/ other platform port'ers and perhaps for build/ porting doc, faq purpose...
In case you're planning to use DBGU for serial shell/ terminal/ console; please keep in mind...
1) Choosing CON_UART_ID in platform_conf.h won't help. Instead make sure to replace AT91C_BASE_USx with
2) Either explicitly enable receive interrupt for DBGU or simply disable(comment out) both the RX buffering defines
This allowed proper shell operation on my SAM7 module.
|Free forum by Nabble||Edit this page|