Skip to content
This repository has been archived by the owner on Jun 5, 2019. It is now read-only.

Llilum application template #237

Open
tkatsch opened this issue Jan 17, 2017 · 3 comments
Open

Llilum application template #237

tkatsch opened this issue Jan 17, 2017 · 3 comments

Comments

@tkatsch
Copy link

tkatsch commented Jan 17, 2017

I could build and install Llilum (LLVM, Zelig project, Board Configuration, Llilum SDK MSI and application template VSIX). In VS2015 (community version) I can create a new Llilum Application. After some bugfixes with the board confuguration and the wrong folder for storing managed_opt.o my build goes up to the end...
I used the default values predefined for using LPC1768 - I just created and build the solution, but I get linker failure with the following message:
##############################################################################
c:/program files (x86)/gnu tools arm embedded/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: region RAM overflowed with stack
1>collect2.exe : error : ld returned 1 exit status
##############################################################################

Thus, it seems that the build image needs more RAM than available!? Where can I find the RAM usage of the build? I just wondering that the default project uses LPC1768 but I cannot build it? Does any other person had the same issue? Maybe by Zelig SDK is wrong in some way?

Thank you for any hints.

@vgolovanov
Copy link

Hi.
Can you please share how did you fix folder problem with managed_opt file ?

Thank you.

@tkatsch
Copy link
Author

tkatsch commented Jan 23, 2017

Hi,

to say it more precisly... its the workaround another user initcated this here under issues. I simply copied the file after first failed build into the parent folder folder. Thank you for notify me, it is not a bug fix, it's a workaround.

Thank you!

@tkatsch
Copy link
Author

tkatsch commented Jan 24, 2017

Short update:

I build today a small Windows Desktop App (first quick and easy for testing) acting as File System Watcher. This app will watch the target subfolder in ARM/Debug and looking for 'llilum.Managed_opt.o' file creations or changes. Once detected, I auto copy this file to the ARM\Debug folder. Because this is so fast, the Llilum application build runs without failure and can create the application image to deploy or debug. It works fine for me.

I used a K64F project due to LPC1768 failed to build due to RAM issues...

What I discovered during Debug session, that - and I do not know why - certain breakpoints never get triggered even the code has to run through... but application seems to run...

And every time I initiate a debug or build the whole native project will be rebuild which needs some time. Normally all the native code coming from the Llilum SDK (except m own interop code normally will not be changed once tested... why the Llilum SDK rebuild everthing again? What I do not understand?

Many Thanks

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants