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/OMAPL138B-EP: System crash

Part Number: OMAPL138B-EP


Tool/software: Code Composer Studio

Dear all,

we are using the OMAP L138 ARM + DSP Controller. We have SYS/BIOS on the ARM, no operating System on the DSP. I am currently tracing a bug where the whole system gets stalled. The fault should be on the DSP, because small code changes there can Switch it on ofr off.

When I have started the software via debugger, and the error has occurred, I try to stop the OMAP L138 DSP and get the following message:

Trouble Halting Target CPU:
Error 0x00000020/-1202
Error during: Execution,

CPU pipeline is stalled and the CPU is 'not ready'. This means
that the CPU has performed an access which has not
completed, and the CPU is waiting. The target may need to be
reset. The user can choose 'Yes' to force the CPU to be 'ready'.
When this is done, the user will have the ability to examine
the target memory and registers to determine the cause of the
CPU stall. If CPU hang is caused by application and it has been
forced to be 'ready', the CPU should not be run without a reset.

  Yes  - force CPU ready (might corrupt the code)
  Disconnect - disconnect CCS so that it can be reset
  Retry  - attempt the command again

Stopping the ARM is not possible, ony disconnecting.

- What exactly does this message mean? Is it an instruction fetch or data fetch error?

- When clicking Yes, I sometimes get to a debug-able point in the code. Where should I look for the critical instruction? Directly before the current instruction? Somewhere before?

- I have the impression that some 1-5 assembly lines before the current instruction there is always an access to internal peripherals (GPIO, Timer, SPI). When I try to open a peripheral in the Registers view, I get the above message lots of times.

How is this possible?

I tried to cover the PLL and PSC controllers with a Watchpoint from the DSP (location type: range, trigger on write), but this did not trigger.

Any hint is appreciated.

Alexander

  • Alexander,

    Alexander Baehr said:
    - What exactly does this message mean? Is it an instruction fetch or data fetch error?

    The Pipeline Stall condition is explained in section 5.14 of the page below:

    http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems 

    Alexander Baehr said:
    - When clicking Yes, I sometimes get to a debug-able point in the code. Where should I look for the critical instruction? Directly before the current instruction? Somewhere before?

    Yes, as mentioned in the reference above that can happen at times.

    Alexander Baehr said:
    - I have the impression that some 1-5 assembly lines before the current instruction there is always an access to internal peripherals (GPIO, Timer, SPI). When I try to open a peripheral in the Registers view, I get the above message lots of times.

    As the reference mentions, the pipeline can be stalled if the CPU and another source are competing for the same resource (peripherals, bus, etc.). In general the CCS debug engine does not access the target device while the CPU is running just to avoid these conflicts. To allow access to data in a debug session, you can enable the option Halt the target before any debugger access, as mentioned in section 3.2 of the page below:

    http://processors.wiki.ti.com/index.php/Debug_Handbook_for_CCS 

    I don't think that ARM9 cores have real-time mode (just like some DSPs), but if this is happening while you are opening or reading registers it may well be a bug of the tool. What is the version of CCS you are using?

    Regards,

    Rafael