• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 81 subscribers
  • Views 535 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-F280049C: CCS breakpoints, skips over decals and other code lines.

Genatco
Guru 55923 points
Part Number: LAUNCHXL-F280049C


Hello forum,

Have issues with CCS v12.2 behavior after IDE had java Null pointer exception, debug break points manager has lost his mind. Moving code down or up in editor while there is debug paused and reload program does not  move the existing break points to follow the new line positions up or down, sometimes it does. What to do for the odd things below? 

Cleaning the project closing CCS launching with -clean the same odd issues occur. Clearing all breakpoints, stop target, rebuild launch debug, code lines are orphaned by break point manager and simulator. Also removed power from the target powered via USB. When adding a breakpoint on the line of code or declarations XDC110 skips over (does not display in variables tab) break point jumps down several lines to a past removed break point.

Is there some way to clear breakpoints history in the IDE to make XDC110 work correctly again?  I noticed stepping speed F5, F6 much faster and has forever had issues to process 4 loops without selecting run 2 line just under, often return(0) statement is the only syntax emulator will run 2. When try to F7 after F5 to F6 fails that cause illegal instruction exception NMI (interrupt.h) when no such instruction has ever occurred. There is no bad instruction only bad simulator behavior as if the emulator is not on the same page when NMI occurs. Noticing the target after POR runs to (main.c) locks up, does not do that in debug mode being even more perplexing.

The F7 is was past to process (for) statement when source code exists and stepped into F5 or F6 and seems broken in this CCS version. So F7 just jumps over existing break points when it should run to next breakpoint then hold. Oddly there have been no updates for CCS12.2 last to run on windows 7. After upgrading to 10 on another machine it's not top priority as upgrade 7 to 10 does not save registry or applications settings and forget 11 that's a hardware can of worms.

Regards,

  • 0
    Guru 55923 points

    After rebooting my computer the same odd issues. CCS break points are ghosting greyed out when reapplied to line numbers during pause, breaks existed prior to java exception. Compiler TI 21.6.1.LTS

    Step into F5 or F6 refuses to execute the simple code below, only F7 can move past jumps past all other breaks in the function. Code is tested via hexadecimal calculator to be very functional. The pointer (uint32_t) has the value at the address & 0x1000 - 1 = 0. any other 256KB address (9C=156) with 156 bytes are blocked to the else statement below.

    Why is this code not being executed by the debug simulator or XDS110 emulator? The compiler is not issuing any warning or error and the same basic code piece works via ARM compiler TM4C. These address pointers are less than 22 bits long even though 32bit data type was required. 

    Below algorithm would not execute in debug mode and had to be replaced by generic if (OR) with addresses. The code below blocked every step method even F7.

    // Only assert erase mode if at the start of a different flash sector.
    // pui16New 0x0009C09C = 639132, 0x0009c000 = 638,976
    if((*pui16New &(FLASH_SECTOR_SIZE - 1) == 0)
    { 

        // We matched pointer value to 0x00009C000 and not 0x0009C09C or any other address blocks of 256KB accept,

        // 0x0009D000, 0x0009E000, 0x0009F000 

    }

    else

    {

    }

  • 0 in reply to Genatco
    Guru 55923 points

    I remove the comment between these two lines below and new break points no longer are ghosting below when C module code shifted backup 1 line. This proves IDE is keeping previous history that has been changed, as active history and break point manager has heart attack and dies. Hence ghosting of break points below the shifted lines and very odd emulator simulator behavior, though debug stepping speed doubled with the comment (//) in place.

     pui16New = g_pui16FlashPBCurrent + ui16NumParams;
    if(pui16New == g_pui16FlashPBEnd)
    {  

  • +1 in reply to Genatco
    Guru 55923 points

    Declarations with keyword (static) are being stepped over when F5 stepping. The simulator ignores the memory mapped address even though static pointer may be showing up via hover over static variable in the function or in the variables tab. Hence the algorithm refused to execute unless the pointer is made Volatile? The static keyword pointer shows the flash memory address during hover, debug paused and in the variables tab. Only tipped off when flash address failed to load into the memory map and hover shows an error.

    Genatco said:
    if((*pui16New &(FLASH_SECTOR_SIZE - 1) == 0)

    All variable declarations had to have Volatile keyword even though function optimizations #pragma set register 0 speed 0. These are issue that should have been fixed in earlier CCS versions, let alone CCS v12.2. The C2000 debug simulator should not jump over the keyword (static) even when the static variable is a pointer with less than 22 bits. In fact the static variable pointer was not being initialized 0x0 and unit16_t variables set to = 0 were not being initialized either.