• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 2109 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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/TMDXRM57LHDK: Stuck at prefetchEntry - How to Debug

Lars Jagodzinski
Prodigy 70 points
Part Number: TMDXRM57LHDK

Tool/software: Code Composer Studio

Hello,

I am developing an application that uses the lwIP library to create two servers, a "Data" and a "Config" Server. The Data server sends sensor data, received using dma, every 100ms. The Config server sends the sensor configuration, read out once at the beginning, every 1000ms.

Now, at some seemingly random* point during execution, the Config Server ignores its 1000ms timing and sends every time sys_check_timeouts() is called. After a short time (few ms) the app stops. When suspending it in the CCS Debug View I can see that it hangs at the line b   prefetchEntry in the HL_sys_intvecs.asm File. Up to the point where the app stops it works as intended.

I would greatly appreciate advice as to how to debug this scenario.

* I have observed this behavior after a few seconds, as well as after half an hour. 

Regards,

Lars

  • 0
    TI__Guru**** 186256 points
    Hello Lar,

    1. write a ISR for prefetch, the ISR may only contains a while loop
    2. add a breakpoint at this while()
    3. When the error occurs, it runs to the breakpoint.
    4. Open "registers" window
    5. under CP15, you will find the "instruction fault address" and "instruction fault status"
  • 0 in reply to QJ Wang
    Prodigy 70 points

    Hello and thanks for the reply. 

    I am not sure I know how to write a ISR for prefetch. Could you provide a minimal example or guide that gives further instructions? I apologize for any inconvenience, but as this my first project I am not that experienced yet.

    Regards,

    Lars

  • 0 in reply to QJ Wang
    Prodigy 70 points

    Can I take the abscence of an answer as a "No"?

  • 0 in reply to Lars Jagodzinski
    TI__Guru 59540 points

    Hello Lars,

    QJ has been away from the office for a few days and unable to respond. If you already are reaching the b prefetchentry location in the ISR vector table, I think you are already at a point where it has reached the prefetch vector and is looping on itself. If you halt operation at this point, you should be able to perform the CP15 check that QJ references. Also, have a look at the other CPU registers such as the LR register which will show the return address and give you some idea where the issue occurred.

  • 0 in reply to Chuck Davenport
    Prodigy 70 points
    Hello Chuck,

    thanks for the quick reply. I got the following Addresses out of the Registers:
    CP15_INSTRUCTION_FAULT_ADDRESS: 0x20202020
    CP15_INSTRUCTION_FAULT_STATUS: 0x00000000
    LR: 0x20202024

    Looking at those Addresses in the Disassembly View only gave me "???? Memory map prevented reading 0x20201D78 [code=0x20000]"

    I hope this is enough Information to give further Assistance. If not I'll gladly try to collect it.

    Best Regards,
    Lars
  • 0 in reply to Lars Jagodzinski
    TI__Guru 59540 points
    Lars,

    This generally means that your code is branching to this address or accessing this address by either something that is uninitialized or corrupted. This is more tricky to track down. I don't have a real great way to track these types of issues down except brute force by putting break points in your code, execute to the break point, if no fault, put break point further into the code and repeat until you narrow down where the fault is happening. You could also put markers in your code (toggle GPIO, send UART messages, using a global to set flags according to which sections of code have executed, etc) to check execution path and where the error might be occurring. Trace capability is also nice to have in these cases, but can be tricky to set up and expensive tools to buy.

    What is the last point that the code executed without this error? i.e., what was the last change that was made? This appears to be a read from an ECC bank where the 8-bit data is used to fill the entire word but the LR value indicates the next address as the return address. Is there anywhere in you code that this value makes since or recent changes around an ECC diagnostic test where you might be reading the ECC values? Other possibility would be something related to FEE operations where ECC is calculated as part of the programming operation.
  • 0 in reply to Chuck Davenport
    Prodigy 70 points

    Hey Chuck,

    thanks for the advice. This is probably gonna take me some time to narrow down. I am not exactly sure which code is executed last without error yet.

    What I have observed however, is that this only happens when both Servers have a connection to a client. If only one has a connection the program runs without error (as far as I could see).