Hello,
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.
Hello,
By following the link register and assembly code over ~5 function calls, I’ve managed to confirm, that the endless loops origins from the task function of the task create by ICall_createRemoteTasks. The task function simply calls the function at ICALL_STACK0_ADDR and passing it the address of a configuration struct named user0Cfg. I’ve checked that the argument to ICALL_STACK0_ADDR (startup_entry) is passed correctly. So there is very little, that I can do on that end.
Ok, now as I was desperate enough, I replaced my project files (as suggested) with the project file from the SimplePeripheral project and started from scratch to make the project position independent. The resulting SimplePeripheral project worked. Then I replace the simeple_peripheral-Service with my service, I added all the required sources and added SRC_BLE_CORE/common/cc26xx/board_key.c to the project.
Hi Sean,
the compiler version is:
C:\Users\Torsten>C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.6/bin/armcl --compiler_revision 5.2.6
I've tried just the simple_peripheral_cc2650em example and that works (advertising looks reasonable, I can connect to the device and interact with in on a GATT level).
kind regards,
Torsten
Hello Sean,
Currently I’m experimenting with a setup, where the device does not add any additional GATT services (only the GAP service). I can easily change that example from „working“ to „not working“, by removing the device name from the scan response data. Now I made a diff between the map files of the working and the not-working versions. What puzzles me, is that the symbol rfRegTbl (defined in blue_user_config.c to be an array of 20 32-bit values), begins at an address that would not be proper aligned for 32 bit integers, for the not working version (left side), but begins at a proper aligned address in the working version (right side).
Is rfRegTbl accessed in a manner that requires the symbol to be 32-bit aligned?
Can I instruct the linker to force a certain alignment for a single symbol, or for all symbols?
Please see the attached screenshot.
kind regards,
Torsten
I've managed to place the rfRegTbl in an own linker output section, and thus forced the alignment to be 4 byte, and now my striped down version works. I will see if that works for the overall version too...
Here is my patch:
Index: cc26xx_app.cmd =================================================================== --- cc26xx_app.cmd (revision 428) +++ cc26xx_app.cmd (working copy) @@ -128,8 +128,14 @@ .emb_text : >> FLASH | FLASH_LAST_PAGE .ccfg : > FLASH_LAST_PAGE (HIGH) + + ble_user_config { + ./ICallBLE/ble_user_config.obj(.data) + } > SRAM + GROUP > SRAM { + ble_user_config .data .bss .vtable
Apologies for replying to a year-old post, but this was the first Google result I found when researching the same problem, which appears to continue to affect the current version of the BLE stack (2.2.1.18).
The root cause of this issue appears to be that regOverride_t, the type that rfRegTbl resolves to, is defined in ble_sdk_2_02_01_18/src/components/hal/src/target/_common/cc26xx/rf_hal.h like so:
PACKED_TYPEDEF_UNION { hwOverride_t hwRegOverride; fwOverride_t fwRegOverride; } regOverride_t;
PACKED_TYPEDEF_UNION ultimately resolves to (for CCS/TI compiler) "typedef union __attribute__((__packed__))" with the packed attribute explicitly telling the compiler to omit the padding required to preserve word-alignment (See SPNU151P section 5.16.4).
The fix is to change "PACKED_TYPEDEF_UNION" at line 833 in rf_hal.h to "typedef union".
Yes, rfRegTbl is of type regOverride_t. My fix just forced the linker to align that symbol properly, so that the ROM code, that is accessing the table won't crash. This way you don't have to touch the library source (a fix that you have to redo with every new version).
But, of cause, if TI would fix that, it would save us a lot of trouble.