when debugger starts, SYS/BIOS and CCS enter dead loops instead of running to main

Eugene,

Have you tried *not* using auto run to main()?  And if you connect the debugger, where is the CPU?  I’m trying to clarify if this might be a problem when running to main(), versus maybe a debugger configuration issue.

And this is the A8 you’re trying to run the SYS/BIOS examples on, right?  Not the C64x+?

Thanks,
Scott

Scott,

Thank you for quick reply.

• Have you tried *not* using auto run to main()?

Yes, there is no difference in debugger behavior. After a reset, non-SYS/BIOS examples hang in a dead loop (although at 0x00014084 instead of 0x0001408C), but after I press 'restart' the examples run to main and stop there anyway(!?). SYS/BIOS examples never reach main, with 'run to main' checked or unchecked.

Probably noteworthy: once 'restart' is pressed, all non-SYS/BIOS examples stop at main. Even if I reload same or even different non-SYS/BIOS example, or even exit and restart CCS,- all non-SYS/BIOS examples run to main properly until a reset. If I reset and then start the debugger, they hang in a dead loop until 'restart' is pressed.

• And if you connect the debugger, where is the CPU?

I am not sure I understand the question. When the debugger is started/connected, Cortex_A8 core is connected and running, C64x+ core is disconnected. Is that what you mean to ask?

• I’m trying to clarify if this might be a problem when running to main(), versus maybe a debugger configuration issue.

I have not been able to get SYS/BIOS examples to reach main at all.

• And this is the A8 you’re trying to run the SYS/BIOS examples on, right? Not the C64x+?

Yes, baby steps first. I am trying to run SYS/BIOS examples on Cortex A8 core.

Thank you,

Eugene

I believe it is normal and expected to see the "no source available for 0x____" messages.  I have seen this in all of my SYS/BIOS programs, and they all run as expected (and start at main to get to my call of BIOS_start() ).

By default, SYS/BIOS enables the A8 cache and MMU during startup code prior to main().

When you hit the CCS reset icon, this does NOT disable the cache nor the MMU.

If you subsequently load an application while the cache is enabled, the code is not actually placed in external memory by the CCS loader. Instead, it is loaded into the L1 and L2 caches.

There is no way for this loading condition to be adequately addressed by the startup code, Neither disabling the cache, invalidating the cache, nor flushing the cache will guarantee that the program will execute properly once the system is in this state.

We have found that you must manually disable the MMU and Caches using the "ARM Advanced Features" tool within the CCS debugger between each program load step in order to expected behavior.

Alan

I have observed (after reading your reply) the enabling of the cache during start-up, the MMU appeared disabled though.

However, my problem occurs before CCS reset (or any other user action) is used. The application simply does not run to main() and hangs.

Intuitively, I feel that the cache issue you describe could be relevant, because I had identical problem (not running to main) in non SYSBIOS applications and got that issue 'solved' by adding "GEL_Reset()" inside "OnTargetConnect()" in GEL file. I use the same "fixed" GEL file with my SYSBIOS application but it still does not run to main(). So it is likely that SYSBIOS (or its start-up code) is the culprit.

What are your thoughts?

Eugene

Same problem here,

Working on the ARM9 side of the OMAP L138.

Is this problem solved?

Yoel

I don't think so.

The unfortunate situation is that we get many "answers" that do not come close to solving the problem. I have a feeling that people post them just to rack up points for "answering".

If anyone (especially TI employes with mega-points under the belt) thinks that I am wrong about this then please, please prove me wrong. I would be delighted to be proven wrong about this.

Eugene

Yoel,

What version of CCS are you using? Are you using SYS/BIOS on the ARM9? If so, what version? Can you also please state the exact the scenario and problem you are seeing? I know you said "Same problem here" but I want to make sure all the information is present.

Todd

Yes Yoel, go ahead and tell us CCS version and all the other particulars of your issue. Because even though the very first post in this thread does that in detail, we need to hear it again or from you. And so the cycle continues...

This is exactly what I am talking about.

But look on the bright side, we all got hefty points added for our posts. I am curious to see if anything else will come of this.

Eugene

Hey Todd and Eugene,

Here is my setup (even tough I tried several setups but the problem stays the same).

XDC Tools: 3.24.7.73
SYSBIOS: 6.35.4.50
CCS  Version: 5.3.0.00090 

This is my story:

I connect both targets (ARM9 and DSP) and load the program to both cores (SYSBIOS on both no IPC).
The debugger starts at main on the ARM side but when I call BIOS_start() it halts.

When I step in the assembly code, I can see that it is suppose to jump to an invalid place in memory (for example, if the code is at 0x80004000, it jumps to 0x800C4000 for some reason) and then I see this message: "Memory map prevented reading of target memory".

If I stay connected, reset the target and reload the same project (restart doesn't work at this point) I can run the program (tasks start running), at this point I can see the same in the assembly (the 0x000C add-on to the addres) but it works still.

Important to mention that this programs ran perfectly up until recently but I don't know what changed in the last two weeks.

From several tests I made, If I don't connect the DSP core, this problem doesn't happen. The DSP doesn't overrides the ARM code section or stack, memory map for both cores attached

8306.arm_map.txt

7725.dsp_map.txt

I don't use SYSBIOS functions or resources before calling BIOS_start.

The ROV tells me it can't read memory 0x0 and there is a problem with the SWI scheduler, nothing more (I tried removing all the SWI's with no success).

I tried moving all the code and stack to DDR, no success.

Tried reducing task and swi number of priorities to 4, no success, attached, cfg file:
3487.arm.cfg

Help would be much appreciated,

I hope you can help eugene as well, I know how frustrating it can be wrestling with the embedded platform.

Thanks,

Yoel

Yoel,

Thanks for the information. I'm tracking down that board try to reproduce your issue. I should have the board tomorrow. Can you attach the gel files that you are using?

Todd

Arm Gel file:

2465.OMAPL138_ARM_372MHz.gel

Dsp Gel file:

8400.OMAPL138_DSP_372MHz.gel

Yoel,

I have a board now, but cannot reproduce what you are seeing. Do you any example code you could share that reproduces the problem (along with the exact steps...e.g. 1. Connect to Arm, 2. Load Arm, etc.). If the code cannot be shared on the forum, you can friend me and give it to me directly.

You said it was working a couple weeks ago. Did you change any versions, gel files, etc?

Todd

Hi Todd,

I made 2 stub projects that have the same problem, attached (I hope, don't get along with the new forum changes).

1. Connect to ARM.
2. Connect to DSP
3. Load ARM
4. Load DSP
5. Run ARM
6. Run DSP (not necessary, the problem occurs before).

This happens only on first connection, if I try to run the program, and it gets stuck and then I reset and Load the program again, it will run.

Attached is also my platform package from the XDC tools folder.

Thanks,
Yoel

5518.packages.zip

8132.dsp.zip0363.arm.zip

Update:

It seems that I am working with a different SOM now, instead of LogicPD 1602AHCR I work with LogicPD 1502QHCR.
The difference between them is the DDR, 64MB instead of 128MB in the old one, maybe this could be the problem?
Maybe the GEL file needs to be altered?

Yoel

Eugene Varshavsky said:

Intuitively, I feel that the cache issue you describe could be relevant, because I had identical problem (not running to main) in non SYSBIOS applications and got that issue 'solved' by adding "GEL_Reset()" inside "OnTargetConnect()" in GEL file. I use the same "fixed" GEL file with my SYSBIOS application but it still does not run to main(). So it is likely that SYSBIOS (or its start-up code) is the culprit.