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.

OMAP-L137: ARM single step free runs.

Part Number: OMAP-L137
Other Parts Discussed in Thread: SYSBIOS,

A little history just by way of explanation.

I have been asked to make some modifications to a project based around an  OMAP-L137BPTPH.

Previously, the DSP has been used with the hardware and the ARM has just sat in reset being totally unused.

There is now a requirement to migrate some functionality to the ARM to take some load away from the DSP.


The obvious first step was to create a demonstration that the ARM is alive at he same time as the DSP.

I have created simple bare-metal DSP and ARM applications to for this. These apparently work OK.

The DSP code initialises a UART, prints a banner and starts up the ARM. When the arm is running the DSP will output a periodic message.

The ARM code performs an initialisation handshake with the DSP code using shared memory, outputs an ARM banner to the UART and then prints a periodic message at a different rate from the DSP.

All seems good at this point. This is a very bare metal demo but does show both processors to be alive and communicating.


I have integrated the ARM startup code into the customers original DSP application. The ARM is started after the system is setup and immediately before calling  to get the BIOS_start();  to get  sysbios running.

The DSP does bring the ARM out of reset.

I have created an RTSC project for the ARM so that sysbios can be used. This seems to have created as expected. The .vecs are in place and memory map looks ok.  


This is where the unexpected starts to happen.

I can see in the debugger that the boot.asm does start to execute at  _c_int00:   I can single step through the code.


I see however that as I single step the processor can jump into a ‘running’ state, by the time I manually stop it, it is executing memory that is not part of the program.  I have seen this happen at different branches.

This is the boot code provided in  C:\ti\bios_6_76_04_02\packages\ti\targets\arm\rtsarm\boot.asm  after I have removed the conditional  code that is unused.


;* FUNCTION DEF: _c_int00                                     


_c_int00: .asmfunc





        MRS     r0, cpsr

        BIC     r0, r0, #0x1F  ; CLEAR MODES

        ORR     r0, r0, #0x1F  ; SET SYSTEM MODE

        MSR     cpsr_cf, r0



        ;* INITIALIZE THE USER/SYSTEM MODE STACK                     


        LDR     sp, c_stack

        LDR     r0, c_STACK_SIZE

        ADD     sp, sp, r0





       BIC     sp, sp, #0x07  ; Clear upper 3 bits for 64-bit alignment.





        LDR     r0, c_mf_sp

        STR     sp, [r0]


       LDR    r0, c_reset

       CMP    r0, #0

       BEQ    _no_reset_

       MOV    lr, pc

       BX     r0                ; This typically causes the single step to free run and by the time I can stop it, memory outside the program scope is being executed.





        ;* Perform all the required initilizations:

        ;*   - Process BINIT Table

        ;*   - Perform C auto initialization

        ;*   - Call global constructors


        BL      __TI_auto_init



       ;* CALL APPLICATION                                    


        BL      ARGS_MAIN_RTN





        BL      EXIT_RTN





L1:     B    L1




 The hilighted code above is where I typically see the issue but I have seen it happen a branch or two later. 

I understand that CCS is not the latest available. This is not my choice but I am trying an update on another PC.

I am using  

Code Composer Studio    Version: 

Hardware is                        OMAP-L137BPTPH

Debug via                            XDS100v3+ Rev E   (

I see issues with the IDE in that registers are not always updated on the display.

I see the ARM jumping out of 'single step' into a running state when I step at the branch.

The DSP is sitting waiting to see life from the ARM before it starts sysbios.

The ARM is not getting into application code because it always fails in the boot code.

The bare metal demo has a similar but different boot.asm. It always works on the same hardware.


Does anyone have any idea what may be causing this issue ?

If anyone has seen this before I would be very interested to know the cause.

Have I missed something obvious ?

Is it illegal to have sysbios on both the DSP and the ARM ?

Does anyone else see artefacts from the IDE such as registers not updated on the display ?