How to import Mesh examples to Keil or VisualGDB

[MeliodasD]

Hi there,

I would like to import the Mesh examples to Keil or VisualGDB (I have both licenses) instead running the examples using SES

[Andre]

I am not familiar with Keil or VisualGDB, so if they support importing projects from SES, that should be the way to go, however, since you're asking this question, I assume there is no such option, therefore, I suppose the only way to do so is adding them manually.

Open the .emProject file in a text editor, there you see  an XML  file. There you can see the include directories, defines and files used in the project, which you then have to add and set manually in your favourite IDE. And then add the linker file from the linker directory. 

Please note SES uses the GCC compiler. As Keil uses it's own compiler, there might be some GCC-specific code that does not compile. I don't know VisualGDB, but my first impression is it is GCC based so that should compile fine.

[MeliodasD]

Hi Andre, I was adding the files source files and headers files I found on SES to VisualGDB project I just created, I am able to compile, but I am having issues with the RAM, I am getting the following message

"Region RAM overflowed with stack"

1>c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/7.2.0/../../../../arm-eabi/bin/ld.exe: ../VisualGDB/Debug/mesh3 section `.bss' will not fit in region `RAM'
1>c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/7.2.0/../../../../arm-eabi/bin/ld.exe: region RAM overflowed with stack
1>c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/7.2.0/../../../../arm-eabi/bin/ld.exe: region `RAM' overflowed by 3921 bytes

my RAM/FLASH on the .lds file

GROUP(S132_softdevice.o)
MEMORY
{

  FLASH_SOFTDEVICE (RX)		: ORIGIN = 0x00000000, LENGTH = 0x00026000					
  FLASH (RX) 				: ORIGIN = 0x00026000, LENGTH = 0x5a000		                  	
  SRAM_SOFTDEVICE (RWX)		: ORIGIN = 0x20000000, LENGTH = 0x00007978
  RAM (RWX) 				: ORIGIN = 0x00007978, LENGTH = 0x8687
}

SECTIONS
{
  .softdevice :
  {
    KEEP(*(.softdevice))
    FILL(0xFFFFFFFF);
    . = 0x00026000;
  } > FLASH_SOFTDEVICE

  .softdevice_sram :
  {
    FILL(0xFFFFFFFF);
    . = 0x00007900;
  } > SRAM_SOFTDEVICE
}

so it seems I am running out of RAM, but almost the same files on SES compile just fine

[Bjørn Kvaale]

Hi,

Which mesh SDK are you currently running? v2.2.0? I would not recommend porting SES to Keil or Visual GDB. We unfortunately do not support either in the mesh sdk.

May I ask why you do not want to use SES? There is a free commercial license to use it with Nordic products (no memory limits like in the free version of Keil). I have used both SES & Keil & in my opinion, they are very similar to use. I prefer to use SES actually to Keil.

Kind Regards,

Bjørn

[MeliodasD]

Hi Bjørn, we are using VisualGDB because it is a requirement where I work, I managed to port my code to VisualGDB and it is compiling, but I am getting on my RTT output:

> <warning> nrf_sdh_ble: RAM starts at 0x20002A98, can be adjusted to 0x00005668.
0> <warning> nrf_sdh_ble: RAM size can be adjusted to 0xa998.
0> <error> nrf_sdh_ble: sd_ble_enable() returned NRF_ERROR_NO_MEM.

no sure how can I solve it

[awneil]

The warnings seem pretty self-explanatory to me: you need to adjust your VisualGDB project settings - specifically, the RAM start & size - to match what those warnings tell you.

As you say that VisualGDB is mandated at you workplace there must, surely, be co-workers who can show you how to do that?