Sysprogs forums › Forums › VisualGDB › Mbed compile problem
- This topic has 9 replies, 2 voices, and was last updated 7 years, 11 months ago by support.
-
AuthorPosts
-
November 28, 2016 at 19:52 #9608PreciousRoyParticipant
Hi,
I have some questions relating to using VisualGDB for mbed.
I have an GHI Electronics Retro that has the NPX LPC11U24 microprocessor, I followed the tutorial here to be able to program for it in visual studio. The simple blink code shown below compiles in mbed’s web editor and in visual studio.
#include “mbed.h”
int main()
{
DigitalOut led1(P0_9, false);
DigitalOut led2(P0_8, false);while (true) {
led1 = !led1;
led2 = !led2;
wait(.5);
}
}But when i copy the bin file to the usb drive the visualstudio generated bin file fails to run, it just starts in usb mode.
can anyone tell me what i am doing wrong, i dont have a debugger so i cant test using one.
Roy
November 30, 2016 at 05:09 #9623supportKeymasterHi,
It is hard to say what could be wrong based on this description. Please try debugging your program by pressing F5 in Visual Studio and step through the initialization code to see what is wrong.
December 6, 2016 at 07:51 #9706PreciousRoyParticipantHello,
when run in debug mode i get this error. i have it settup to use the built in GDB debugger.
Severity Code Description Project File Line Suppression State
Error ld returned 1 exit status MbedTest2 C:\Users\P-Roy\Desktop\MbedTest2\MbedTest2\collect2.exe 1December 7, 2016 at 05:32 #9718supportKeymasterHi,
This error indicates linker error and the Output window should contain more details about it. Most likely your linker script is corrupt or the program is too big to fit in the memory. In the latter case please select the newlib-nano library via VisualGDB Project Properties and try enabling the -Og optimization in the Visual Studio project properties (this is the optimization level that should not interfere with mots of the debugging features).
December 7, 2016 at 07:33 #9721PreciousRoyParticipanti dont think it is a size problem, i mean how can it be for 5 lines of code… of it does include stuff but still, and it has been set to newlib-nano as mentioned in the tutorial. here is the output text, sorry i should of done that first.
1> C:/Users/P-Roy/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.mbed/targets/TARGET_NXP/TARGET_LPC11UXX/device/TOOLCHAIN_GCC_ARM/TARGET_LPC11U24_401/LPC11U24.ld:50 cannot move location counter backwards (from 0000023c to 00000200)
December 8, 2016 at 02:50 #9739supportKeymasterHi,
Thanks for the build output. It looks like the linker script from mbed expects the SystemInit() function and the other functions to fit in 512 bytes:
KEEP(*(.isr_vector)) *(.text.Reset_Handler) *(.text.SystemInit) /* Only vectors and code running at reset are safe to be in first 512 bytes since RAM can be mapped into this area for RAM based interrupt vectors. */ . = 0x00000200;
Please change the optimization setting for the system_LPC11Uxx.c file to “Minimize size” via normal File Properties in VS (you need to be using the new MSBuild subsystem to set per-file settings).
December 12, 2016 at 08:27 #9776PreciousRoyParticipantOk now it indeed does build and run in debug mode,
However it never actually goes into my code it sits and waits on this line
while (!(LPC_SYSCON->SYSPLLSTAT & 0x01)); /* Wait Until PLL Locked */
in system_LPC11Uxx.c file.
cant see if it will run on my board just jet but will do tonight.
December 13, 2016 at 06:57 #9782supportKeymasterHi,
If your program never goes beyond that line, it means that your PLL never gets a stable frequency output. This may happen if the PLL multiplier/divider settings are incorrect for your board (e.g. the project you are building is meant for a different board with a different clock crystal).
December 13, 2016 at 18:05 #9790PreciousRoyParticipantHmm i am pretty sure i selected the right chip (NPX LPC11U24, using system_LPC11Uxx.c), i am however debugging with the GDB debugger (software). so i’m guessing thats the problem.
the release build however still does not work. any ideas on what els i can try ?
i am supposed to upload this file right VisualGDB\Release\MbedTest2.bin?
December 14, 2016 at 06:12 #9797supportKeymasterHi,
The clock crystal is not a part of the chip – it’s an external component on the board. I.e. 2 different boards using LPC11U24 may use 2 different clock crystals (e.g. 8MHz vs 25 MHz) and the initialization code for one of them will trigger the PLL problem you are observing on the other one due to the difference in frequencies.
When you select the LPC11U24 in VisualGDB, it uses the default system file that is shipped with mbed; the online version may actually use a file provided by your board manufacturer that is not a part of the regular mbed distribution that VisualGDB uses. Please try exporting your mbed project from the online compiler and use the system file and the configuration files from it.
-
AuthorPosts
- You must be logged in to reply to this topic.