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.

Does CIO functions halt CPU and wait for CCS intervention?

Other Parts Discussed in Thread: OMAP-L138

Hi,
 
 
When reading How Do Breakpoints Work (http://processors.wiki.ti.com/index.php/How_Do_Breakpoints_Work), in the end it says:
When code with CIO functions is loaded onto the target, CCS (by default) sets a breakpoint where the CIO symbol is loaded. Whenever one of these CIO functions is called that transports data from the target to the host, the data is gathered, and when it is ready to be transported, the application branches to this CIO symbol and halts.
An important point to understand is what exactly happens when CCS tells a target to run. CCS tells the target to run, and the target runs independently of CCS. But CCS will then periodically poll the device to see if it is halted.
1.    If it's not halted, CCS does nothing.
2.    If it is halted, then CCS checks the location of the Program Counter.
a.     If that counter is at a typical breakpoint, CCS will just update various windows (register, memory, etc) and wait for another instruction from the user.
b.    However, if that breakpoint is this special CIO breakpoint, CCS will then read the appropriate data off of the target, send it to wherever it needs to go (STDOUT window, file on disk, etc) and then it will automatically run the target again. If data is being transported from the host to the target, a similar action occurs in the reverse direction.
 
The key here is that the target gets halted and restarted by CCS without any notification to the user.
 
So it appears from the underlined paragraph that CIO functions halt CPU first, and continuation needs to be triggered by CCS.
We experimented under OMAP L138 by:

1.    Add some printf() code into various parts of the program, and these printf() executes about every 10 seconds

2.    Load the program into the device by emulator and run it when the JTAG is still connected. We do see the printf() message every 10s.

3.    Suddenly unplug JTAG header: however the program can still continue, and the device responds to all external commands via button or touchscreen correctly.

The observation in (3) suggests that CIO does not halt CPU indefinitely and requires CCS to continue running, which contradicts the Wiki article description.
Could someone clarify on this?
 
 
 
Paul
  • Paul Singh said:
    3.    Suddenly unplug JTAG header: however the program can still continue, and the device responds to all external commands via button or touchscreen correctly.

    According to the OMAP-L138 datasheet, there is a an internal pull-down on TRST. Therefore, think that when the JTAG header is unplugged TRST will be asserted, which as per the datasheet will cause "all test and debug logic in the device to be reset". i.e. the act of unplugging the JTAG header could reset any hardware breakpoints which are active.

    Could you try repeating the test, but fit an external pull-up to TRST prior to unplugging the JTAG header to see if the behaviour changes?

  • The CIO functions themselves do not issue any sort of halt or breakpoint.  They rely on the host (CCS in this case) to set breakpoints at special labels.

    If you remove CCS from a system which uses host CIO, the results of using CIO functions are undefined; that is, calls to any CIO function might not do anything reasonable, and might even loop forever.

    The button and touchscreen I/O you are referring to must not be going through host CIO, which is why they continue to be serviced even without CCS present.

  • Archaeologist,

    I see it, thanks for the answer.

    Paul

  • There's the input portion of CIO that needs to be addressed. If I perform a fscanf(stdin,"%s\n", ptr) - will the processor halt during the CIO processing to service a complete fscanf() entry?
  • Jim Swartzendruber said:
    will the processor halt during the CIO processing to service a complete fscanf() entry?

    Yes.  In the case of reading from stdin, CCS will wait for you to type something in the Console view.  That input is then sent, via the CIO System Call Protocol, back to the input function that is called (fscanf in your specific case).

    Thanks and regards,

    -George