Running out of flash when implementing Off chip OAD in CC2640

Harald Ilg

Hy there,

when trying to implement OAD into my project, I run into a flash size problem: My original firmware, which covers about 2/3 of the final features, uses 69,6k for the stack and 47,4k for the application.

App:

         name            origin    length      used     unused   attr    fill
---------------------- -------- --------- -------- -------- ---- --------
FLASH                 00000000   0000cfff 0000bdb2 0000124d R X
FLASH_LAST_PAGE       0001f000   00001000 00000058 00000fa8 R X

Stack:

name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
FLASH 0000d000 00012000 0001163c 000009c4 R X

When I want to implement OAD in SBP manner, I lose flash page 0 and need to run OS from flash rather than from ROM. Is that correct? With this setup, the flash size is not large enough.

program will not fit into available memory. placement with alignment fails for section ".cinit" size 0x9ee . Available memory ranges:
FLASH size: 0xafff unused: 0x1 max hole: 0x1
FLASH_LAST_PAGE size: 0x1000 unused: 0x8 max hole: 0x4

Is this different for Sensor Tag OAD sample? Can I run the OS from ROM there? (see here for differences between SBP and Sensortag OAD). When including the ROM into my build it consumes 4,8k in flash, is that possible?

What other possibilities do you see to save flash?

Best regards

Harald

over 10 years ago

0 JXS over 10 years ago

TI__Guru** 105180 points

Hi Harald,

As explained in the documentation, the RTOS must be built for flash as opposed to ROM since the RCFG is fixed in page 0.

Have you tried reducing stack features, such as OSAL SNV or disabling Pairing/Bonding support? This will free up some more flash memory.

Best wishes

0 Harald Ilg over 10 years ago in reply to JXS

Genius 3060 points

Hy, thanks for the quick response.

I understand, that the ROM OS need to have access to page 0. But in SensorTag OAD Mode, page 0 is free to use by application ("- The application image starts at 0x00000") see here.

In the SensorTag example, I find the two lines

var ROM = xdc.useModule('ti.sysbios.rom.ROM');
ROM.romName = ROM.CC2650;

in the file C:\ti\simplelink\ble_cc26xx_2_01_00_44423\Projects\ble\SensorTag\CC26xx\CCS\Config\appBLE.cfg

and SensorTag has OAD enabled, right?

From map file of sensorTag: The app uses addresses 0x0 ... 0000dfff, so it should be able to use OS in ROM, right?

FLASH 00000000 0000dfff 0000bd80 0000227f R X

All of this makes me think, that sensorTag Application uses OS from ROM and has OAD enabled, true?

As for the other possibilities to save flash space: You pointed me to the chapter 10.4.1 Minimizing Flash Usage of the Software Developers Guide. Thanks for that hint, I will have a look at this

Regards, Harald

0 JXS over 10 years ago in reply to Harald Ilg

TI__Guru** 105180 points

Yes, SensorTag does use the RTOS in ROM config even for OAD. However, kindly take note that if a fault, such as a reset or power loss event, occurs while sector 0 is erased or not fully programmed, the device will be in a state that prevents booting into SW as the reset vector table will be invalid. In this state, the device would be considered inoperable until the SW is recovered via JTAG or serial programmer. SensorTag, being a demonstration & app development platform, can take this risk since it is designed to be upgraded by the DevPack debugger.

Unless you have the appropriate debug/flash programming interfaces on your product, I would suggest using the recommended RTOS in Flash configuration for OAD.

Best wishes

0 Harald Ilg over 10 years ago in reply to JXS

Genius 3060 points

Thanks again for the quick response. We are quite clear about the risks with a non-booting device, if an error/reset occurs in the vulnerable time during OAD (that would be after erasing flash before fully writing it). But we expect this not to happen. We have a battery powered device, so no power on/failure reset can happen. If the flash writing itself causes a reset, the recommended OAD would be stuck in a eternal BIM, too. So we decided to go with the Sensor Tag philosophy of OAD.
There are still a couple of questions:
- How about CCFG area? Usually, the user ccfg area in flash is in the last page, same page as the BIM, which can not be updated with OAD. Does that mean, that I can not do any changes to ccfg flags? In Sensor Tag, the ccfg is linked to address 0x0003C, so on page 0. Is this possible? In thread here I read, that ccfg range must be on the last page of flash, because "ROM code" access these addresses, too. Can I use page 0 to hold ccfg initializers?
- The BIM is located on the last page of flash (0x1F000), it uses 2.3kByte at the moment, so there is still 1,7k in this page unused. I probably can use this area for common functions of BIM and application, i.e. access to the external ROM or constants or strings, right?
Thanks in advance, Harald

0 svendbt over 10 years ago in reply to Harald Ilg

TI__Mastermind 29650 points

Harald Ilg said:
How about CCFG area? Usually, the user ccfg area in flash is in the last page, same page as the BIM, which can not be updated with OAD. Does that mean, that I can not do any changes to ccfg flags?

Technically you can write bits that are 1's to 0's to continue updating CCFG area but we recommend not to. CCFG will not change but new TI RTOS / driverLib versions might extend CCFG (towards lower addresses) to support new features, bug fixes or performance improvements added by SW. If there are other data here then 0's might be interpreted as "enable" for these features which might be unfortunate.

Harald Ilg said:
In Sensor Tag, the ccfg is linked to address 0x0003C, so on page 0. Is this possible? In thread here I read, that ccfg range must be on the last page of flash, because "ROM code" access these addresses, too. Can I use page 0 to hold ccfg initializers?

Where do you see CCFG linked to 0x3C? CCFG should be located at the end of flash and for the SensorTag project it is only linked in by the BIM project.

Boot ROM reads this area and checks whether JTAG should be enabled, configures flash erase/write lock and checks if the flash image valid field is set.
This is done by reading from address 0x50003000 which is always mapped to the last flash page.

Harald Ilg said:
- The BIM is located on the last page of flash (0x1F000), it uses 2.3kByte at the moment, so there is still 1,7k in this page unused. I probably can use this area for common functions of BIM and application, i.e. access to the external ROM or constants or strings, right?

You can theoretically do this, yes. Beware however that you should have a couple of hundred bytes free before the CCFG structure in case it is extended in later versions.

Regards,
Svend

0 Harald Ilg over 10 years ago in reply to svendbt

Genius 3060 points

Hy Sven,

svendbt said:

Where do you see CCFG linked to 0x3C? CCFG should be located at the end of flash and for the SensorTag project it is only linked in by the BIM project.

Boot ROM reads this area and checks whether JTAG should be enabled, configures flash erase/write lock and checks if the flash image valid field is set.
This is done by reading from address 0x50003000 which is always mapped to the last flash page.

When I compile the original SensorTag project, configuration "FlashOnlyOAD", I see

0000003c 0000003c 00000058 00000058 r-- .ccfg
in the map file. This probably comes from the /SensorTag/Startup/ccfg_appBLE.c file, that is part of the project and includes the ccfg.c file.

In addition to that, I find

0001ffa8 0001ffa8 00000058 00000058 r-- .ccfg

in the map file of BIM. Does that mean, ccfg is double in Flash?

There is another thing I don't understand for the SBP OAD example: When compiling the original SimpleBLEPeripheral example with OAD activated as described in the OAD Users Guide, the BIM is linked in page 0 (IVEC_FLASH, address 0x0) as well as in page 31 (FLASH). In page 0, there is only the vectortable (.TI.bound:resetVectors, length 0x3C), all functionality is in page 31, starting on address 0x1F000 (LoaderEntry, length 0xF06). Also, the ccfg section is in page 31 (address 0x1ffa8, length 0x58 .ccfg).

Does that mean, in the SBP OAD way, I lose page 0, page 31 and the 4.9k for OS in flash?

Why wouldn't I link the BIM functionality to page 0, too?

Fullscreen BIM_ExtFlash.map.txt Download

******************************************************************************
                  TI ARM Linker PC v5.2.2                      
******************************************************************************
>> Linked Tue Sep 08 15:41:58 2015

OUTPUT FILE NAME:   <BIM_ExtFlash.out>
ENTRY POINT SYMBOL: "_c_int00"  address: 0001fd9d


MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  IVEC_FLASH            00000000   00001000  0000003c  00000fc4  R  X
  FLASH                 0001f000   00001000  00000f06  000000fa  R  X
  SRAM                  20000000   00002cff  00001124  00001bdb  RW X


SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00000000    00000000    0000003c   0000003c    r--
  00000000    00000000    0000003c   0000003c    r-- .TI.bound:resetVectors
0001f000    0001f000    00000eb0   00000eb0    r-x
  0001f000    0001f000    00000018   00000018    r-x LoaderEntry
  0001f018    0001f018    00000e58   00000e58    r-x .text
  0001fe70    0001fe70    00000006   00000006    r-- .const
  0001fe78    0001fe78    00000038   00000038    r-- .cinit
0001ffa8    0001ffa8    00000058   00000058    r--
  0001ffa8    0001ffa8    00000058   00000058    r-- .ccfg
20000000    20000000    00001024   00000000    rw-
  20000000    20000000    00001010   00000000    rw- .bss
  20001010    20001010    00000014   00000000    rw- .data
20002bfc    20002bfc    00000100   00000000    rw-
  20002bfc    20002bfc    00000100   00000000    rw- .stack


SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
LoaderEntry 
*          0    0001f000    00000018     
                  0001f000    00000018     baseloaderentry_ti.obj (LoaderEntry:CODE:ROOT)

.text      0    0001f018    00000e58     
                  0001f018    00000464     bim_main.obj (.text)
                  0001f47c    000003f8     ext_flash.obj (.text)
                  0001f874    00000238     bsp_spi.obj (.text)
                  0001faac    0000009c     rtsv7M3_T_le_eabi.lib : memcpy_t2.obj (.text)
                  0001fb48    0000007a                           : memset_t2.obj (.text)
                  0001fbc2    00000070     bls_bsp.obj (.text)
                  0001fc32    00000002     vector_table.obj (.text)
                  0001fc34    0000006c     rtsv7M3_T_le_eabi.lib : autoinit.obj (.text)
                  0001fca0    0000006a                           : copy_decompress_rle.obj (.text)
                  0001fd0a    00000002     --HOLE-- [fill = 0]
                  0001fd0c    0000004c                           : cpy_tbl.obj (.text)
                  0001fd58    00000044                           : exit.obj (.text)
                  0001fd9c    0000003c                           : boot.obj (.text)
                  0001fdd8    0000001e     driverlib.lib : flash.obj (.text:NOROM_FlashProgram)
                  0001fdf6    0000001e                   : flash.obj (.text:NOROM_FlashSectorErase)
                  0001fe14    00000018     rtsv7M3_T_le_eabi.lib : args_main.obj (.text)
                  0001fe2c    00000014                           : _lock.obj (.text)
                  0001fe40    0000000e                           : copy_decompress_none.obj (.text:decompress:none)
                  0001fe4e    0000000c     driverlib.lib : cpu.obj (.text:NOROM_CPUcpsie)
                  0001fe5a    0000000c     rtsv7M3_T_le_eabi.lib : copy_zero_init.obj (.text:decompress:ZI)
                  0001fe66    00000006                           : copy_decompress_rle.obj (.text:decompress:rle24)
                  0001fe6c    00000004                           : pre_init.obj (.text)

.const     0    0001fe70    00000006     
                  0001fe70    00000006     ext_flash.obj (.const:.string)

.cinit     0    0001fe78    00000038     
                  0001fe78    00000010     (.cinit..data.load) [load image, compression = rle]
                  0001fe88    0000000c     (__TI_handler_table)
                  0001fe94    00000004     --HOLE-- [fill = 0]
                  0001fe98    00000008     (.cinit..bss.load) [load image, compression = zero_init]
                  0001fea0    00000010     (__TI_cinit_table)

.init_array 
*          0    0001f000    00000000     UNINITIALIZED

.ccfg      0    0001ffa8    00000058     
                  0001ffa8    00000058     ccfg_appBLE.obj (.ccfg:retain)

.bss       0    20000000    00001010     UNINITIALIZED
                  20000000    00001000     bim_main.obj (.bss:pgBuf)
                  20001000    00000010     (.common:imgInfo)

.data      0    20001010    00000014     UNINITIALIZED
                  20001010    00000008     rtsv7M3_T_le_eabi.lib : _lock.obj (.data)
                  20001018    00000008                           : exit.obj (.data)
                  20001020    00000004                           : stkdepth_vars.obj (.data)

.TI.bound:resetVectors 
*          0    00000000    0000003c     
                  00000000    0000003c     vector_table.obj (.TI.bound:resetVectors)

.TI.noinit 
*          0    20000000    00000000     UNINITIALIZED

.TI.persistent 
*          0    20001010    00000000     UNINITIALIZED

.stack     0    20002bfc    00000100     UNINITIALIZED
                  20002bfc    00000100     --HOLE--


LINKER GENERATED COPY TABLES

__TI_cinit_table @ 0001fea0 records: 2, size/record: 8, table size: 16
	.data: load addr=0001fe78, load size=00000010 bytes, run addr=20001010, run size=00000014 bytes, compression=rle
	.bss: load addr=0001fe98, load size=00000008 bytes, run addr=20000000, run size=00001010 bytes, compression=zero_init


LINKER GENERATED HANDLER TABLE

__TI_handler_table @ 0001fe88 records: 3, size/record: 4, table size: 12
	index: 0, handler: __TI_decompress_rle24
	index: 1, handler: __TI_decompress_none
	index: 2, handler: __TI_zero_init


GLOBAL SYMBOLS: SORTED ALPHABETICALLY BY Name 

address   name                    
-------   ----                    
0001fbd5  BLS_close               
0001fc19  BLS_erase               
0001fbc3  BLS_init                
0001fbdd  BLS_read                
0001fbfb  BLS_write               
0001f001  BaseLoader_start        
0001f393  Bim_checkImages         
0001f35f  Bim_safeStart           
0001fd59  C$$EXIT                 
0001fe4f  NOROM_CPUcpsie          
0001fdd9  NOROM_FlashProgram      
0001fdf7  NOROM_FlashSectorErase  
UNDEFED   SHT$$INIT_ARRAY$$Base   
UNDEFED   SHT$$INIT_ARRAY$$Limit  
20002cfc  __STACK_END             
00000100  __STACK_SIZE            
20002cfc  __STACK_TOP             
0001fea0  __TI_CINIT_Base         
0001feb0  __TI_CINIT_Limit        
0001fe88  __TI_Handler_Table_Base 
0001fe94  __TI_Handler_Table_Limit
0001fc35  __TI_auto_init          
20001018  __TI_cleanup_ptr        
0001fe41  __TI_decompress_none    
0001fe67  __TI_decompress_rle24   
2000101c  __TI_dtors_ptr          
0001fe78  __TI_static_base__      
0001fe5b  __TI_zero_init          
0001fb49  __aeabi_memclr          
0001fb49  __aeabi_memclr4         
0001fb49  __aeabi_memclr8         
0001faad  __aeabi_memcpy          
0001faad  __aeabi_memcpy4         
0001faad  __aeabi_memcpy8         
0001fb4b  __aeabi_memset          
0001fb4b  __aeabi_memset4         
0001fb4b  __aeabi_memset8         
ffffffff  __binit__               
ffffffff  __c_args__              
0001ffa8  __ccfg                  
20002bfc  __stack                 
0001fe15  _args_main              
0001fd9d  _c_int00                
20001010  _lock                   
0001fe3b  _nop                    
0001fe33  _register_lock          
0001fe2d  _register_unlock        
0001fe6d  _system_pre_init        
20001014  _unlock                 
0001fd5d  abort                   
ffffffff  binit                   
0001fa41  bspSpiClose             
0001f965  bspSpiFlush             
0001f97d  bspSpiOpen              
0001f915  bspSpiRead              
0001f8d3  bspSpiWrite             
0001fd0d  copy_in                 
0001fc33  excHandler              
0001fd65  exit                    
0001f65b  extFlashClose           
0001f7a5  extFlashErase           
0001f637  extFlashOpen            
0001f667  extFlashRead            
0001f855  extFlashTest            
0001f6e5  extFlashWrite           
20001000  imgInfo                 
0001f44d  main                    
20001020  main_func_sp            
0001faad  memcpy                  
0001fb51  memset                  
20000000  pgBuf                   
00000000  resetVectors            


GLOBAL SYMBOLS: SORTED BY Symbol Address 

address   name                    
-------   ----                    
00000000  resetVectors            
00000100  __STACK_SIZE            
0001f001  BaseLoader_start        
0001f35f  Bim_safeStart           
0001f393  Bim_checkImages         
0001f44d  main                    
0001f637  extFlashOpen            
0001f65b  extFlashClose           
0001f667  extFlashRead            
0001f6e5  extFlashWrite           
0001f7a5  extFlashErase           
0001f855  extFlashTest            
0001f8d3  bspSpiWrite             
0001f915  bspSpiRead              
0001f965  bspSpiFlush             
0001f97d  bspSpiOpen              
0001fa41  bspSpiClose             
0001faad  __aeabi_memcpy          
0001faad  __aeabi_memcpy4         
0001faad  __aeabi_memcpy8         
0001faad  memcpy                  
0001fb49  __aeabi_memclr          
0001fb49  __aeabi_memclr4         
0001fb49  __aeabi_memclr8         
0001fb4b  __aeabi_memset          
0001fb4b  __aeabi_memset4         
0001fb4b  __aeabi_memset8         
0001fb51  memset                  
0001fbc3  BLS_init                
0001fbd5  BLS_close               
0001fbdd  BLS_read                
0001fbfb  BLS_write               
0001fc19  BLS_erase               
0001fc33  excHandler              
0001fc35  __TI_auto_init          
0001fd0d  copy_in                 
0001fd59  C$$EXIT                 
0001fd5d  abort                   
0001fd65  exit                    
0001fd9d  _c_int00                
0001fdd9  NOROM_FlashProgram      
0001fdf7  NOROM_FlashSectorErase  
0001fe15  _args_main              
0001fe2d  _register_unlock        
0001fe33  _register_lock          
0001fe3b  _nop                    
0001fe41  __TI_decompress_none    
0001fe4f  NOROM_CPUcpsie          
0001fe5b  __TI_zero_init          
0001fe67  __TI_decompress_rle24   
0001fe6d  _system_pre_init        
0001fe78  __TI_static_base__      
0001fe88  __TI_Handler_Table_Base 
0001fe94  __TI_Handler_Table_Limit
0001fea0  __TI_CINIT_Base         
0001feb0  __TI_CINIT_Limit        
0001ffa8  __ccfg                  
20000000  pgBuf                   
20001000  imgInfo                 
20001010  _lock                   
20001014  _unlock                 
20001018  __TI_cleanup_ptr        
2000101c  __TI_dtors_ptr          
20001020  main_func_sp            
20002bfc  __stack                 
20002cfc  __STACK_END             
20002cfc  __STACK_TOP             
ffffffff  __binit__               
ffffffff  __c_args__              
ffffffff  binit                   
UNDEFED   SHT$$INIT_ARRAY$$Base   
UNDEFED   SHT$$INIT_ARRAY$$Limit  

[72 symbols]

map file of BIM

Best regards

Harald

0 svendbt over 10 years ago in reply to Harald Ilg

TI__Mastermind 29650 points

Hi Harald,

The ccfg_appBLE.c should have been excluded from the SensorTag in the OAD build as is the case for IAR. You can simply exclude the one in the SensorTag from the build.

In page 0 the BIM project will put a set of reset vectors at page 0 and put the BIM image in page 31. The reset vectors from the BIM image are not used when merging the images, only for debugging as far as I can see.

Having BIM in page 0 would prevent you from upgrading this page as you cannot execute code from the location you are erasing..

Regards,
Svend

0 Harald Ilg over 10 years ago in reply to svendbt

Genius 3060 points

Hy Sven,

svendbt said:

In page 0 the BIM project will put a set of reset vectors at page 0 and put the BIM image in page 31. The reset vectors from the BIM image are not used when merging the images, only for debugging as far as I can see.
Having BIM in page 0 would prevent you from upgrading this page as you cannot execute code from the location you are erasing..

This is probably true for the SensorTag way of OAD, right? But I observe this for the SimpleBLEPeripheral project. Could you maybe send me map files of the Application, Stack and BIM projects of a successfully built SBP with OAD project? I would expect BIM on page 0, Application on page 1...x, Stack on page x ... 30 and ccfg on page 31. OS is run from Flash.

For the Sensor Tag way of OAD I expect Application on page 0...x, Stack on x ... 30 and BIM and ccfg on page 31, OS in ROM.

Is this correct?

Harald

0 Aslak N. over 10 years ago in reply to Harald Ilg

TI__Mastermind 23440 points

Hi,

Feel free to follow the SensorTag project's way of doing OAD. The CCS project is perhaps misnamed, as it's really FlashROM.
* Linker file: cc26xx_ble_app_oad.cmd
* Linker define: APP_BASE=0x00000
* appBLE.cfg uses ROM + M3Hwi.resetVectorAddress = 0x0;
* OAD profile from Profiles\OAD\CC26xxST\oad.c and Profiles\OAD\CC26xxST\oad_target_externalFlash.c

The BIM project is also a bit different here;
* Build configuration FlashOnly_SensorTag -> precompiler define KEEP_INTVECS is not defined.

This should put BIM (not really BIM any more, just BaseLoader, in sector 31 along with CCFG and leave Sector 0 free.

Note that the baseloader must be called from OAD when complete instead of reset. This is done by OAD\CC26xxST\oad_target_externalFlash.c :: OADTarget_systemReset().

There are maybe more details that I've forgot, but this should get you started.

Best regards,
Aslak

0 Harald Ilg over 10 years ago in reply to Aslak N.

Genius 3060 points

Hy,
thanks for this confirmation. I think I got the firmware part up and running. At least, the "BIM" now maps to sector 31, the application boots alright etc.
I am running into next issue now: Apparently, the data that is transferred from either Device Monitor or Sensor Tag App is different. I observe inplausible data coming in when using the Device Monitor to OAD my device. Is that correct? Is the protocol different for the SBP and the SensorTag way of OADing? In the SensorTag app, my device is not listed any more, because it has a different advertising name. What would be a good OAD "master" to send the correct data to my device?
Regards
Harald

0 Aslak N. over 10 years ago in reply to Harald Ilg

TI__Mastermind 23440 points

Hi,

The latest DevMon should be a good master, as long as you use HEX file as input.

The length, crc and start address for the image (which is sent to the Identify characteristic) is calculated by DevMon based on the hex file. One thing to note is that DevMon rounds up the size to the next whole page/sector.

The SensorTag app probably always selects 0x0000 as the location the .bin file should be copied to, which is true in your case also, but not for SimpleBLEPeripheral where it is 0x1000 (0x400 words)

Aslak

Bluetooth®︎

Bluetooth forum

Running out of flash when implementing Off chip OAD in CC2640