• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 2 replies
  • Subscribers 75 subscribers
  • Views 1131 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 250739
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF Connect SDK for nrF91690, version 1.2.0 and 1.3.0-rc1, Toolchain manager, macOS and Windows: cannot debug

pemar13

Hi,

My problem has similarities with Case 250648 (for nRF52840):

When trying to run your AT-client sample for the nRF9160 on your DK board, I cannot debug. Segger Embedded Studio gives the get the error "Failed to set startup completion breakpoint: main symbol not found"

This occurs for:

1. ncs v1.3.0-rc1 on windows 10 (a complete fresh install of 1909 with no other development tools) set up using the latest version of your Toolchain manager

2. ncs v1.3.0-rc1 on macOS Catalina set up using the following your http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ using a Python Virtual Environment (as described in my answer to case 250284).

This does not occur for:

3. ncs v1.0.0 set up on windows 10 following your http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/.

4. ncs v1.2.0 on macOS Catalina set up using the following your http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ using a Python Virtual Environment.

My conclusion is that something is seriously wrong with v1.3.0-rc1.

You are often quick to inform that the latest master shouldn't be used, but I am forced to do this since I must implement A-GPS with does not work with the sample you provide with ncs v1.2.0 but does work with later version of that sample. Since you don't release any bug fixes to your tagged releases, it is extremely hard to know which code base to use.

Also, I guess the whole point with RC's is that they should be tested.

I have asked before which development environment you use most internally, but haven't got an answer. Given all the problems getting macOS Catalina to work and now this issue with  the Windows environment, I wonder if you recokmmend Linux.

Best regards,
Per

Parents
  • +1

    Hi Per,

     

    When trying to run your AT-client sample for the nRF9160 on your DK board, I cannot debug. Segger Embedded Studio gives the get the error "Failed to set startup completion breakpoint: main symbol not found"

    I can confirm that we do see this issue in a corner case, and we are working on getting this issue fixed.

    The reason is that the .elf file does not seem to be properly detected and populated in the SES-NordicEdition debug settings, so I needed to add the .elf manually, as shown here:

     

    This behavior looks to be a issue with SES, not OS dependent, and the issue is a very unfortunate regression from our side, and I must apologize for this behavior. My apologies for the inconvenience that this has caused.

     

    You are often quick to inform that the latest master shouldn't be used, but I am forced to do this since I must implement A-GPS with does not work with the sample you provide with ncs v1.2.0 but does work with later version of that sample. Since you don't release any bug fixes to your tagged releases, it is extremely hard to know which code base to use.

    This is correct. AGPS features in v1.2.0 isn't fully implemented. It is possible to get it running by implementing the nrf_socket API for the GNSS socket directly, but support for AGPS in nrf9160_gps driver was added at a later point in time. 

     

    I have asked before which development environment you use most internally, but haven't got an answer. Given all the problems getting macOS Catalina to work and now this issue with  the Windows environment, I wonder if you recokmmend Linux.

     We support all three main desktop OSes, and we try to use all of them. Windows is still the most commonly used OS, so we have focused on this first towards getting toolchain manager support.

    Providing a Toolchain manager for linux is not yet there, and has proven to be a bit more difficult, as there are so many distros available, thus providing many variations of installed dependencies on a system (glibc etc), and local kernel configurations can also create incompatibilities.

     

    Kind regards,

    Håkon

Reply
  • +1

    Hi Per,

     

    When trying to run your AT-client sample for the nRF9160 on your DK board, I cannot debug. Segger Embedded Studio gives the get the error "Failed to set startup completion breakpoint: main symbol not found"

    I can confirm that we do see this issue in a corner case, and we are working on getting this issue fixed.

    The reason is that the .elf file does not seem to be properly detected and populated in the SES-NordicEdition debug settings, so I needed to add the .elf manually, as shown here:

     

    This behavior looks to be a issue with SES, not OS dependent, and the issue is a very unfortunate regression from our side, and I must apologize for this behavior. My apologies for the inconvenience that this has caused.

     

    You are often quick to inform that the latest master shouldn't be used, but I am forced to do this since I must implement A-GPS with does not work with the sample you provide with ncs v1.2.0 but does work with later version of that sample. Since you don't release any bug fixes to your tagged releases, it is extremely hard to know which code base to use.

    This is correct. AGPS features in v1.2.0 isn't fully implemented. It is possible to get it running by implementing the nrf_socket API for the GNSS socket directly, but support for AGPS in nrf9160_gps driver was added at a later point in time. 

     

    I have asked before which development environment you use most internally, but haven't got an answer. Given all the problems getting macOS Catalina to work and now this issue with  the Windows environment, I wonder if you recokmmend Linux.

     We support all three main desktop OSes, and we try to use all of them. Windows is still the most commonly used OS, so we have focused on this first towards getting toolchain manager support.

    Providing a Toolchain manager for linux is not yet there, and has proven to be a bit more difficult, as there are so many distros available, thus providing many variations of installed dependencies on a system (glibc etc), and local kernel configurations can also create incompatibilities.

     

    Kind regards,

    Håkon

Children
Related
Terms of service