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.

CCS/TM4C1237H6PGE: sprintf, vsnprintf causing crash

Part Number: TM4C1237H6PGE

Tool/software: Code Composer Studio

I just created a project using CCS Version: 7.3.0.00019, compiler TI v17.9.0.STS for a TM4C1237H6PGE. When I attempt to call sprintf or vsnprintf, the program locks up. I placed blinking functions inside the faultISR(), but it looks like I never get there. I have modified the heap settings under ARM Linker -> Basic Options to a value of 1024, and ARM Compiler -> Advanced Options -> Language Options -> Level of printf/scanf support is set to Full. I have never encountered this on previous projects and versions of CCS, so I am looking for a little guidance.

Thanks, 

  • Are you using an RTOS? When it locks up, if you halt the CPU, where is the PC? Is it in one of the abort loops?
  • I tried to respond to my own post, the button wouldn't do anything (I was using Chrome). Anyway I switch to IE and apparently I can post responses.

    A lot has happened since my original post but the website wouldn't let me fill you in:

    1. I am not using an RTOS.
    2. I plugged in a debugger and it was failing inside the tiprintf function when the % character was being interpreted.
    3. It was causing a faultISR
    4. I made a bare bones project and was able to do sprintf.
    5. I then began systematically removing components of my project.
    6. After I commented out instantiation of an object that was decently large (3k) sprintf quit crashing.
    7. I then went to Properties->Build->Arm Linker->Basic Options and increased the stack size from 1024 to 10240.
    8. This appears to have fixed the problem.

    I have a uart class that has an rx and tx buffer of 512 and 256 bytes respectively. I had a manager class that instantiated three instances of uart (Which made my stack unhappy). I will probably move those buffers by using pointers to them instead.

    Does my conclusion make sense?

    Thanks,

  • Yes, that makes sense. Glad that you figured it out, and I appreciate you updating your status.