• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 33 subscribers
  • Views 422 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.

Issue with C$$IO$$ cropping up on pause in debug on T4MC1233H6PM

Theodore Dufour26
Prodigy 30 points

I just ran into this issue using:

CCSV6.1.0 (most recent update)

TI-RTOS (most recent update 2.10.01.38)

XDC Tools (3.31.00.24)

Target is T4MC1233H6PM

SmartRF06 board jumpered to T4MC1233H6PM JTAG pins as XDS100v3.

Running Windows 7 on Xenon E31230

Screen capture and comment in attached pdf (picture is worth 1000 words).

.I've seen references to this popping up in other posts with no real good explanation as to how it happens and how  to avoid it.   Admittedly, there is a 4 inch of ribbon between the SmartRF06 board and the target (the board is custom design).

The application is incredibly simple, packets fed in on UART0, buffered then transmitted out on UART1.   When I jumper the source and target together without involving the Tiva Chip, it works as intended.  I've been an engineer for 38 years, this is the first time I've had this much "adventure" developing something as simple as this.

This is only one in a long series of "issues" that keep cropping up with what should be a straightforward tool-chain.  Is there a possible incompatibility running your tool-chain (CCSV6) on the Xenon processor (just a desperate grasp at an explanation).

RequiresExplanation.pdf

  • 0
    TI__Guru**** 244440 points
    Hello Theodore,

    Surely it is not the 4" cable. When you mentioned that the source and target are jumpered w/o Tiva chip it works as expected. But as per the post the Target is the Tiva chip? Am I missing something?

    Regards
    Amit
  • 0
    Guru 92251 points

    C$$IO$$ is the run time library function which used to allow the target to perform C I/O when running in the debugger (see http://processors.wiki.ti.com/index.php/Tips_for_using_printf .

    Does your program perform any explicit C I/O?

    If the program doesn't perform any explicit C I/O, then maybe TI-RTOS is detecting any error, since TI-RTOS can attempt to use C I/O to report an error. [e.g. if an exception occurs when the program attempts to access an invalid address]

    Under CCS Project Properties -> Debug -> Program/Memory Load Options -> Program/Memory Load Options is the "Enable CIO function use (requires setting a breakpoint)" ticked? When that option is ticked then CCS will automatically set a breakpoint on C$$IO$$ to handle any C I/O for the target.

  • 0 in reply to Chester Gillon
    Prodigy 30 points
    Although the application started out a bit more complex, I've basically reduced it to three tasks (running at equal priority) running under TI-RTOS with no interrupts (other than ones within TI-RTOS). In theory, less sources of error reduces the probability.

    I typically don't use printf()s to debug; my guess is that the these are likely TI-RTOS generated. When possible, I tend to use a Fault ISR handler to figure out the source of any "unexpected" problems and trapping asserts where I think design errors might occur (much in the style of FreeRTOS).

    Thanks for the link to the C I/O information. At least it gives me some way of putting the wheels back on the wagon and push it up the hill a bit further.
  • 0 in reply to Amit Ashara
    Prodigy 30 points
    Amit,

    The Tiva chip is always in place (sorry for any confusion). Since there's no scan-chain on the custom board, TMS, TCK, TDI, TDO are directly connected to the Tiva chip. Mentioning the length of the cable was to simply bring up the only hardware related aspect I could think of that might present a problem.

    I think Chester Gillon pretty much hit the source of the C$$IO$$ issue in his response. I strongly suspect the TI-RTOS is attempting to printf() in response to a YTBD error and C$$IO$$ is hanging things up.

    Thanks,
  • 0 in reply to Theodore Dufour26
    Guru 92251 points

    When set a breakpoint on a function which was written in assembler, when the breakpoint was hit I noticed that the stack backtrace in the CCS 6.1 Debug view wasn't showing the stack backtrace. I.e. similar to your C$$IO$$ example:

    While I haven't figured out how to get the CCS debugger to display a stack backtrace when halted in an assembly function if you look at the value of the LR (Link Register) in the Core Registers in the Registers view, the value of the LR should give the address from which the assembly function was called. You can enter the value of the LR in the Disassembly view or look it up in the Linker .map file to identify which function the LR address is within.

    Getting the function which called C$$IO$$ should help to identify what happened in your case.