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.

C6678 Loop Buffer Exception while debugging

Other Parts Discussed in Thread: SYSBIOS

Hi,

I think there exists a problem with certain SPLOOP code, which causes a 'Loop buffer exception' and 'Missed stall exception' when CCS tries to access the target. I already noticed this problem in the past with different optimized loops. I could avoid the problem by disabling SPLOOP for the affected files. But now I'm using a IMGLIB function which is causing the same problem (IMG_sobel_3x3_8()).

I'm not sure if this is the right forum. It could be a device isssue, a CCS / Emulation problem or a compiler bug. First, I posted this question in the Keystone Multicore Forum, but I'm not getting any answer there:
https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/445013

Here is a small test program which can be used to reproduce the problem on the 6678 EVM:
ExceptionTest.zip

I'm using the following components:

  • TMDXEVM6678L EVM
  • CCS 5.5
  • XDCtools 3.25.3.72
  • SYS/BIOS 6.35.4.50
  • IMGLIB C66xx 3.1.1.0
  • Emulator SD XDS560v2 LC Traveler or SD XDS200

After the program is started, the exception can be triggered by accessing the target while it's running. For example by showing registers in the Register window or by entering an address in the memory window.

There also is an unresolved post which seems to be about the same issue on a C674x device:
https://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/280988

Thanks,
Ralf

  • Ralf,

    Thanks for sending the details and the test case. I was able to reproduce the exception, which also happens if I halt the code, do some Assembly single Steps and re-run it (check the attached clip) or even inspect a global variable on the Expressions view.

    Your original description indicates the Debugger is influencing the runtime behavior, but with the Assembly steps I am not so sure anymore (the code should have executed without problems).  

    One workaround I found was to enable Real-Time Mode (check the attached clip). Just be sure to disable it before halting the core.

    Thus, just like you, I am unsure where this issue is being originated but I will ask around.

    Regards,

    Rafael

  • Hi Rafael,

    thank you for analyzing this problem. Using Real-Time Mode seems to work. But it's very annoying to turn it off and on when halting a core or when loading a program, especially while debugging 8 cores.

    Thanks,
    Ralf

  • Hi,

    I did some PC trace recordings and there always seems to be a pipeline stall of about 50 cycles just before the exception occurs:

    Maybe someone can use this information to analyze the problem.

    Ralf

  • Ralf,

    Thanks for sending the additional information. I am still a bit backed up with other stuff and couldn't do a deeper analysis yet - I will do this today.

    The trace confirms the stall is occurring and not a glitch on the running RTOS.

    Regarding the Real-time mode - yes I agree it is a pain but at least gets you going for now.

    Cheers,
    Rafael
  • Hi Rafael,

    The problem appeared in an example program we created for our customers. We don't need a solution immediately.

    But I think it's important to find the root cause and hopefully be able to fix it. These kind of problems only lead to frustration for developers.

    Thanks,
    Ralf

  • Hi Rafael,

    since there is no progress on this issue, do you know if it's possible to disable these exceptions or to install a dummy exception handler?

    Thanks,
    Ralf

  • I found a way to disable Exceptions in SYS/BIOS:

    var Hwi = xdc.useModule('ti.sysbios.family.c64p.Hwi');
    Hwi.enableException = false;

    Ralf

  • Hi,

    Is there any update on this issue?

    Thanks,
    Ralf
  • Hi,

    is there something I can do to get support on this issue?

    Thanks,
    Ralf
  • Ralf,

    I am sorry to have completely missed the mark on this thread. Since your reply yesterday I have pulled the testcase again and tested it here with different component versions and I am trying to pinpoint the one that causes the issue.

    So far I have built a new executable that does not fail in any scenario (CCv5.5 and CCSv6.2) and uses the following components:

    XDCtools 3.32.1.22_core

    SYS/BIOS 6.46.0.23

    IMGLIB C66xx 3.2.0.1

    This lead me to conclude the CCS and TI Emupack components are irrelevant, given the original executable also fails in the newest CCSv6.2 with the latest Emupack.

    I will mix and match the components and verify which one is the culprit for this issue. If you would like to play along, please check attached the project with the updated components (it requires CCSv6.2 and all the components installed under C:\ti). 

    I will get back to you with my conclusions. 

    I apologize for the inconvenience,

    Rafael

    Exception_test.zip

  • Ralf,

    I was able to pinpoint the component that is faulty: the IMGLIB. I modified my CCSv5.5 project (that uses all the original components you mentioned) and switched this library in the project options - the error does not happen anymore. 

    I attach my project that has two build configurations: one for each IMGLIB version. To switch between them, simply right click on the project and select Build Configurations --> Set Active. 

    Please feel free to give this a try.

    As for why the code was thrown off when accessing the target - I can only suspect that the IMG_sobel_3x3_8() function of the original version was not entirely safe while executing its main loop, thus the debug access disrupted its normal execution.  Unfortunately I am not well versed in its internals and perhaps this was hand-optimized assembly..

    Hope this helps,

    Rafael

    exceptionTest.zip

  • Thanks a lot Rafael, I will try it.

    Ralf

  • Hi Rafael,

    I can confirm that the exception doesn't happen with the new IMGLIB. Looking at the assembly code, there are some small differences. The new library seems to use a different compiler version.

    But unfortunately, we still have other code which is affected by the same problem, even after switching to a recent compiler.

    I attached a project with some example code. The project doesn't use the IMGLIB. I tested the program using CG Tools 7.4.4, 7.4.14 and 7.4.20 all resulting in an exception.

    Thanks,
    Ralf

    0825.exceptionTest.zip