CCS/MSP430FR5994: Debugger is no more useble, but no error messages coms from compiler

Hello,

I see two separate problems here (maybe related? hard to say at this point).

I can try to address the below:

Hardy Zissel said:

But I think the problem of the debugger has an other reason.

If I send the program to the CPU I see the red button for terminate only. The Buttons for run, stop, go into, go over are gray and not usable.

If I had to guess, I suspect it is an issue with your debug contex. If you can provide a screenshot of your whole Debug view, I can confirm this. 

Hardy Zissel said:

The compiling prozess produce only 31 warnings: "#515-D a value of type "long" cannot be assigned to an entity of type "__SFR_FARPTR"    fram.c    /ContainerObserver02    line 632    C/C++ Problem"
I use this: #define __SFR_FARPTR long

How can I fix this problem? It coms at every line with loading command of the 20 bit registers of the DMA-modul. This is an example: DMA0SA = (__SFR_FARPTR)pStart;

I will have a compiler expert answer this one.

Thanks

ki

Regarding this problem ...

Hardy Zissel said:

warnings: "#515-D a value of type "long" cannot be assigned to an entity of type "__SFR_FARPTR"

Consider changing the code to use a compiler intrinsic such as __data20_write_long. For more background, see this forum thread. To see a list of all the compiler intrinsics, please search the MSP430 compiler manual for the sub-chapter titled Using Intrinsics to Access Assembly Language Statements.

Thanks and regards,

-George

Look to see if the option "Build Settings->CCS Build->Linker->Basic Options->Hold Watchdog Timer" is set to "on".

1335 bytes of data isn't particularly large, but this is the symptom you''d see if C initialization took so long that the Watchdog triggered.

Thanks for the fast answer. But the point "Hold Watchdog Timer" is on. Do you have an other idea? I checked the stack size. CCS shows the highest stack size is 26 bytes. This can also not be the cause.

Greatings
Hardy

Thanks.
To the problem with the warnings to the DMA-10-bit-register I received an answer. It solved this plroblem.

The otherone, the main problem, is open.

Regards
Hardy

Hardy Zissel said:

The otherone, the main problem, is open.

Can you provide a screenshot of the CCS IDE as requested in my previous post? 

Thanks

ki

Hello,

this is the sceen shot of the debug session directly after the start of the session. I con not push the run button.

I have perceived a effect. If I reduce the length of the longest c file I can debug the program. I is unimportand if I reduce it fron the begin or from the end. Is it possible that the length of the file or the numbers of the lines od a function are restricted?

Regards
Hardy

Thanks. In the Debug view, please select the node called "TI MSP430 USB1/MSP430". Once you select that, you should see the "suspend" button become available, allowing you to halt the target. Since the target is already running, the run and step buttons will still be greyed out. But you will be able to press the "suspend" button to halt the target.

Hello,

sorry, I don't understand what I have to do.

I am sending a screenshot of the General Properties page. Is it possible that the debugger can never run if I have chosen the wrong connection to the device?
I have the problem that the debugger is usable with 99% of the code. The program has more than thousand lines. If I set the comment characters /* */ in the following code segment, I can use the debugger. But I have to debug the complete program in real time. Why I don't get error messages?

int intToStr(int x, char str[], int l){
    int i = l - 1;
    int c = 0;
    while (x >= 0) {
        str[i--] = (x % 10) + '0';
        x = x * 0.1;
        c++;
    }
    c = l - c;
    while (i < c)
        str[i++] = '0';
    return l;
}
void ftoa(float n, char* res, int afterpoint){
    int ipart;
    ipart = (int)n;

    float fpart;
    fpart = n - (float)ipart;

    int i;
/*    i = intToStr(ipart, res, 0);

    if (afterpoint > 0) {
        res[i++] = '.';
        int m = 10;
        char n;
        n = 1;
        while(n < afterpoint){
            m = m * 10;
            n++;
        }
        fpart = fpart * m;
        intToStr((int)fpart, res + i, afterpoint);
    }*/
}

This are my settings of the General page. Is this what you mean?

Hardy Zissel said:

sorry, I don't understand what I have to do.

In the Debug view, you have the top node selected like so:

This is not a proper debug context, which is why all the target execution buttons are greyed out.

If you select the context below it like so:

Note the suspend button is now available for you to halt the running target to see where the program counter is.

Hardy Zissel said:

I am sending a screenshot of the General Properties page. Is it possible that the debugger can never run if I have chosen the wrong connection to the device?

In your screenshot, the debugger is connected to your target and showing target execution. If the code is not running as expected, it could be that there was some issue with your application or target. Suspend the target and see where the program is stuck.

Hello,

if I delete the comment signs in the code, activate the stop mode of WDT in project properties, start a debug session and I select the highlighted line (of your post) the suspend button is usable. If I push the green or yellow single step button the program counter switch between the first command of the boot code and the address 0xFFFA. How can I reach the Breakpoints, e.g. at 0x8DB8 or 0x8DC4 ?

If I set the comment signs in the short function for number format change it works normaly. I don't understand why is the function of the debugger dependent on the structure of the test code? With which option can I switch off the dependency?

Greating
Hardy

Hardy Zissel said:

if I delete the comment signs in the code, activate the stop mode of WDT in project properties, start a debug session and I select the highlighted line (of your post) the suspend button is usable.

The key thing regarding the suspend button being "active" is the proper debug context. Everything else will not have an impact regarding that.

Hardy Zissel said:

I don't understand why is the function of the debugger dependent on the structure of the test code? With which option can I switch off the dependency?

This issue sounds related to the application and not an issue with the debugger. The device experts can help you debug further. I will bring this thread to their attention.

Thanks

ki

This symptom makes it look like your code FRAM has lost X-ecute access. Have you changed your MPU settings (ever) for this project?

Hello,

I think yes. It was neccessary to write into FRAM. At other positions of this Program it works. The idea is to plan the memory protection at the end of this prject. At the development time it should be writable.

I think this way is to the right direction. I have isolate the problem points. I can use the debugger if i set the comment signs into the 3 lines with the pointer access to FRAM. This are the lines with str[i] = ... in my short source code of the last e-mail.

But the program write at meny points into the FRAM and it works. At the begin of the development process of this program I tried to write into the protected FRAM. The follow was the value of the target cells was constant. But the debugger works with this.

Do you have an idea whot I have to change in the MPU settings?

Best Regards
Hardy

Writeable is sort of orthogonal -- you need to make sure all the code (including the library/startup code in low FRAM) has Execute access.

I don't have my materials here, but I recall that setting an MPU configuration "Manually", then setting back to "Compiler managed" didn't seem to set all of my configuration back to some default state. I ended up manually putting everything back (I created a dummy project to get the default settings). Maybe that isn't your case, but that's why I said "(ever)".

The only thing I know to do is take the .MAP file and lay out the segments appropriately (1KB resolution). It seems possible that your added code was enough to nudge some code over some boundary.

Hello,

could you write where I find the .MAP file?

In the time I tried a other way. this small code segment generate the result in a array in RAM. After this I tried to move it via DMA to the target address in FRAM. Now it is some ting myterial for me. If I delete the comment singn only from the first line of the DMA configuration (DMA0CTL = 0x00;) the debugger can not work. In this case the debugger can not know that the operation has the target address in FRAM. What is it?

After loading the code into the CPU CCS wirte "MSP430:  Flash/FRAM usage is 21179 bytes. RAM usage is 1287 bytes.". Is it possible the code is to large?

Reagrds
Hardy

int intToStr(long x, char *str, int l){
    int c = 0,d = 0;
    char resStr[10];
    unsigned int i = sizeof(resStr);
    while (x > 0) {
        d = (x % 10);
        d += '0';
        if(*(resStr + i) != d) *(resStr + i) = d;
        i--;
        x = x * 0.1;
        c++;
    }
    i = c;
    while (i < l){
        resStr[l - i++] = '0';
    }
//    DMA0CTL = 0x00;
//    DMA0SA = (__SFR_FARPTR)(&resStr[0] + sizeof(resStr) - c);
//    DMA0DA = (__SFR_FARPTR)(&str[0]);
//    DMA0SZ = (unsigned int)l;
//    DMA0CTL = DMADT_5 | DMASRCINCR_3 | DMADSTINCR_3 | DMADSTBYTE | DMASRCBYTE | DMAEN | DMAREQ ; // Rpt, inc

    return c;
}

The .map file would be found in the build directory, typically "Debug".

Adding or removing code, out of context, could mean many things. 21KB/1.3KB isn't particularly large, so I think something else is going on.

When you get control using the Pause button, try doing a Hard Reset (that "chip" icon in the middle -- the one with the drop-down). That will take you to c_int00, but with pretty much everything cleared (BOR vs PUC). Then try stepping, and see how far you get.

Can you show us your MPU configuration?

Hello,

Sorry, I accidentally pressed the "resolved" button. But the theme is not resolved.

if I delete the comment sign from the line "DMA0CTL = 0x00;" and load the program into the debugger I have the follow situation:

I can coose the "TI MSP430 USB1/MSP430 (Running)" line. After this the yello "break" button is activ. If I push this, the other controll buttons are active an the progam counter in the disassembly view is on 0x00FFA. I can push the yello or the green step buttons. All have the same function. I can switch the program counter beween 0x00FFA and 0x8D0A (_c_int00_noargs_mpu()). If I push the reset button (whith the black IC) I have the same situation as after loading the program ("break" button active all others gray). But the coosed line (TI MSP430 USB1/MSP430 (Running) is still activ.

Please write my waht do you neet to the MPU.

Regards
Hardy

That "chip" icon has a drop-down list. One of the options is "Hard Reset". That applies a stronger reset (a BOR equivalent, I think) which I'm pretty sure will reset the MPU, so maybe you can (briefly) execute to see when things go wrong. What you're witnessing now is repeated PUC resets, which don't reset the MPU.

All the debugger knows is that your program never reached the breakpoint it set at main(). There are various reasons why this might (not) happen, and we're stepping through those possibilities.

I thought you said you changed the MPU configuration at "Build Settings->CCS General->MPU [Tab]"; if so a screenshot of that would be useful.