• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 533 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.

no property named '$logError' error

Allen Lee
Genius 3770 points

Other Parts Discussed in Thread: SYSBIOS

Hi,

I am working on a DSPBIOS->SYSBIOS migration. The conversion of tcf is done with a output named 'out.cfg'.

But when building out.cfg, there comes an error like:

js: "C:/ti/bios_6_35_01_29/packages/ti/bios/SEM.xs", line 94: XDC runtime error:
ti.bios.SEM.Instance#0: no property named '$logError'

And my build command is as:

D:\Workspace\Conversion>"D:\Texas Instruments\xdctools_3_23_02_47\xs.exe" --xdcpath="C:\ti\bios_6_35_01_29\packages;D:\Texas Instruments\xdctools_3_23_02_47\packages;D:\Workspace\Conversion" xdc.tools.configuro -o "configPkg" -t "ti.targets.C674" -p "myplatform" -r "RELEASE" -c "C:\ti\ccsv5\tools\compiler\c6000_7.4.2" out.cfg

Attached is the out.cfg file and platform package. platform package is located in D:\Workspace\Conversion .

Hope to hear some useful suggestion.

Thanks.

8204.Conversion.zip

Allen

  • 0
    TI__Mastermind 37985 points

    Allen,
    that looks like a bug in the module SEM. However, you don't have to wait for that bug to be fixed. The statement that triggers the bug is one that removes a SEM instance that was just created in the statement above. You can simply delete both these statements in out.cfg:
    bios.SEM.create("sem_tsk_main");
    bios.SEM.instance("sem_tsk_main").destroy();

    The conversion tool simply does not have the capability to recognize that these two statements taken together are one NOP instruction.

  • 0 in reply to Sasha Slijepcevic
    Genius 3770 points

    Hi Sasha,

    Yes, i have done what you suggested. 

    I just confused by the 'destroy' method, since it takes effect in static meta domain where BIOS is not started yet. So if a 'destroy' is called, all actions to this instance are actually equals to a 'NOP', and also equals to all the instance related statements are not existed. While why a 'destroy' method is created... 

    Allen

  • 0 in reply to Sasha Slijepcevic
    Genius 3770 points

    Hi Sasha,

    Attached is my cfg file in application, with the same build command and platform package. It reports an build error that:

    error: ti.sysbios.family.c64p.Hwi: "C:/ti/bios_6_35_01_29/packages/ti/sysbios/family/c64p/Hwi.xs", line 295: ti.sysbios.family.c64p.Hwi.Instance#0 :

    Failed to plug: &ti_sysbios_knl_Clock_doTick__I. Hwi 14 already in use by: &TINT3_ISR.

    It seems an HWI assignment conflict occurs, but i couldn't find out where is the reason. Could you help me to figure it out? Thanks.

    2806.out.cfg

    Allen

  • 0 in reply to Allen Lee
    TI__Mastermind 37985 points

    Allen,
    one use case where you would want to have destroy() is when the code that creates and configures instances is not available in your TCF script. DSP/BIOS predefines memory object instances and some other instances, and if you don't want them the only way to get rid of them is to call destroy().
    The other usage is related to DSP/BIOS GUI configuration. When you add and configure various instances, a TCF script that keeps the state of your configuration is automatically created. If you change your mind and you don't want to keep an instance that you previously created, the TCF script generation code wasn't smart enough to delete all statements related to that instance. It would simply call destroy() on that instance.

    As for your Hwi problem, I'll have to ask someone more familiar with Hwi configuration to help.

  • 0 in reply to Sasha Slijepcevic
    TI__Mastermind 21645 points

    Hi Allen,

    C64P parts use Timer64 module which use interrupt numbers 14,15, 4 and 5 by default. If you can, I would recommend using a different interrupt number for TINT3_ISR.

    If you would still like to use interrupt number 14 for TINT3_ISR, then you would need to manually create a timer with the desired interrupt number and call the clock tick function from the timer handler (This also requires setting Clock module's tick source as USER). There is an example showing how to do this in the cdoc:

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/6_35_03_47/exports/bios_6_35_03_47/docs/cdoc/ti/sysbios/knl/Clock.html#xdoc-desc

    Best,

    Ashish