CC1354P10: MAP_GapInit_cancelConnect() in SDK 8.31 resolves to trap (E7FE) and causes infinite loop when canceling initiating (CC1354P10_6)

Part Number: CC1354P10

MAP_GapInit_cancelConnect() resolves to trap (E7FE) in SDK 8.31 causing infinite loop during initiating cancel

Environment

• SDK Version: SimpleLink CC13xx/CC26xx SDK 8.31.00.11

• Device: CC1354P10

• Stack Variant: ble5stack_flash / cc1354p10_6

• Base Example: multi_role

• Toolchain: TI ARM compiler (CCS)

Problem Description

When operating as Central and performing connection initiation, our application implements a timeout mechanism. Upon timeout, we call the cancel connection procedure (initiator cancel).

However, when this path executes, the system enters an infinite loop inside:

MAP_GapInit_cancelConnect()

The device halts and never returns.

Disassembly Evidence

The function resolves to:

E7FE    b .

This corresponds to a 2-byte infinite branch instruction (trap stub).

Map File Evidence

From the generated .map file:

00060382    00000002     rom_init.o (.text.MAP_GapInit_cancelConnect)

This confirms:

• MAP_GapInit_cancelConnect is linked from rom_init.o

• Function size is 2 bytes

• It matches the trap stub (E7FE)

Expected Behavior

The official examples and stack references indicate that the correct implementation path should call:

GapInit_cancelConnect()

To verify this, we modified rom_init.c as follows:

extern uint8 GapInit_cancelConnect(void);

uint8 MAP_GapInit_cancelConnect(void)
{
#if (HOST_CONFIG & CENTRAL_CFG)
    return GapInit_cancelConnect();
#else
    return bleIncorrectMode;
#endif
}

After this change:

• The project builds without errors

• The .map file now shows:

0008262f    GapInit_cancelConnect

• Cancel connect executes correctly

• The infinite loop no longer occurs

Observations

1. GapInit_cancelConnect() exists and links successfully (presumably from OneLib.a).

2. The default rom_init.c implementation of MAP_GapInit_cancelConnect() appears to be a trap stub.

3. This trap is reached during a valid central initiating timeout → cancel scenario.

Questions

1. Why does SDK 8.31 provide a trap implementation for MAP_GapInit_cancelConnect()?

2. Is this behavior expected only under certain configuration variants?

3. Is there a required glue-layer variant that should override this stub?

4. Should this be considered a defect in the cc1354p10_6 ble5stack_flash configuration?