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.

CCS/CC1352P: Sysconfig blows up on RF Protocol change?

Part Number: CC1352P
Other Parts Discussed in Thread: SYSCONFIG, SYSBIOS,

Tool/software: Code Composer Studio

Champs,

So I have been working with one of the BLE+WSN (sub 1GHz) projects in the latest CC1352 SDK (3.30.00.03) but have run into a problem.  Everything out of the box worked fine, and I was even able to make small modifictions to the SysConfig using the tool in CCS; but on a whim I wanted to test if I could possibly use the 200Kbps RF protocol instead of the stock 50Kbps.  When I selected this option in SysConfig and saved; the next build exploded:

"

making ../src/sysbios/rom_sysbios.aem4f ...
Building file: "../dmm_wsnnode_ble_sp.syscfg"
Invoking: SysConfig
"C:/ti/ccs920/ccs/utils/sysconfig/sysconfig_cli.bat" -b "/ti/boards/.meta/CC1352P_2_LAUNCHXL" -s "C:/ti/simplelink_cc13x2_26x2_sdk_3_30_00_03/.metadata/product.json" -o "syscfg" "../dmm_wsnnode_ble_sp.syscfg"
gmake[1]: Nothing to be done for 'all'.
Running script...
subdir_rules.mk:33: recipe for target 'build-387547023-inproc' failed
Error: cannot set 'EasyLink_Phy_Custom' to false
at Object.set (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:26:268330)
at eval (C:\Users\a0322091\workspace_v9_2\CC1352Sandbox\dmm_wsnnode_ble_sp_app_CC1352P_2_LAUNCHXL_tirtos_ccs_syscfg\dmm_wsnnode_ble_sp.syscfg:184:30)
at n.each (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:26:560767)
at Wt (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:9:5239)
at Function.Ga (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:9:40286)
at Object.t.runScript (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:26:560651)
at <anonymous>
Caused by: TypeError: Cannot read property 'name' of undefined
at Object.onPhyConfigChange [as onChange] (C:\ti\simplelink_cc13x2_26x2_sdk_3_30_00_03\source\ti\easylink\.meta\rf_config\easylink_rf_config.syscfg.js:188:27)
at e.def.onChange.C.guardCallbackAccess (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:33:58262)
at Object.t.guardCallbackAccess (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:9:72786)
at e.nameMemberMgr.l.ConfigurableMgr.inOnChange.runOnChanged (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:33:58232)
at l.runOnChanged (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:33:62237)
at y.disableScriptingForCallback (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:33:58194)
at Object.s [as disableScriptingForCallback] (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:33:27480)
at l.onMemberChanged (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:33:58061)
at validateAssignment.isEqual.o.internalBoundary (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:26:41187)
at Object.t.internalBoundary (C:\ti\ccs920\ccs\utils\sysconfig\dist\cli.js:26:543717)
gmake[1]: *** [build-387547023-inproc] Error 1
gmake: *** [build-387547023] Error 2
subdir_rules.mk:30: recipe for target 'build-387547023' failed
gmake: Target 'all' not remade because of errors."

and what's worse, now I can't open SysConfig to change it back; I get this screen of death when I try to reopen SysConfig.

I'm dead in the water- help!!!!

  • Hi Radar,

    Did you try clicking "OK" at the bottom left corner of the window? That should allow you to regain access to SysConfig and change it back for now. 

    Thanks,

    Alexis

  • No, that just welcomes you with this window; at which point if you reload the thing it will put you back into the circle of doom.

  • Hi Dave, 

    I'm having some trouble reproducing the issue using:

    • CCS v9.2.0.00013
    • simplelink_cc13x2_26x2_sdk_3_30_00_03
    • dmm_wsnnode_ble_sp_app_CC1352P_2_LAUNCHXL_tirtos_ccs_syscfg example

    Here are the steps I take to try to reproduce the issue:

    1. Import project
    2. Build
    3. Open .syscfg file
    4. Navigate to EasyLink--> Radio
    5. Select the 200kbps, 2-GFSK PHY
    6. Deselect the Custom PHY
    7. Save and build

    Can you look over what I've done and let me know how it differs from how you uncovered the problem? Also, can you attach the corrupted .syscfg file for review?

    Best regards, 

    Caleb

  • Well, your method seems fine, in fact it's what I did.  So maybe it's just the result...mine's just corrupted.  I got lucky in that I had imported the project so the virgin copy is still part of the SDK on my HDD; so I just made a new workspace and started over.  For reference, I did get it to work if i left the 50kbps option in there as well but have it default to the 200kbps; haven't had the guts to try deselcting the custom PHY piece yet but I may give that go.

     

  • Hi Dave, 

    Were you brave enough to deselect the custom phy? Any other updates you'd like to share?

    Best regards, 

    Caleb

  • Caleb,

    So I'm going to close this out; mostly because I'm frankly afraid to touch it again because I have other things working.  In the end, what I THINK has happened is.... I tend to type fast; I even tell myself I can outrun some of the wireless keyboards I run into.  What I do know even when not typing fast though, is that the SysConfig tool is running a script in the background when i change things, and what i think is happening is that I'm clicking on the PHY I want, hitting close which saves the file, and then I try to rebuild.  I have done it several times, and what I see happening is that if I go back and try to change the PHY, the default PHY dialogue box changes, but IT DOES TAKE A SECOND OR TWO.  I think if I save the file in that second or two, I'm getting the actual text file that the script is editing into a bad state; where it's still got the default PHY set to something like a 50kbps one when I don't have that even available anymore; and that's what's hosing it up.  I could try to figure out the text file, but that's a) stupid because no one else should gave to to that, and  b) could just be my PC being slow or something too; so maybe no noe else has this problem.

    So in the end, my advice to all is, if you change anything in SysConfig, count to 3, and then save the file.  That has worked well several times; I can't say with absolute certainly this is it; but when I had the issues with corrupting the thing I was definitely clicking faster.