• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 983 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM335x debugger - LDR loads wrong value

Vasili Galka
Expert 2690 points

Hi,

I'm using a Blackhawk XDS560v2 to debug software on a AM335x based board. I'm observing the following very strange behaviour:

Reproduction scenario

  1. Connect the XDS560v2 to the setup.
  2. Power on XDS560v2.
  3. Power on the setup.
  4. Run CCS, launch our debug configuration (using LAN).
  5. Connect to Cortex-A8 target.
  6. Click CPU reset (SW) button.
  7. Load Program from COFF file.
  8. Put break-point on LDR instruction.
  9. Click Resume button.
  10. The debugger stops on the break-point.
  11. Click Assembly step into button.

Results

See the screen shot:

As the LDR instruction loads data from the 0x8007E410 address, and we see that it contains 0x8002DBB0, we would expect that R0 contains this value. However, we see that R0 contains some other value.

Additional notes

  1. This reproduces with both CCS 6.0.0.190 and CCS 6.0.1.40.
  2. This is not due to a single faulty AM335x chip piece. I reproduced it on two different boards (with different AM335x chip revisions).
  3. Most of the times the same software image runs fine if no break-point is set. However, sometimes it does fail to run (and pausing shows attempts to run on non-existing 0xExxxxxxx addresses). That's how I found this issue in the first place. I started debugging why sometimes the software does not run and after putting breakpoints found this.


What can be the reason for this strange behaviour? Am I missing something?

Best regards,
Vasili

  • 0
    TI__Guru**** 173310 points

    Vasili,

    It looks like you are debugging the BIOS boot code and you are building with GNU rather than TI tools. If so, the folks in the TI-RTOS forum might be able to help better here. However, I find it a bit odd that it would only fail in some cases and not every time it runs. Does that mean that in some cases when you step through that instruction, the expected value is loaded into R0 and at other times it is not?

    I wil move this thread to the TI-RTOS forum to see what the folks there have to say.

  • 0 in reply to AartiG
    TI__Mastermind 21645 points

    Hi Vasili,

    The behavior you are seeing is indeed strange. Can you open "Tools"->"ARM Advanced Features" window and check if the MMU and/or any of the caches are enabled ? If the cache is enabled, it is possible that the "ldr" instruction is fetching from the cache and not RAM. I don't expect the cache to be enabled though as it is very early in the boot process, but it does not hurt to check.

    Also, can you share your executable ?

    Best,

    Ashish

  • 0 in reply to Ashish Kapania
    Expert 2690 points

    Hi Aarti, Ashish,

    1. I think I've noticed some times when it stepped fine over this instruction in the past. However, I fail to reproduce it now, it fails consistently when I try it.

    2. Yes, the MMU and caches are off. That was my first guess and I checked it before contacting you.

    3. I sent the executable by private conversation to Aarti. Hope you can reproduce it too. If not, please guide me how we can debug it together on my end.

    Best regards,
    Vasili

  • 0 in reply to Vasili Galka
    TI__Mastermind 21645 points

    Hi Vasili,

    Aarti shared your outfile with me. I dont have an AM335x board at the moment so could not run the app yet. I will try to borrow one tomorrow and run the app to see if I can repro the problem.

    Best,

    Ashish 

  • 0 in reply to Ashish Kapania
    TI__Mastermind 21645 points

    Hi Vasili,

    Both Aarti and I were able to repro the bad LDR load on adding a breakpoint in our setups. This looks like a emulation bug. I have filed a bug report (SDSCM00051052) for this. I only see the problem when using SW breakpoints (default bkpt type). The problem does not seem to happen with HW breakpoints.

    Whenever I do a free run also, I dont see any issues. I am wondering if the corruption you occasionally see with a free run is related to something else. Do you load applications back to back ? If yes, then you need to take care of 2 things:

     - First, you should ensure that you do a CPU reset (to disable the cache and MMU) followed by an explicit cache and tlb flush from the "Tools" -> "ARM advanced features" window in CCS, before loading another application.

     - Second, you should always do a reload (if loading the same app again) instead of doing a restart. This is because GNU apps do not do a runtime init of data section (you can change the load and run address of data section to force that) therefore the data section needs to be loaded each time the app is run.

    Best,

    Ashish

  • 0 in reply to Ashish Kapania
    TI__Mastermind 21645 points

    Hi Vasili,

    After studying this a little more here is what I found. The value that you see the LDR instruction sometimes incorrectly returns (i.e. 0xE1200070) is the opcode for the "bkpt" assembly instruction. When using software breakpoints, this instruction is inserted in the code and is suppose to be replaced with the original code by the debugger once the breakpoint is hit. It looks like that is not always happening.

    Best,

    Ashish

  • 0 in reply to Ashish Kapania
    Expert 2690 points

    Hi Ashish,

    I'm glad that you could reproduce it and understand how to fix. Looking forward for the next version :-)

    Many thanks!

    Best,
    Vasili

  • 0 in reply to Vasili Galka
    TI__Mastermind 21645 points

    Hi Vasili,

    This is a bug in the emulation driver so you should get the fix through an updated emulation driver (TI Emulators) in CCS. I am not sure when the fix (updated driver) will be available as I am in a different team. Here's a link to the bug (username and password is readonly):

    https://cqweb.ext.ti.com/cqweb/restapi/SDO-Web/SDOWP/RECORD/SDSCM00051052?format=HTML&noframes=true&recordType=IncidentReport

    Best,

    Ashish