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
;*------------------------------------------------------
;* SET TO SYSTEM MODE
;*------------------------------------------------------
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
;*-----------------------------------------------------
;* ALIGN THE STACK TO 64-BITS IF EABI.
;*-----------------------------------------------------
BIC sp, sp, #0x07 ; Clear upper 3 bits for 64-bit alignment.
;*-----------------------------------------------------
;* SAVE CURRENT STACK POINTER FOR SDP ANALYSIS
;*-----------------------------------------------------
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.
_no_reset_:
;*------------------------------------------------------
;* 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
;*------------------------------------------------------
;* IF APPLICATION DIDN'T CALL EXIT, CALL EXIT()
;*------------------------------------------------------
BL EXIT_RTN
;*------------------------------------------------------
;* DONE, LOOP FOREVER
;*------------------------------------------------------
L1: B L1
.endasmfunc
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: 9.3.0.00012
Hardware is OMAP-L137BPTPH
Debug via XDS100v3+ Rev E (olimex.com)
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.
Questions...
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 ?
