CC2340R5: MTU and PDU size issues with Latest F3 Stack

A little more info I have got from the trace...

Currently it looks like the Central (Phone) - is sending LL_LENGTH_REQ with correct size for TX and RX, 251 bytes but the response from the Peripheral is MAX RX Octets : 27 and MAX TX octets 251.

Hi Robert !

The issue does seem to come from the Max RX octets of your LL_LENGTH_RSP packet from your peripheral. Could you try to call the function HCI_EXT_SetMaxDataLenCmd after entering your BLE Task and before starting your connection, with the 251 for both TX and RX octets, and 17000 for the TX and RX time ? Could you also check the return value of this function ?

This should increase the max RX value for LL_LENGTH_RSP to 251 and fix your issue.

Kind regards,
Lea

Hi Lea

I've tried changing these.... and added a trap to see if the command is rejected.

The HCi returns with HCI_SUCCESS, but the parameters on the LL_LENGTH_RSP never change - values below added just to look for any change on RX and TX.

Seems like something is wrong inside the stack locking these values?

void *BLEAppUtil_Task(void *arg)
{

hciStatus_t hstatus ;

// Register to the stack and create queue and event
BLEAppUtil_stackRegister();

// Init the ble stack
BLEAppUtil_stackInit();

// Robs Test...

//Change initial values of RX/TX PDU and Time, RX is set to max. by default(251 octets, 2120us)
#define MV_APP_SUGGESTED_RX_PDU_SIZE 240 //default is 251 octets(RX)
#define MV_APP_SUGGESTED_RX_TIME 2500 //default is 17000us(RX)
#define MV_APP_SUGGESTED_TX_PDU_SIZE 240 //default is 251 octets(TX)
#define MV_APP_SUGGESTED_TX_TIME 2500 //default is 17000us(TX)

//This API is documented in hci.h
//See the LE Data Length Extension section in the BLE5-Stack User's Guide for information on using this command:
//All the documentation and collateral applicable can be found on TI Developer Zone - https://dev.ti.com/
hstatus = HCI_EXT_SetMaxDataLenCmd(MV_APP_SUGGESTED_TX_PDU_SIZE, MV_APP_SUGGESTED_TX_TIME, MV_APP_SUGGESTED_RX_PDU_SIZE, MV_APP_SUGGESTED_RX_TIME);

if( hstatus != HCI_SUCCESS )
{
while(1);
}

// Application main loop
for (;;)
{

.....

}

Hi !

It's difficult to pinpoint the issue with such a huge leap between 8.10.01.02 and 9.14.01.16. You could try to progressively change your SDK version to see which one is the first to cause the issue.

Alternatively, you could try to see if the basic_ble example from the latest SDK you are using also has the same issue or not. By using the menu, you can change the MTU of the connection. If you don't see the fragmentation issue, you could base your code on this example.

Kind regards,
Lea

Hi Lea,

Okay I have managed to build the BasicBle example from the latest SDK, so none of our custom code in the project but only changes to the characteristics defined to align with our target device and expose a large characteristic of size 240 bytes.

So when data moves back and forth between central and peripheral there is no decoding or anything done on the data from an APP perspective.

With this configuration I am seeing the same problem. LL_LENGTH_REQ is good from central (phone) and LL_LENGTH_RSP (from peripheral CC2340 ) is wrong and limiting to 27 bytes on its RX even though it happily transmits at full length.

I am very sure this is a problem in the stack. Even using the HCI commands I cannot ever get this to change. 

Would be happy to work with the TI App Dev support team offline directly to try and resolve this even share code. We've been trying to get this device into production for over a year now to replace the CC2541 but the stack and early devices have just been so problematic to get a real App useful App running.

Best Regards

Rob

Hi Robert !

Sorry for the long delay, I wanted to make sure to have proper examples backing up my claims before replying. I have created for you two projects for the CC2340R5.

The first project is called "basic_ble_peripheral_LP_EM_CC2340R53_freertos_ticlang" and exposes a new service with a new characteristic, which is a long characteristic (255 bytes).

The second project, called "basic_ble_LP_EM_CC2340R53_freertos_ticlang", is an example of a central device that can send GATT requests. It is mostly based on this example (https://github.com/TexasInstruments-Sandbox/SimpleLink-Low-Power-F3-Demos/tree/main/Projects/full_ble_GATT_client_LP_EM_CC2340R5_freertos_ticlang) that I created a few months back. The difference is that this project adds the feature of being able to send a MTU request through the menu.

I have confirmed using a sniffer that when using both these projects on CC2340R53 LaunchPads, the GATT requests are done 251 bytes by 251 bytes, which is the theoretical maximum in BLE.

These examples are done using the latest SDK (9.14.02.16). I hope that this will be enough for you to compare, inspire yourself and make use of these working examples to fix the issues that you may have.

Kind regards,
Lea

Hi Lea,

Thanks for your effort on this, but looking at the transactions on your sniffer, are you not seeing the same problem where by the LL LENGTH REQUEST - which is 251 bytes TX and 251 Bytes RX is not being accepted, instead the response for this is 27bytes and 251 bytes. Even though the MTU length is accepted, you transfers in one direction are probably still being fragmented. Which wasn't what I get with the older SDK.

Have you tried expanding the capture of the large packets to see if they are Fragmented. 

I will have to try and build these examples and use wireshark. It might take some times as actually we use IAR here.

Kind Regards

Rob

HI Lea,

I have tried downloading and building Full_GATT_Client_Ble_LP_EM-CC2340R5 FreeRTOS_ticloang from GitHub, it doesn't seem to build, seems to be looking for SDK v9.10.0.83, i have 9.14_01_16 available it is trying to use.

Build errors:

[0]**** Build of configuration 'Release' for project 'full_GATT_client_LP_EM_CC2340R5_freertos_ticlang' ****

[1]"C:\\ti\\ccs2041\\ccs\\utils\\bin\\gmake" -k -j 32 all -O

[2]Building file: "../full_GATT_client.syscfg"
[3]Invoking: SysConfig
[4]"C:/ti/sysconfig_1.23.2/sysconfig_cli.bat" -s "C:/ti/simplelink_lowpower_f3_sdk_9_14_01_16/.metadata/product.json" -s "C:/ti/simplelink_lowpower_f3_sdk_9_14_01_16/.metadata/product.json" --script "C:/Users/Rob/workspace_ccstheia/full_GATT_client_LP_EM_CC2340R5_freertos_ticlang/full_GATT_client.syscfg" -o "syscfg" --compiler ticlang
[5]Running script...
[6]TypeError: unknown property: numOfDefAdvSets
[7] at setHelper (C:\ti\sysconfig_1.23.2\dist\webpack:\sysconfig\src\pinmux\services\objectManagers\proxyHandlers\managedObjectProxyHandler.ts:186:8)
[8] at Object.set (C:\ti\sysconfig_1.23.2\dist\webpack:\sysconfig\src\pinmux\services\objectManagers\proxyHandlers\managedObjectProxyHandler.ts:30:10)
[9] at scriptFunc (C:\Users\Rob\workspace_ccstheia\full_GATT_client_LP_EM_CC2340R5_freertos_ticlang\full_GATT_client.syscfg:49:43)
[10] at cb (C:\ti\sysconfig_1.23.2\dist\webpack:\sysconfig\src\pinmux\services\scripting\runScript.ts:112:7)
[11] at withDeprecatedAccess (C:\ti\sysconfig_1.23.2\dist\webpack:\sysconfig\src\pinmux\services\deprecatedAccessGuard.ts:14:10)
[12] at runAsUserScript (C:\ti\sysconfig_1.23.2\dist\webpack:\sysconfig\src\pinmux\services\scripting\scriptingGuard.ts:61:10)
[13] at iteratee (C:\ti\sysconfig_1.23.2\dist\webpack:\sysconfig\src\pinmux\services\scripting\runScript.ts:110:5)
[14] at baseEach (C:\ti\sysconfig_1.23.2\dist\webpack:\sysconfig\node_modules\lodash\lodash.js:530:11)
[15] at Function.each (C:\ti\sysconfig_1.23.2\dist\webpack:\sysconfig\node_modules\lodash\lodash.js:9409:52)
[16] at C:\ti\sysconfig_1.23.2\dist\webpack:\sysconfig\src\pinmux\services\scripting\runScript.ts:108:6
[17]gmake: Target 'all' not remade because of errors.

[18]**** Build finished ****

Isn't that numOfDefAdvSets sysconfig related?

Hi Robert !

Yes, numOfDefAdvSets is related to SysConfig. This project was made for an older SDK, and I'm working on updating this example since i took the time to upgrade the example for your use case. 

I just realized after reading my previous message that I completely forgot to add the projects I was talking about, so sorry about that >_>
You can find the two projects here :

MTU_long_characteistic_LP_EM_CC2340R53_freertos_ticlang.zip

Kind regards,
Lea

HI Lea,

Okay, I've managed to build your two examples and get them running on two LaunchPads. Note I am using CC2340R5 - not R53. So I changed the target CPU in sysconfig to get these to run.

I have managed to use wireshark to look at the big data transfers. When the Central does a READ_REQ the Read data is a large packet and works, however when I try to do a WRITE_REQ  (which you did provide a example trace log for) - the peripheral seems to lock up without responding.

It is indeed the WRITE which we need to check as these are the transfers getting fragmented with the latest STACK from what our devices now show.

Also FYI - for speed we do a WRITE_NORSP

Before I dive to much into your examples - can you try this - and maybe with CC2340R5 as that is where our problem is also.

Thanks

Rob

Hi Lea,

FYI: Just a couple of things that look wrong in your test APP is memcpy() usage moving data in and out of the long characteristic, with its length defined as 512 but the receiving array in the callback on 20 bytes.

I also thought 251 was maximum payload size with Data Length Extension?

Rob

Hi Lea,

Okay so I managed you get your two projects running and using a 241 bytes payload data. Corrected memory allocations and caught characteristic 53 in the central to write a larger data block. As the demo you had only ever wrote a single byte.

The overall result is it demonstrates the same issue I have in our project whereby in one direction Central ReadReq (PERIPHERAL to CENTRAL )the 241 bytes of payload is sent in a single interval, but in the other direction  Central WriteReg (CENTRAL to PERIPHERAL) the payload is fragmented into multiple transactions of 27 bytes max.

The MTU setup is still exactly as you had it.

This confirms there seems to be an issue in these latest SDK's with the LL size one direction. 

I have a capture of this but can't seem to upload here at the moment. I can also probably share the modified projects.

My next step is try WriteReq without Response. But I expect it is all the same. RX / TX MTU set to 251.

Can we get some more investigation into this? Our project is quite blocked by this at the moment. Happy to help out any way I can.

Thanks

Rob

Hi Robert !

Good catch on the memcpy issue, I will be sure to fix it as soon as I can. I indeed only tried the read while testing, I will try to see if the writes are fragmented and come back to you as soon as I can. Could you please send me your code where you fixed this issue so that I can both fix it on the github repository, and also reproduce your issue easily ?

What I'm gonna try to do once you send me your patch is to change the SDK versions to see where this issue started to appear, and inform R&D of the issue if I cannot find a fix for you by myself.

Kind regards,
Lea

Hi Lea,

Sorry I am unable to attach any files on this. Can you send me any upload link etc?

I think there is an issue with the FORUM attaching files at the moment.

Br

Rob

Hi !

https://tidrive.ext.ti.com/u/7GYWNZHmFjT-ZhYW/6f985194-32d5-4aed-82c9-447132453185?l
code : 8FA|Rvj9

You should be able to upload there for 1 day.

Kind regards,
Lea

Hi Lea

Great thanks - I have now uploaded the zip file with the two projects.

Also added image showing fragmentation.

PS. Appologies in advance - in the Central I have hard coded a trap to send the 241 bytes large packet on if( currentGATTChar.valueHandle == 55), not ideal but was trying to get to grips with the app_menu.c operation. Couldn't quickly work out how to check characteristic max length.

Hope this helps

Rob

Hi !

No problem, your work already saves me a lot of time.
I will look into it today and try to give you an update on my findings,

Kind regards,
Lea

Hi Robert,

I am able to reproduce your issue, where writes are fragmented but not the reads. I'll continue to investigate.
(E2E is having difficulties to send the image of my sniffer but I do see the Continuation LE-U transfers in my sniffer)

Kind regards,
Lea

Hi Robert,

After more testing, the issue appears in SDK version 9.14.00.39. The SDK version 9.12.00.19 is working fine. I will try to find the difference between those two SDK versions that cause the issue.

Kind regards,
Lea

Hi Robert !

After digging more, I was able to identify the exact commit that caused the issue. This bug was introduced when trying to fix another bug when CODED PHY was used, but we did not realize until it was released that it caused another issue.

The issue you're facing is on every DLE exchange, the connMaxRxOctets and connMaxRxTime values are updated to the effective value of the connection. This causes an issue where those values can only go down. At the start of your connection, these values are low due to the central using 27 bytes for the TX, making the effective value for RX 27 bytes for the peripheral. The value is then set as the max value for the peripheral and is stuck that way.

There is currently an unmerged PR that would fix this issue, I'm gonna give more attention to the issue and ask the team responsible for the BLE stack to merge the PR as soon as possible.

Kind regards,
Lea

Hi Lea,

Thanks for you work on this - sounding like there is a positive solution not far away. Let me know when there is an update I can test and review.

All the best

Rob

In the meanwhile, you can upgrade your SDK to version 9.12.00.19 which does not contain the bug, and later upgrade to 9.20 when it is released.

Hi Lea,

I'm trying to downgrade the Stack and retest all this.

In CCS - the BLETestLongCentral is building okay with older stack, but on the BLETestLong (peripheral ) - I can't seem to overcome this error in the build.relating to BLE_CONFIG_NUM_ADV_SETS.

Did you just redirect the build in CSS to the older SDK, or do I need to maybe use an older sysconfig, or re-create the project. Seems like sysConfig should be defining the BLE_CONFIG_NUM_ADV_SETS in ti_ble_config.h ? but I have no definition in my peripheral based project. Actually multiple advertising seems to be defined under Broadcaster,

Any pointer to what I am doing wrong would help  ( New to CCS - normally work with IAR, but starting to think sysconfig and SDK version are tightly linked together maybe.

270] | ^
[271]../app/app_peripheral.c:182:13: warning: call to undeclared function 'BleConfig_startAdvSets'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
[272] 182 | BleConfig_startAdvSets(peripheralAdvHandles, NULL, BLE_CONFIG_NUM_ADV_SETS);
[273] | ^
[274]../app/app_peripheral.c:182:64: error: use of undeclared identifier 'BLE_CONFIG_NUM_ADV_SETS'
[275] 182 | BleConfig_startAdvSets(peripheralAdvHandles, NULL, BLE_CONFIG_NUM_ADV_SETS);
[276] | ^
[277]../app/app_peripheral.c:221:42: error: use of undeclared identifier 'BLE_CONFIG_NUM_ADV_SETS'
[278] 221 | uint8_t peripheralAdvHandlesStatuses[BLE_CONFIG_NUM_ADV_SETS];
[279] | ^
[280]../app/app_peripheral.c:222:5: warning: call to undeclared function 'BleConfig_initAdvSets'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
[281] 222 | BleConfig_initAdvSets(peripheralAdvHandles, peripheralAdvHandlesStatuses);
[282] | ^
[283]../app/app_peripheral.c:223:25: error: use of undeclared identifier 'BLE_CONFIG_NUM_ADV_SETS'
[284] 223 | for (int i = 0; i < BLE_CONFIG_NUM_ADV_SETS; i++)
[285] | ^
[286]../app/app_peripheral.c:232:5: warning: call to undeclared function 'BleConfig_startAdvSets'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
[287] 232 | BleConfig_startAdvSets(peripheralAdvHandles, NULL, BLE_CONFIG_NUM_ADV_SETS);
[288] | ^
[289]../app/app_peripheral.c:232:56: error: use of undeclared identifier 'BLE_CONFIG_NUM_ADV_SETS'
[290] 232 | BleConfig_startAdvSets(peripheralAdvHandles, NULL, BLE_CONFIG_NUM_ADV_SETS);

Br

Rob

Hi Rob !

You're correct that there are some differences in the SysConfig between difference SDK versions. You can find all the code I've written in this TI drive. In particular, you can copy the SysConfig file for the BLETestLong_9.12 sample

https://tidrive.ext.ti.com/u/ixP2L_aT9i-ZE_YM/6f985194-32d5-4aed-82c9-447132453185?l
code : @va85iQs

Kind regards,
Lea

Hi Lea,

So eventually go back onto this. I have used you example for the 9.12 SDK, (peripheral side) - but I still see the same fragmentation. 

Does the central need to run the old stack as well, or was this just a peripheral issue. 

I am still working inside CSS and using two TI Dev cards just to test this at the moment.

Best Regards

Rob

Hi !

Sorry for the late reply, I was in Easter vacations.
The issue should only be on the peripheral side, and was created in 9.14.00.39.

Using the example I provided in the TI drive should work. I have tested it using my mobile phone as the central.

Kind regards,
Lea

Hi Lea,

Just back from Hols myself.  I have revisited this, build the examples you have with a Central and Peripheral running on two CC2340R5 dev boards. I am still seeing the long Write Request fragmented.

Wondering how you are using the mobile phone to actually send large Write_Req. Do you have a custom APP. as creating these large block with APP's light light blue explorer is just difficult to ensure to write in the correct number of bytes.

My BLETestLongCentral is using F3 SDK 9.11.1.19

My BLETestLong   (peripheral) is also using F3 SDK 9.11.1.19

Here is the sniffer showing the fragmentation still occurring when Central writes 241 bytes to peripheral.

Any thoughts? Do you have a sniffer log of the actual Write_Req ?

Br

Rob

Good afternoon Robert !

I sent a message this morning saying that I would test this for you, but it didn't send apparently, sorry for that.
I have made sure that the BLETestLong_9.12 project works as intended using a sniffer. This was tested on a CC2340R53 and my mobile phone using a bluetooth app.

You can see that before the MTU transaction, the maximum read is 22 bytes, and the maximum write is 18 bytes

I then send the MTU transaction request with my phone, and the CC2340R53 peripheral replies with a MTU of 251. Right after the MTU transaction, a Data Length Update transaction is also sent, with all RX and TX values set to 251 bytes

Finally once this is done, both my RX and TX GATT transactions can read everything in one go without dividing the packets

I suspect that the issue you might be facing in your side is that you forgot the MTU transaction, or that your central does not operate a Data Length Update transaction after the MTU transaction automatically. In this case, one solution would be to do this DLU transaction yourself in the callback of the MTU update in your peripheral.

Kind regards,
Lea

Hi Lea,

I've back looking at this on and off now. I am still making zero progress and unable to get a working build when using the CC2340R% Dev Kit for both the Central and Peripheral running stack 9.12.

I really need some more support with this, have burnt months now and this project isn't getting anywhere.

In you last response you mention doing the DLU transaction myself in the callback for the MTU update. do you have a example of this.

 I cant find any call-back in the examples we've been using for troubleshooting this issue. I have some concern you are not testing this with a dev board
running the this SDK for both sides. So perhaps I am getting tripped up by a CC2340 central SDK issue too.

I am definitely performing the MTU request  - and the stack seem to be responding okay (whether they are modifying setting in the stack as a result of that
command I cannot tell).

Finally, on the images you sent, the last didn't show a complete 241byte Central Write (bottom half) - looked broken into smaller packers? (Correct me if I am wrong) - allbeit not as small as my 27 bytes blocks.

Best Regards

Rob

Hi !

I'm in travel right now, I'm giving you a short answer because I don't have much time, I'll go more in depth next week sorry for that.

The 241 bytes central is because I sent a 241 bytes long packet, it was just a long gibberish string and I didnt check if it was longer than 255. I could have sent something longer, it was just to prove that we can send more than 23 bytes in this version.

I am definitely testing this with a dev board, since its the only thing I have in the office anyway lol.

Do you see the DLU packet after the MTU update in a sniffer ? That's the key part that tells you if this works or not.

Kind regards,
Lea

Hi Lea,

Okay, this is where I have managed to get to.

Using the 9.12.00.19 SDK, I have managed to build a peripheral device that now achieves the long packets on Read and Write. However this only
works with a PHONE running as the connecting central. When I use a Central Device running CC2340R5 Dev board, I continue to have the issue in one
direction, so really unsure what is going on with that. The MTU updates and LL exchanges seem similar to when the PHONE is the central.

From there, I've managed to regenerate our APP based on the 9.12.00.19 SDK and again prove through the bigger transfers, so all good.

Just spotted new release 9.20.00.81 has dropped. So I will be moving to that and checking its a final solution.

Moving in house project work between stack on IAR is a real headache, I cannot just reference the new stack - and generally have to build up again from the BLE Demo app. Wondering if there any intention from TI's side to create BIN library files for the Stack instead of all the source files?

Anyway, will rebuild with 9.20.00.81 and let you know how it goes.

As for why my 9.12.00.19 Central still does fragmented Writes, I just don't know.

All the best

Rob

Hi !

For your IAR upgrade issues, I would recommend for you to look into the differences between two files files for the original SDK and target SDK :
- examples\rtos\LP_EM_CC2340R53\ble\basic_ble\freertos\iar\basic_ble_LP_EM_CC2340R53_freertos_iar.ipcf
- examples\rtos\LP_EM_CC2340R53\ble\basic_ble\freertos\iar\makefile

These are the files where the new files to build or other changes are added. See for example the differences in the basic_ble project, where 9.20 adds coex and PawR files.

Please keep me updated if the issue is fixed on 9.20.

Hi Lea,

So still working with the BasicBLE Demo and building in the IAR environment. After that I should be able to bring over our APP code and test.

I have found a lot of issues with the new SDK and its setup for IAR. I think I now have the basicBLE building but wanted to give you a list of the problems I have found so maybe the team can resolve in the next release so its easier for other users.

Here is my notes so far. Seems to be building now. You should also note that my working folder is on a different drive letter and include white space in the folder name - so some changes are just adding "" around $PROJ_DIR etc, to ensure the whole file string gets passed. I can see TI have added this in many places anyway in the latest stack.

A lot of my additional issues have been related to the created IAR project files not referencing correct locations, and also I can see TI have moved basicble.syscfg file inside /freertos  and also main_freertos.c inside \common\startup

One key area I haven't fixed, but managed to workaround is a prebuild command using 'command_runner', it seems to use the .exe and I assume the location
of .syscfg is hardcoded in that and incorrect given it has now moved into \freertos.

For my workaround I corrected the python script to work and run that instead.

Here is my list of things I've needed to do on IAR project to build it correctly.

New SDK Released  9.20.00.81

This introduces build issues again.
Stock demo of BasicBLE doesn't setup correctly. 

Issues: 

1. Copy across the folders into the working area: from the SDK for the example.
   \app
   \common
   \freertos
2. Project file location references are wrong. Need to edit .EWT and .EWP look for file referenced at $PROJ_DIR\C:\ti\simplelink_lowpower_f3_sdk_9_20_00_81\  and change to $COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR
3. Basic_ble.sysconfig is no longer in project route folder, re-attach it at \freertos
4. Main_freertos.c is no longer in route folder, re-attach it at \common\Startup

Problem with sysconfig GUI running. Manifest file is missing.

This is because 'package.json' has moved inside folder \APP

The Configure Viewers command line should change to add the \App folder:

"$SYSCONFIG_ROOT$\nw\nw.exe" "$SYSCONFIG_ROOT$\app" --compiler iar --product "$SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR$\.metadata\product.json"  "--output"  """$PROJ_DIR$" """$FILE_PATH$""

Problem with sysconfig.cli exectution.

Post build actions failing.

There is now 4 separate command lines.Pre and post builds.

Look for any file references for our $PROJ_DIR location and add "" to allow for out folder whitespaces ie $TARGET_BPATH$.out should be "$TARGET_BPATH.out"

$TARGET_BPATH$.hex should be "$TARGET_BPATH.hex"

"$PROJ_DIR$\$PROJ_FNAME$.ewp"

Final issue is with command_runner.py which is used as a prebuild step, its doesn't look beyond the project folder:

def find_syscfg_file(search_dir: Path):

    """Return the first .syscfg file found in search_dir, or None."""

    files = list(search_dir.glob("*.syscfg"))

    return files[0] if files else None

Change to

def find_syscfg_file(search_dir: Path):
    """Return the first .syscfg file found in search_dir, or None."""
    files = list(search_dir.rglob("*.syscfg"))
    return files[0] if files else None

or (better)

def find_syscfg_file(search_dir: Path):
    """Return the preferred .syscfg file from the project tree, or None."""
    preferred = search_dir / "freertos" / "basic_ble.syscfg"
    if preferred.exists():
               return preferred

    files = list(search_dir.rglob("*.syscfg"))
    return files[0] if files else None

Doesn't fix IAR as it seems IAR is using the commands_runner.exe rather than the python script.

 My workaround is to force it to use the edited .py script. Edit the prebuild line.

Change:

$SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR$/tools/ble/oad/commands_runner --cfg_file "$PROJ_DIR$\ti_ble_oad_prebuild.cfg" --compiler iar --ewp "$PROJ_DIR$\$PROJ_FNAME$.ewp" --config "$CONFIG_NAME$" --iarbuild "$TOOLKIT_DIR$\..\common\bin\IarBuild.exe" --sysconfig_cli "$SYSCONFIG_ROOT$\sysconfig_cli.bat" --execute_sysconfig --sdk_dir "$SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR$"

To:

python "$SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR$/tools/ble/oad/commands_runner.py" --cfg_file "$PROJ_DIR$\ti_ble_oad_prebuild.cfg" --compiler iar --ewp "$PROJ_DIR$\$PROJ_FNAME$.ewp" --config "$CONFIG_NAME$" --iarbuild "$TOOLKIT_DIR$\..\common\bin\IarBuild.exe" --sysconfig_cli "$SYSCONFIG_ROOT$\sysconfig_cli.bat" --execute_sysconfig --sdk_dir "$SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR$"

Hope this helps.

I'll also let you know once I have our full APP running and validate the big packets in that using the new SDK.

Best Regards

Rob

Hi !

You're correct that SysConfig has changed location, and that it breaks a few things. The MSP team reported a similar bug (MSPSWSDK-6776) where IAR users could not open *.syscfg files in the SysConfig editor using SysConfig version 1.26 or greater.

The solution is that “Users will need to re-import the ‘sysconfig_set_iar.xml’ file, provided in this SDK, in to their IAR viewer configuration to apply the change. Follow from step 5 in the IAR Quickstart Start Guide”. This should I hope fix most of the problems, such as the "Manifest file is missing" error.

Finally, I understand the issue with paths with spaces and I'll propose a patch to the team that handles this.

Kind regards,
Lea