Working Segger Embedded Studio project for ble_app_uart

[KannanK]

We recently decided to use the Nordic nRF52840. Given the nature of the use (BLE + Thread) of this device we were asked to use Segger Embedded Studio as our development platform using a Nordic supported external toolchain.

We are running SES 3.24 against nRF5 SDK 13.1.0.

We were initially given an SES project for the SDK example ble_app_uart using its own internal toolchain. Things progressed well for our development until we found that projects developed with the SES option "Build > Build and Debug" did not work with "Build > Build and Run". It turns out that ble_app_uart has the same issues as our application project. Interestingly if I build the project with armgcc or Keil, I do not have any issues. Here "does not work" means the device not advertise.

Of course, the internal GNU toolchain was meant to be an intermediate step while the project that uses the Nordic supported external toolchain arrives.

I would appreciate your help in getting a working SES project that uses an external GNU toolchain for a well known Nordic example like ble_app_uart.

If you need any further information, I'll be glad to provide it.

I have no issues if you ask me to a use a different version of SES or the SDK, provided the SDK is reasonably current.

Regards, Kannan

[RK]

What are you talking about 'internal toolchains' and what does 'waiting for the project which uses the Nordic external toolchain to arrive' mean? The toolchain is gcc (well SES has clang too but not on by default) so there's nothing to wait for.

You can 'build and run' your project, then attach a debugger to it and find out where it is. There's no difference between the two options apart from the fact the debugger doesn't automatically attach.

SES was derived from another product called Crossworks, and there you had to define 'STARTUP_FROM_RESET' in order to get the project to start without a debugger attached. However I see no code in the standard SES project which requires that.

[RK]

Thought I commented on this earlier but perhaps I didn't. The version of the toolchain is pretty irrelevant, minor or even major revisions of GCC don't change basic C and the SDK is basic C. Nordic may use a certain version of GCC but I don't think you should consider that as the maximum supported version, nor have I ever seen anywhere Nordic claims a supported version of GCC. C doesn't change, GCC doesn't change in respect to C.

If you have an issue with Build and Run over Build and Debug in your project, it has nothing to do with the version of GCC. Trying to build with an external toolchain will probably cause more issues (because it's hard) than you already have. I suggest you hit break in the build and run version and work out what the problem actually is. It's not the toolchain.