at91sam7x build issue
Locked
|
Hi all,
Started exploring eLua since last couple of weeks, this is my first post to this list. Here's my development host setup: Ubuntu 12.04 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 ... CPU: AT91SAM7X512 Board: SAM7-EX256 Platform: at91sam7x Allocator: newlib Boot Mode: standard Target: lua Toolchain: codesourcery ROMFS mode: verbatim Version: unknown ********************************* 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. Best, Ash _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
<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. Lukas On May 1, 2013, at 20:48 PM, Ashu V. wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Thanks Lukas,
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 #define BUILD_XMODEM #define BUILD_SHELL #define BUILD_ROMFS #define BUILD_TERM #define BUILD_CON_GENERIC //#define BUILD_RPC //#define BUILD_RFS //#define BUILD_SERMUX #define BUILD_C_INT_HANDLERS #define PLATFORM_HAS_SYSTIMER UPDATE: 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. Lukas. On May 1, 2013, at 22:08 PM, Ashu wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
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... Thanks again. Cheers, Ash |
|
|
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 AT91C_BASE_DBGU 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. |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |