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.

AM5716: C66 crashes during startup around init/start of IPC without beeing able to connect to the target

Part Number: AM5716
Other Parts Discussed in Thread: SYSBIOS

Hi

We are using the AM5716 sitara processor with sysbios (V6.76.3.01)
Between the A15 and C66 core we are using IPC (V3.50.2.02) with shared memory, ShmNotify and MessageQ for data exchange.
There are two queues, one for with the A15 as host and one with the C66.

We experience a strange behavior after reset, the C66 can crash without beeing able to connect with the debugger. Changing a unrelated instruction e.g. in C66 main() can lead to a working version again...

Also re-start can work, but not always... Some versions crash with every start, some only after hundreds of starts, some not at all (> 2000 tries)...

The location where the crash happens is also different. In some versions it crashes before reaching main(), on other around IPC_attach(). This has been debugged by toggling GPIO pins.

The newer IPC version has also been tried, but not that extensively, so we are not sure if it crashes with the same patterns...

Debugging is nearly impossible, because stepping through always works and in the crash situation the debugger doesn't work any more...

Any hints / ideas?

Regards,
André

  • We still couldn't find any hint what's happening...


    We have versions that crash every time before main()! If we are able to get the debugger to connect, it is around dmTimer: Timer.c, Timer_checkFreq()

    Any hints appreciated!

    Thanks,

    André

  • We are still searching the problem!

    One more hint could be that if the application starts, there are Errors shown in ROV -> Sysbios -> Scan for Errors tab.I inspected the data structure with the memory browser and could'nt find any problem in the data...

    Does anybody know how to get the application's section map as mentioned in "INVALID address according to the application's section map"? Is this the map File?

    Thanks,

    André

    ti.sdo.ipc.GateMP
    Gate Resources
    N/A
    N/A
    Caught exception in view init code: Problem fetching remoteSystemInUseJavaException: java.lang.Exception: Target memory read failed at address: 0x40360980, length: 256 This read is at an INVALID address according to the application's section map. The application is likely either uninitialized or corrupt.
    ti.sdo.ipc.heaps.HeapMultiBufMP
    Basic
    (0xa0018110)
    N/A
    Caught exception in view init code: Error: could not access shared memory: JavaException: java.lang.Exception: Target memory read failed at address: 0x40361180, length: 272 This read is at an INVALID address according to the application's section map. The application is likely either uninitialized or corrupt.
    ti.sdo.ipc.heaps.HeapMultiBufMP
    Buffer Information
    A15IpcHeap
    N/A
    Caught exception in view init code: Error: could not access shared memory: JavaException: java.lang.Exception: Target memory read failed at address: 0x40361180, length: 272 This read is at an INVALID address according to the application's section map. The application is likely either uninitialized or corrupt.
    ti.sdo.ipc.nsremote.NameServerRemoteNotify
    Basic
    (0xa0018048)
    localRequestStatus
    Problem retrieving local request status
  • Update...

    We are still having the crash problems...

    but the ROV -> BIOS -> Scan for errors has been mostly resolved. It was a ROV problem. By adding ROV only  _start__ & _end__ defines for the whole address range the errors dissapeared, except one, which is most likely also related to ROV (unused GateMP custom proxy defined to NULL).

    Any hints to the above startup crash are highly appreciated!

    Thanks,
    André

  • Hi Andre,

    Thanks for your patience! Did you try the default IPC sample comes with SDK? If not, my suggestion is first try it out.

    Based on the random crash scenario you mentioned above it looks like some memory corruption issue. Once you execute the default samples successfully, please make sure you take the configuration (mem map, timer configs etc) from the working sample application.

    Thanks & Regards,

    Sunita.