The TI E2E™ design support forums will undergo maintenance from Sept. 28 to Oct. 2. If you need design support during this time, contact your TI representative or open a new support request with our customer support center.

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.

SIMPLELINK-CC13XX-CC26XX-SDK: I need to bypass this routine in ROM: "ThisLibraryIsFor_CC13x2_CC26x2_HwRev20AndLater_HaltIfViolated"

Part Number: SIMPLELINK-CC13XX-CC26XX-SDK
Other Parts Discussed in Thread: CC2651P3, SYSBIOS, , CC2651R3

Hi, I have been battling this issue for a few weeks.  I have a working app. that is NOT using the BLE lib's so far.

Now has come the time to merge my app. source code into "simple_peripheral" for the CC26xx processor.

I have been using the CC2652R1 so far.  However we bought 50 pieces of the XCC2651RF1 part a year ago

and now find we have to use them as NONE of the production parts are available until 2023. 

The problem I have is TI seems to not have a correct SDK for these proto. X parts.  I have gotten my application

to run on the part, as well as the simple_peripheral BLE and both work well. (The BLE example only uses the

BTN1/2, LED RED/GREEN pins).

My app. will run on either part, doesn't care, I don't use the missing UART channel.  However I do need the other

pins to be working, and even though the production part (and SDK) have them locked out in syscfg editor the

way I got them to work shows me these XCC parts have the pins where I need them (board layout locks me in).

So, what I'm trying to do is find a configuration that works to build this so it runs and does lock up in a spin loop

at start up due to the "wrong library" issue.  I don't care about that for these 50 parts and our proto. run.

Either I take a CC2652R1 sample and make it not lock up by patching out the checks for CPU TYPE and VER

and anything else that would lock it up.  Or I take a CC2651P3 SDK example code and make it allow me to use

the pins I have to have due to board layout.  (Pins are: DIO0,DIO1,DIO4)  (Note: DIO2&3 are UART, N/A).

I CAN NOT FIND an SDK that allows the XCC2651RF1 part selection as most likely as it's a factory proto. part

and no longer available either, fine.  I think for a short time TI may have had an SDK that would work with the

XCC2651RF1 part, but it is long forgotten now. My company wants to use the 50 parts we have so I need to find a

way to build for them. 

I have been through the wringer on sifting through TI's source code.  There are two places it seems to check

for the correct CPU in the library: 1) in the ROM, 2) in the driverlib in my app.  I commented out the driverlib

that is in 'chipinfo.c' but the code hangs before than in the ROM version of this check, there are two?  I have

not found a way to patch out the ROM version or even rebuild the ROM code. 

I think I found it's source code that is zipped up but not sure how or when this gets built, maybe it comes prebuilt

in the SDK install?  Not sure, need help on that.  I'm not even really sure how a "ROM" us used being this is an all

FLASH device, so I think ROM is an old adage being used still and mimiced in TI's SDK's, perhaps some CPUs do

have a separate ROM but these are all FLASH parts so the ROM image is there and must contain the TI RTOS

and boot code.  How do I modify and rebuild this?

It appears this folder in the simple_peripheral demo project makes the ROM library, but it is not clear to me

that a "clean" at the top level cleans the sysbios stuff so a "full rebuild" remakes all of the FLASH image.

# ======== convenient build goals ========
.PHONY: sysbios
sysbios: $(GEN_SRC_DIR)/sysbios/rom_sysbios.aem4f

# CDT managed make executables depend on $(OBJS)
OBJS += $(sysbios_LIB)

#
# ======== rules ========
#
$(sysbios_LIB): .force
    @echo making $@ ...
    @$(MAKE) -C $(sysbios_SRC)

.sysbios_clean:
    @echo cleaning $(sysbios_SRC) ...
    -@$(MAKE) --no-print-directory -C $(sysbios_SRC) clean

#============================

Maybe TI expects a CCS user to drop to command line and get in that folder and run 'make' the usual

old fashioned way outside of the IDE? (i.e. make clean, make all).

So, if that rebuilds the ROM lib, great.  I still CAN NOT find the "NOROM_ThisLibraryIsFor-----" routine

source code to patch it out for the ROM lib.  I can only find the one stated above in 'chipinfo.c'.

Please find a way to simplify this for me so I can do what I need to to build BLE into or along with my

application code and get to the next level and make the team leader happy.

Thanks,  Marc Y.

CCS  Linux version 11

SDKs: /ti/simplelink_cc13xx_cc26xx_sdk_5_40_00_40 (I've tried the newer ones, same issues or worse).

MCU: CC25x2R1 (Launchpad), and XCC2651RF1 (on my custom board)

Dev. OS: Linux Mint 20

  • Hi Marc,

    The pre-production CC2652R1 silicon (Rev C) has not been active on the SIMPLELINK-CC13XX-CC26XX-SDK since v2.30 as further explained in this FAQ post.  As it is not recommended for production, this version is no longer listed on the SDK download page.  There are TI-RTOS, drivers, bootloader, Bluetooth® 5.2 low energy controller, and IEEE 802.15.4 MAC resources stored in the device's ROM for optimized application size, please refer to the datasheet for more details.  Thus you would not be able to use a newer SDK version on this part which aligns with the older ROM contents, and reverting to a deprecated SDK would degrade the performance of your simple peripheral application.  This is why a chip verification procedure has been implemented to prevent incompatible devices from running the SDK application.  We could further discuss providing a compatible SDK offline, however TI would not be able to provide any further support or assistance.

    Regards,
    Ryan

  • Thank you for the reply.  It's detailed and helps a bit.  However you appear to be talking about the CC2652 part not the XCC2651RF1 I am using and needs an SDK for it.  I think there was one around when that part was in pre-release beta.  However at the time I did not download it.  Where can I get an SDK that would work, I don't care how old it is as long as I can get BLE with my own app.  Are you saying that the ROM code is baked in on XCC2651RF1 part?  If so I really won't get code running with any of the newer SDK's.  Please dig in and see what is available for this part?

    Thanks again,

    Marc Y.

  • My apologies for making an assumption about which part you were using.  The final product of the XCC2651RF1 is the CC2651R3 and there should not be any discernable ROM differences between the two.  There is no official CC2651R3 LaunchPad which is why default examples are not provided in the SDK. There is a software-on-cc13x1x-26x1x module in the BLE5-Stack Migration Guide which shows how to take a LP_CC2651P3 project and convert it for LP_CC2651R3 support.  Be aware that as compared to the CC2652R1, the CC2651R3 has less RAM and a reduced set of peripherals/features which can be further explored when reviewing the datasheet or comparing products.

    Regards,
    Ryan

  • Thanks again Ryan.  Those two doc links look good, I couldn't find anything on my own that detailed this issue.  Your first link really nails it down for me.  I couldn't get 'syscfg' editor to allow me to select the R3 part over the P3, somehow with an older SDK I did get it to R3 which allowed me the 3 pins I needed...so I knew it could work, just when I sucked in a BLE example they all were only allowing the P3 part so I was befuddled on how to get it to open up to the R3 part....I will try later today and report either success or befuddled again...( and I thought I had read so many doc's, TI's info. sites are so huge it is hard to get down on stuff, that's why I messaged for help. )

    Cheers, Marc Y.

  • Ok, that was good info.  I'm closer, now can get my pins entered into syscfg editor.  However on compiling I see it fails on some pins that the NPI module requires for handshake.  This NPI stuff came up with SDK 6.10.0.29 has in its examples.  I might walk that back to 5.40.0.40 example I had been working with that didn't use the NPI source code.  This might be my avenue to get my build to work.

    I am closer now with your advice on porting the P3 example to R3 which I need.  Somehow my I had gotten my app. alone to work on R3 as I stumbled into it somehow.  When bringing in a BLE example to build on though, I could not switch from P3 to R3 part, syscfg wouldn't let me.  What you explained to me is the key I just couldn't see looking through the hundreds of files in the /ti folders....

    I'll walk back the example to one with out NPI and report if I got this going...

    Marc Y.

  • Got it.  Walking back to an earlier simple_peripheral example that I was using without NPI now works and I can define I2S, I2C and all the other GPIO's I need that the CC2652R1 had.  Of course missing the one UART I have worked around already as well as 1/2 of the RAM.

    Your help get me where I needed to be.  I sure didn't want to mess with the SDK source code as that will haunt you on upgrades/updates.  So now I have the latest SDK with the odd ball XCC part I have to use for the next 50 board build outs.  Sure wish TI would get a foundry going in the US and make plenty of those CC2652R3 parts as well as the amplifier I'm using TAS6622Q1 parts shipping again.

    I should have contacted support earlier on this issue, would have saved days and days of hair pulling.

    Case closed for now, thanks Ryan,

    Marc Y.