SES debugging support in complex project not working as expected

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • SES debugging support in complex project not working as expected

      Hi,

      We've been using SES v4.12 and SES v 4.14 on both windows and on Mac.

      We have huge problems with the intelisense and everything else regarding the coding/debugging aiding and it's driving me nuts soon. Is this a known issue or are we 4 using the program the ONLY ones that see this?

      What happens is a bit hard to pinpoint (varies depending on how long SES been open, what platform we're on and how many times we've debugged) but the results are these:

      * If you have several layers of include files (for example in freertos) SES don't correctly detect what symbols are defined and not, resulting in code being "grayed" out or vise verse, even though that code is built and you can place breakpoints that you end up in when debugging in hw (currently an arm m33, but We've seen this on STM32Fx as well).
      * The "go to definition" and "go to declaration" rarely works, and especially if it's defined as a static variable or a define that's included through a number of files.

      The "grayed out" code bug seems to be sporadic, sometimes it's enough to just edit the #ifdef SOMEDEFINETHATSDEFINED by for instance just delete and retype the D and it will display the code correctly, sometimes it will NEVER show the code as enabled, but yet if you place an #error statement, or a printf in that section that comes out so it's obviously compiled.
      It seems more prominent when defines are defines not made in the same file or one "file depth" up, ie NOT included in an include file you just included.
      To get the CGG compiler flags like __ARM_PCS_VFP or the like is impossible, they compile correctly and exist for the compiler, but not for the IDE somehow.

      The "Go to definition" bug seems to be a bit random, sometimes it works, sometimes it doesn't. Some times a reboot seems to mend the problem, sometimes it doesn't. Rebuilding the project
      does not help. Static definitions seems to be very hard for it to resolve, so not even in the same file it can find the variable...

      Is there any way we can debug this or are there any plans to get this sorted?

      This is driving us nuts, and we're seriously contemplating going over to another IDE that handles this properly (like Xcode embedded or Visual GDB) but its a pita writing all the debugging definitions for this so it would be much easier if someone just sad; "stupid, just do this" to solve this...

      Hjalmar
    • Hello Hjalmar,

      Thank you for your inquiry.
      Such issues are not known to us.

      Hjalmar wrote:

      If you have several layers of include files (for example in freertos) SES don't correctly detect what symbols are defined and not, resulting in code being "grayed" out or vise verse, even though that code is built and you can place breakpoints that you end up in when debugging in hw (currently an arm m33, but We've seen this on STM32Fx as well).
      Did you change the build config or preprocessor defines by any chance?
      Could you try to reload the project if you see this appear with either the reload button in the project explorer or under Project->Reload.
      Does that improve the highlighting?


      Hjalmar wrote:

      * The "go to definition" and "go to declaration" rarely works, and especially if it's defined as a static variable or a define that's included through a number of files.
      Are all referenced header files known to the project via the "User include directories" option?
      Is it possible that there are redefinitions in separate header files that might interfere here?

      Unfortunately we could not reproduce the reported behaviour with our test projects. Could you provide us with a example project for reproduction purposes?

      Best regards,
      Nino
      Please read the forum rules before posting: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support contact us per e-mail.
      Alternatively our support ticketing system can be used as well: segger.com/ticket/