stuck after porting to stack 2.2

Hello Torsten,

Indeed, you have hit an abort but 0x1001bbd6 is a ROM function, not flash. It's hard to say what the issue could be from the description alone, but did you confirm the stack project is built/flashed correctly and programmed with the correct ICALL_STACK0 address. See "3.10.2 Application and Stack Flash Boundary" in the SW Developer's Guide (SWRU393).

I would start there.

Best wishes

Hello JXS,

thank you very much for responding. Yes, I've checked the ICALL_STACK0 address. It's still 0xf000 (as for the original SimplePeriperhal example) and that's confirmed by looking into the map files of the application and the stack project. Both, flash and ram do not overlap for the stack and the application project.

The assembly code at the address 0x1001bbd6 is:

0x1001bbd6: cmp r2, #0
0x1001bbd8: beq 0x1001bbd6:

With r2 being #0. I wonder under which circumstance does such a loop makes sense? I can only think of an endless loop or some kind of wait for an ISR that sets R2 to some value other then #0.

The stack pointer points into the heap, which makes sense, if the stacks stack is allocated on the heap (at least I didn’t found any symbol that sounds like the stacks stack in the map file).
I’ve looked at the top of the stack, when the CPU is running this loop. The only address, that is at the top of the stack, that is within the application or stack image, is 0x0000B747 which is (according to the map files) ICall_primMalloc(). I’ve set a break point to that function but it seems to run without problems.

The only interrupt vectors that are within the interrupt vector table that points to the ROM region are 0x1001CA01 and 0x1001CA3F, which is clearly not the 0x1001bbd6, that I’m observing.

Puh, what options do I have now?

- Keep poking around in the dark, hoping that I finally stumble over the mistake I made?
- Role back my porting so far and do it again, hopping that I will not do the same mistake again?

Anything else that comes to mind? Any chance that I get the source for ROM functions?

Thanks in advance,

Torsten

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.

I found out, that if I introduce a bug into the SimplePeripheral example that simply does not free memory allocated by events received by ICall_fetchServiceMsg(), by commenting out the call to ICall_freeMsg(), I get the exact same behavior:
- The CPU is running in the loop above.
- The current PC is not on top of any of the RTOS tasks call stacks.
- The display on the eval board is showing nothing.

Now I wonder if a memory leak (shortage) is the only reason for the RTOS to go into this infinite loop or if there are other causes. Is there a way to install some kind of memory shortage handler, that would be called if the allocator is not able to allocate the requested amount of memory?

BTW: Under RTOS Object View, I can watch HeapMem. There seams to be one heap and when the infinite loops happens, that heap has still a totalFreeSize (and largestFreeSize) of 0x258. Does the RTOS/icall use it's own heap for messages?

kind regards,
Torsten

Hi Torsten,

There is a small BIOS heap that is used for dynamically allocating RTOS objects (like clocks, etc), however the BLE stack and the application use the ICALL heap. What compiler version are you using to build the project? Can you build and run the default examples with the SDK?

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

Jep, that fixed the original problem too :-)

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.