at91sam7x build issue

classic Classic list List threaded Threaded
6 messages Options
Ashu Ashu
Reply | Threaded
Open this post in threaded view
|

at91sam7x build issue

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
Lukas Kacer Lukas Kacer
Reply | Threaded
Open this post in threaded view
|

Re: at91sam7x build issue

<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:

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


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

Re: at91sam7x build issue

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...

Lukas Kacer Lukas Kacer
Reply | Threaded
Open this post in threaded view
|

Re: at91sam7x build issue

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:

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...





--
View this message in context: http://elua-development.2368040.n2.nabble.com/at91sam7x-build-issue-tp7577941p7577943.html
Sent from the eLua Development mailing list archive at Nabble.com.
_______________________________________________
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
Ashu Ashu
Reply | Threaded
Open this post in threaded view
|

Re: at91sam7x build issue

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
Ashu Ashu
Reply | Threaded
Open this post in threaded view
|

Re: at91sam7x build issue

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.