• State Resolved
  • Replies 7 replies
  • Subscribers 32 subscribers
  • Views 129 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

IWR1843BOOST: Understanding mmWave SDK exceptions

ML
Prodigy 10 points
Part Number: IWR1843BOOST
Other Parts Discussed in Thread: SYSBIOS

Tool/software:

Could someone please explain how to figure out what is module 36 in this kind of exception message:

Cortex_R4_0: [Sun Jan 12 11:10:14] {module#36}: line 444: error {id:0xa0000, args:[0x8005018, 0x0]}
Cortex_R4_0: [Sun Jan 12 11:10:15] xdc.runtime.Error.raise: terminating execution

I am using CCS Theia v1.5.1.3 and mmWave SDK v3.6.2. It comes with source code of the drivers, datapath modules, etc. and if I'm lucky I guess I can see what's on line 444. But first I need to find module. I have checked map file, project files, SDK user guide.

PS.
Call stack doesn't show the origin.

  • 0
    TI__Genius 14030 points

    Hello.

    Have you connected and started running the DSP prior to starting the R4 core?  Can you provide the steps you are taking to create this issue?

    Sincerely,

    Santosh

  • 0 in reply to Santosh Krishnan
    Prodigy 10 points

    Hello Santosh,

    I am interested in finding the source of module numbers so I can handle the issues on my own. I get them quite often during development and it is sometimes time consuming to find the cause.

    If those numbers are assigned during library build then maybe you could generate some mapping file and ship with SDK?

  • 0 in reply to ML
    TI__Genius 14030 points

    Hello.

    Let me look into this and I will provide an update by the end of the day Thursday.

    Sincerely,

    Santosh

  • 0 in reply to Santosh Krishnan
    TI__Genius 14030 points

    Hello.

    According to this e2e, the entire message indicates that the code was not properly loaded during debug.  I don't think the error is related to that module per say, but I would double check that you are properly loading your code when trying to debug.  Please make sure to follow all the steps from the debugging guide on the radar toolbox.

    Sincerely,

    Santosh

  • 0 in reply to Santosh Krishnan
    Prodigy 10 points

    Hello Santosh,

    My wish is to understand how to interpret such messages, not to come and create forum post every time I see one of these exceptions. Clearly you at TI know that because how else could you answer what's the issue. Is it really so hard to tie the module number with file name or something more verbose?

  • 0 in reply to ML
    TI__Genius 14030 points

    Hello.

    I don't think the module number ties to any file within the mmwave sdk itself; I believe it is more related to the SYSBIOS or the core, which makes it difficult to tie it to a specific file.  If you could provide the scenarios that are causing such errors I might be able to help identify if there is something in your debug procedure that is causing the error or if it is an issue with the IDE or your software.

    Sincerely,

    Santosh

  • 0 in reply to Santosh Krishnan
    Prodigy 10 points

    Hello,

    SYSBIOS was a useful hint and i started looking at TI BIOS. I found this documentation:
    https://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/sysbios/6_52_00_12/exports/bios_6_52_00_12/docs/cdoc/xdc/runtime/Types.html#.Module.Id

    And then realized that modules have function called MODULE_Module_id to get the id value. Can check them at runtime for example, but it's not very convenient. So I digged on and found these ids use public constants that are declared by this generated file in build output directory:

    configPkg\package\cfg\mmw_mss_per4ft.c

    And there I searched for 36 and found it is set in function ti_sysbios_knl_Task_Handle__label__S

    That made me conclude module 36 is Task module. I found Task.c file here:
    C:\ti\bios_6_73_01_01\packages\ti\sysbios\knl\Task.c
    And what I saw on line 444 is:

     Error_raise(NULL, Task_E_stackOverflow, oldTask, 0);
    Which means my task (defined by arg) had stack overflow.
    It sounds plausible because I got this exception after firmware had run for a while.
    Maybe there is a shorter way to figure it out, dunno. It also appears that BIOS handles module names so maybe it is possible to improve the exception handler and print out module names.
    Anyway, please TI do something about these exception messages. Right now it reminds me old days of Windows when all you got for error was some magic number.