fault with calling int main( )

[Ubaid_M]

Hello,

I modified a sample app "blinky" on segger, to include main.cpp instead of main.c
Then when I built, I got a compile time error stating in main.cpp "void main(void)" should be changed to "int main( )"
I changed and it compiled successfully.

Now when I am running it on the board, the execution is not entering "int main( )" rather the execution is straight away entering fault_s.S, as in the screenshot:



Kindly help me in understanding why this is happening so and how I can get the execution to return to "int main( )" ..?


PS. I am using blinky sample app on segger, only changes I made is 
- Excluded main.c from the build
- Added main.cpp (Attaching for your reference)
- Added main.cpp in CMakeLists.txt (Attaching for your reference)

It is building successfully.



main.cpp

#include "stdio.h"
#include "stdint.h"

/**** 1. Demonstration On dynamic allocation  ****/
class Sample
{
  Sample* cPtr;
  public:
  Sample()
  {
    printf("ctor called \n");
    cPtr = new Sample();
  }
  
  ~Sample()
  {
    printf("dtor called \n");
    delete cPtr;
    cPtr = nullptr;
  }

};

/*
 * Copyright (c) 2016 Intel Corporation
 *
 * SPDX-License-Identifier: Apache-2.0
 */

//#include <zephyr.h>
//#include <device.h>
//#include <devicetree.h>
//#include <drivers/gpio.h>

///* 1000 msec = 1 sec */
//#define SLEEP_TIME_MS   1000

///* The devicetree node identifier for the "led0" alias. */
//#define LED0_NODE DT_ALIAS(led0)

//#if DT_NODE_HAS_STATUS(LED0_NODE, okay)
//#define LED0	DT_GPIO_LABEL(LED0_NODE, gpios)
//#define PIN	DT_GPIO_PIN(LED0_NODE, gpios)
//#define FLAGS	DT_GPIO_FLAGS(LED0_NODE, gpios)
//#else
///* A build error here means your board isn't set up to blink an LED. */
//#error "Unsupported board: led0 devicetree alias is not defined"
//#define LED0	""
//#define PIN	0
//#define FLAGS	0
//#endif
       void func(void)
       {
        Sample obj;
       }

int main(void)
{
	const struct device *dev;
	bool led_is_on = true;
	int ret;

        func();

	//dev = device_get_binding(LED0);
	//if (dev == NULL) {
	//	return;
	//}

	//ret = gpio_pin_configure(dev, PIN, GPIO_OUTPUT_ACTIVE | FLAGS);
	//if (ret < 0) {
	//	return;
	//}

	//while (1) {
	//	gpio_pin_set(dev, PIN, (int)led_is_on);
	//	led_is_on = !led_is_on;
	//	k_msleep(SLEEP_TIME_MS);
	//}

        return 0;
}

CMakeLists.txt

# SPDX-License-Identifier: Apache-2.0

cmake_minimum_required(VERSION 3.20.0)
find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(blinky)

target_sources(app PRIVATE D:/CPP_Test/cpp_files/main.cpp src/main.c)

[Einar Thorsrud]

Hi,

Ubaid_M said:

Further, i read that build.emProject modification is necessary when we define a new file, so I copied the fields under main.c as is into main.cpp with additional definition of "cpp_only_additional_options".

You should not do this within Segger Embedded studio. Make the new file outside of it, and add it in CMakeLists.txt. Then the Segger embedded studio project is generated for you correctly. (Generally, it is not a good idea to make changes within SES anyway as that does changes in the build folder, and you want to get your project correctly generated every time you open it or after you have cleaned it.)

I am still not able to reproduce the issue you are seeing. But using nRF Connect SDK 1.7.0 and the hello_world sample as you referred to it, it works and I am able to debug with a minimal change as demonstrated by this sample: hello_world_cpp.zip. Can you try that on your end? Open it in Segger embedded studio, build and debug. Does it work as expected?

As a side note, unless you are committed to using SES with your development, you may want to look at the nRF Connect for VS Code extension. That has some advantages over SES when used with the nRF Connect SDK.

[Ubaid_M]

Hello  Einar Thorsrud,

Einar Thorsrud said:

You should not do this within Segger Embedded studio. Make the new file outside of it, and add it in CMakeLists.txt. Then the Segger embedded studio project is generated for you correctly.

How do I make a new file outside of it and add it in CMakeLists.txt.?

Can you kindly suggest.!

Have attached my hello_world sample project for your reference with main.cpp

7041.CPP_Test.7z

[Einar Thorsrud]

I see you only included the SES build folder, but not the folder below, which is where the relevant parts are (your source files and the CMakeLists.txt and prj.conf). Regardless, the way to add an additional C file is to either simply add a new target_sources like this (snippet from CMakeLists.txt):

target_sources(app PRIVATE src/main.cpp)
target_sources(app PRIVATE src/other_source_file.cpp)

Or you can do it like this so that app files within your src folder is added automatically:

file(GLOB app_sources src/*)
target_sources(app PRIVATE ${app_sources})

Regarding creating the file that is just a text file, so you can use your favorite editor or any other way you prefer.

Noe that after doing this you must open the project in SES again using File -> Open nRF Connect SDK Project... so that CMake runs again.

[Ubaid_M]

Hello Einar Thorsrud,

I am facing compile time issues with the inclusion of nCS files in main.cpp:

Einar Thorsrud said:

see you only included the SES build folder, but not the folder below, which is where the relevant parts are (your source files and the CMakeLists.txt and prj.conf)

I couldn't understand this.

[Einar Thorsrud]

There is no indication here of what is wrong. I have updated the hello world sample to also add a second file with a dummy class. Please test that. If you experience problems use the Toolchain manager and open Segger Embedded Studio from there so that you know it works.

Please see this sample: hello_world_cpp_additional_source_files.zip. It works well with NCS 1.7.0 and SES, and demonstrates C++ including adding a second file.

As you see from this screenshot it works well debugging in SES:

And with a UART terminal you should see this output (board name will depend on the target board you are using to test):

Hello World! nrf52840dk_nrf52840
Number is: 5
Number is now: 10