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.

When string assignment is added to code, uP won't run.

Other Parts Discussed in Thread: TM4C123GH6PM

Part is tm4c123gh6pm

CCS  6.1.0


I have running project that writes chars to Uart 1, that has a serial character display connected.

It runs correctly when I send characters with the code:

UARTCharPut(UART1_BASE, 'H');

UARTCharPut(UART1_BASE, 'e');
UARTCharPut(UART1_BASE, 'l');
UARTCharPut(UART1_BASE, 'l');
UARTCharPut(UART1_BASE, 'o');

Then I declared a buffer:

unsigned char buf2[102];

So far, so good, simply adding this declaration does not crash the uP.

But when I add code that assigns a string to  buf2  and then load the code to the uP, the uP does not appear to run at all.

In other words it seems that having buf2 as an lvalue is somehow a problem.

Either of the following 2 lines of code, being present in the code, will cause the uP to not run:

strcpy(buf2, "A");

buf2[0] = 65;

In all of the TM4c123 TI labs, I did not find a single one that uses strings.

In the Peripheral Driver Library document I also did not find any strcpy used in sample code.

In the Peripheral Driver Library document I did find a string being loaded with a for-loop, using the second approach I included above.

Any help is much appreciated !

Thanks,

Rob

  • robert palma said:

    Then I declared a buffer:

    unsigned char buf2[102];

    Is buf2 given automatic storage, i.e. a local variable in a function?

    If so, the program may have insufficient stack space. Assuming you are using the TI ARM compiler, the stack size can be increased under the CCS Project Properties -> CCS Build -> ARM Linker -> Basic Options. Try increasing stack size by 256 bytes (more than the size of the buf2 array) and see if that prevents the problem.

  • It could be a number of things. Without more details we are just taking stabs in the dark.

    Robert
  • robert palma said:
    But when I add code that assigns a string to  buf2  and then load the code to the uP, the uP does not appear to run at all.

    Do you mean:

    a) CCS reports an error when trying to start a debug session?

    b) When starting a debug session the program doesn't reach main?

    c) When starting a debug session the program reaches main, but crashes or produces incorrect results when set running?

    d) Or something else?

    i.e. more details on the failure mechanism would help to identify the cause.

  • Dear Chester and Robert,

    Thank-you so much for your replies.
    Chester you nailed it. It runs fine now .... not sure I understand though.

    The code is in main.c
    I increased the stack as you said to 256 bytes (it was 100 bytes) and it runs fine.
    I understand that local vars in a function are held in the stack, but I guess I did not understand that that also applies-to main.c

    Would it make sense to declare global vars before main.c ?

    To answer the other questions, there was no reported errors that I could see, including in the consoles.
    The debugger would proceed to main, and halt as usual, but when I clicked to Resume, nothing would happen.

    Thanks again,
    Robe
  • robert palma said:
    I understand that local vars in a function are held in the stack, but I guess I did not understand that that also applies-to main.c

    Just to clarify, do you mean the following, where buf2 will be allocated on the stack:

    int main (void)
    {
        char buf2[102];
    
        strcpy (buf2, "A string");
    }

    Or the following, where buf2 will be allocated in the .bss section for zero-initialized global variables (as opposed to allocated on the stack):

    char buf2[102];
    
    int main (void)
    {
    
        strcpy (buf2, "A string");
    }

    Local variables in main are allocated on the stack, in the same way as any other functions.

    EDIT: corrected to say .bss is used for zero-initialized global variables

  • Yes Chester, the first one,

    So you are showing me that I allocated on the stack.

    Would the limit of the globals simply be the limit of RAM in the uP?

    I'm not familiar with the term .bss

    Many thanks,
    Rob
  • robert palma said:
    Would the limit of the globals simply be the limit of RAM in the uP?

    Yes

    robert palma said:
    I'm not familiar with the term .bss

    .bss is a standard term for C compilers and linkers - see https://en.wikipedia.org/wiki/.bss

  • Thank-you again Chester :-)