• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 494 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.

Original question:

IWR1843BOOST: Traffic Monitoring Demo Crash

IWR6843ISK-ODS: 3D People Counting Demo Crash and USB issues

Mary Raullette Solomo
Intellectual 600 points
Part Number: IWR6843ISK-ODS
Other Parts Discussed in Thread: IWR6843, IWR1843BOOST

Hi,

We are encountering two kinds of issue with the IW6843-ISKODS 3D People Counting Demo:

1. The demo cannot run for more than 2 hours. After a while, it will crash and be resolved when we power down. 

2. The demo cannot start even after sending the CFG commands successfully. The sensorStart command seems to break the USB connection and even powering down the device multiple times and reconnecting the USB don't solve the problem and we cannot start it for a while. When we are able to start again, we cannot figure out what made it work.

Do you have any idea what may have cause these 2 issues? We are encountering the same issues with IWR1846 Traffic Monitoring Demo. Both are ES2.0 devices and using the latest toolbox.

Thanks

  • 0
    TI__Mastermind 28055 points

    Hi Mary,

    I want to confirm you are seeing this issue on two boards:

    1. IWR6843 ISK-ODS
    2. IWR1843BOOST

    If this is the case, I am suspecting that there may be a setup issue. Are you using a 5v3A power supply? Wrong power supply can cause issues like the above.

    Regards,

    Justin

  • 0 in reply to Justin Curewitz
    Intellectual 600 points

    We are using correct power supply.

    I tried running the device through the debugger (3D people counting demo CCS Project) to catch the failure but with the following lines of code modified:

    objectdetectioninternal.h into:

    #define DPC_Objdet_Assert(handle, expression)

    //#define DPC_Objdet_Assert(handle, expression) { \
    // _DPC_Objdet_Assert(handle, expression, \
    // __FILE__, __LINE__); \
    // DebugP_assert(expression); \
    // }

    The reason being, I've found that DPC_Object_Assert is causing crash issue for 1843 (there is another thread for this one) and figured this might also be the one causing the crash for 6843 since they have similar codes. 

    It's the lines:

    objectdetection.c

    1986: DPC_Objdet_Assert(objDetObj->dpmHandle, (objDetObj->interSubFrameProcToken == 0));

    and

    objdetrangehwa.c

    646:  DPC_Objdet_Assert(objDetObj->dpmHandle, (objDetObj->interSubFrameProcToken == 0));

    I also used the pre-compiled gui. The GUI crashed at Frame: 32955 (around 30mins of running) but it seems like the device cores are still running as I'm seeing on the debugger and realterm still continue to stream out the data on the Data Port (though I didn't verify if the data it's outputting is valid at this point, but at least I know it still outputting something).

    The device continues to run for a few more hours without "crashing", meaning the realterm continues to streamout data.

    Questions:

    1. How is skipping the DPC_Object_Assert line affect the othe features of the FW? 

    2. Do you think it's the GUI that crash in this scenario?

    3. Are there any other assert lines in the code that might be causing the FW to hang up at some point in time? We would prefer to disable them and just let the device run.

    Thanks for your help.

  • 0 in reply to Mary Raullette Solomo
    Intellectual 600 points
    I tried removing my changes above and run the ccs debugger again. Same thing, the TI GUI and the python serial reader that we wrote crashes after running for 20min onwards, but data continues to be outputted in the port when we switch to realterm after the crash.This time though we’ve verified that it’s still Outputting valid data. Restarting the python reader (without resetting the device and re-sending the cfg file) will still able to read data successfully. And the device/debugger seems to continuously run all through out. Why would the serial reader / TI GUI “breaks” the serial connection and appear to hangup when data continues to be outputted on the port? I also noticed that the baud rate is 921600*2. Is it okay to lower it down to 921600 for 3d people counting? (Note that we’ve disabled the TRACKERPROC_EN since we don’t need the objects for this case). Thanks.
  • 0 in reply to Mary Raullette Solomo
    TI__Mastermind 28055 points

    Hi Mary,

    Questions from the first post:

    1. DPC_OBJECT_ASSERT - these asserts are typically used in the software to stop execution if any process takes too long. You can safely comment these without negatively effecting the performance.
    2. It looks like the GUI is crashing - typically as long as the device is outputting data, the device is fine.
    3. There are many instances of "Pcount3DDemo_debugAssert()".  You can track these all down with some sort of Grep function (I use grepWin for windows 10).  Removing these will not cause issues.

    Questions from the second post:

    Why does the serial connection fail in the gui? - I have to investigate further, if this is a blocking issue for you, you can also debug this if you run the gui from command line (requires python 3.6 64 bit installation).

    Baud Rate - initially, we set baud rate to 921600*2 to ensure there would be no crashes due to UART taking too long to output data. However, I have tested with 921600, and this is fast enough to output with 50 ms frame periods. You can lower the baud rate.

    Regards,

    Justin

  • 0 in reply to Justin Curewitz
    Intellectual 600 points

    Hi Justin,

    Thanks for your help.

    Just for additional info, the reader/gui hangs up (breaks the serial connection) most of the time at around frame 68k (almost 2 hrs of running). So, you may try to run up to this point when you investigate.

    I am running the test with the lowered baud rate to 921600 and will update the result.

  • 0 in reply to Mary Raullette Solomo
    Intellectual 600 points

    Serial break still occurs at 921600 baud rate.