CC2650 OAD link order

Yes, it matters what is shown in this window. ICALL_STACK0_ADDR needs to be defined both places due to a compiler limitation. From the software developer's guide..."Due to a limitation of the IAR & CCS linker, ICALL_STACK0_ADDR must also be defined in this file to the same value as the linker config file. This file is located in the TOOLS IDE folder and updated by the Boundary tool when an adjustment is required."

Hi Tim,

The screenshot I posted in the question was what I got when I set the SimpleBLEPeripheral to the FlashOnly_ST_OAD_ExtFlash build, so it seems to be an error in the example project...

Anyhow I fixed that, but I also found the following issues:

1) In cc26xx_ble_app_oad.cmd, the following is coded: FLASH (RX) : origin = APP_BASE, length = ICALL_STACK0_ADDR - (APP_BASE + PAGE_SIZE) - 1. However this seems to waste a page. Shouldn't this simply be FLASH (RX) : origin = APP_BASE, length = ICALL_STACK0_ADDR - (APP_BASE) - 1.Why is length reduced by an extra page? You can see from the following map files that one page in flash is wasted:

OUTPUT FILE NAME: <SimpleBLEPeripheralStack.out>
ENTRY POINT SYMBOL: "startup_entry" address: 0000e001
MEMORY CONFIGURATION
name origin length used unused attr fill
FLASH 0000e000 00011000 000104ca 00000b36 R X
SRAM 200043e8 000004ff 000004d4 0000002b RW X
$BOUND$0x20004fec 20004fec 00000010 00000010 00000000 R IX

OUTPUT FILE NAME: <SimpleBLEPeripheralFlashNonOAD.out>
ENTRY POINT SYMBOL: "ResetISR" address: 00005651
MEMORY CONFIGURATION
name origin length used unused attr fill
FLASH 00000000 0000dfff 00007a7a 00006585 R X
FLASH_LAST_PAGE 0001f000 00001000 00000058 00000fa8 R X
SRAM 20000000 000043e7 0000311b 000012cc RW X

0xe000 comes right after 0xdfff, so there's no wasted flash in the non-OAD build

OUTPUT FILE NAME: <SimpleBLEPeripheralOAD.out>
ENTRY POINT SYMBOL: "ResetISR" address: 00007325
MEMORY CONFIGURATION
name origin length used unused attr fill
FLASH 00001000 0000bfff 00008beb 00003414 R X
SRAM 20000000 000043e7 00003287 00001160 RW X

0x1000+0xbfff=0xcfff, but the stack starts at 0xe000, so it seems that a page is wasted in the OAD build.

2) In the hexmerge call in the SimpleBLEPeripheral post build:

python "C:/Python27/Scripts/hexmerge.py" -o "${PROJECT_LOC}/FlashOnly_ST_OAD_ExtFlash/OAD_IMAGE_FULL.hex" -r "1000:1CFFF" --overlap=error "${PROJECT_LOC}/FlashOnly_ST_OAD_ExtFlash/${ProjName}.hex":1000:EFFF "${PROJECT_LOC}/../SimpleBLEPeripheralStack/FlashROM/SimpleBLEPeripheralStack.hex":F000:1CFFF

SimpleBLEPeripheral.hex ends at 0xcfff but the merge chooses 0xefff as the end address. Also SimpleBLEPeripheralStack.hex uses the wrong start and stop addresses. 

3) I'm unclear on the origin for SimpleBLEPeripheralOAD.out starting at 0x1000, but the OAD User's Guide says to set M3Hwi.resetVectorAddress = 0x00001010;. I confirmed that the starting address is indeed 0x1010 by reading the flash contents. Why is this not starting at address 0x1000?

Please comment on these issues as they are found this way in the SimpleBLEPeripheral example. Thanks!

Hi Tim, any comments? Thanks!

There shouldn't be any issues in the default sample project. If there are, I will look into them. Are you using the 2.1.0 installer? And are there absolutely no changes to the sample project?

Hi Tim,

There are no changes and I'm using the 2.1.0 installer. I'm using CCS not IAR. There's another thread in this forum that says that the IAR compilation of the BLE stack uses less flash, and that's where this discrepancy is coming from. You'll want to update the OAD guide and SimpleBLEPeripheral project if so.

Hi,

How did you replace the cc26xx_ble_app.cmd by cc26xx_ble_app_oad.cmd in the list, as mentioned in the user's guide?