CCS/RM46L852: Burning a code in CCS RM46.

Hello Hassan,

If you didn't use the memory swap feature defined in BMMCR1, the program memory (flash) starts at address 0x00000000. The "load program" in CCS will burn your code to the flash starting at 0x0, and the code will reside in the flash until you erase the flash.

Regards,
QJ

Hi,

I just made a project as it is defined in Halcogen examples.I dont have any idea about BMMCR1.Can you guide me how to do that? thanks

Hello Hassan,

You don't need this feature. The CCS should compile/linker the HalCoGen generated project without any problem. After board is connected through JTAG, using "load program" (under RUN dropdown menu) to load the *.out file, the CCS will program the code to flash rather than SRAM. The flash content will be there until you erase the flash.

Which CCS version are you using?

Regards,
QJ

I am using CCS 6.1.3. I posted my sys_link.cmd file in the CCS forum and they said your code, constants and init are all going into flash. ä

But it isnt working.

also i m getting this ...

"CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0 due to System Reset"

I am experiencing a similar issue with a RM46L852ZWTT on an HDK board. I had two different builds working yesterday.

When I added code today (some FreeRTOS and some other stuff), I started seeing the [Address 0x0 due to system reset] messages.

I am open to hearing solution steps.

Can you check you memory map and make sure it is setup for normal operation. i.e., not setup for execution from RAM.

Also, to be certain, under scripts run the gel script "Target_Flash_to_0x0" to ensure the device is setup up for execution from Flash not RAM.

You can also RUN the gel script "CCS_MemMap_FLASH_at_0x0"

The behavior appeared to change/fail after adding more code. Am I near some physical limit for the RM46 HDK

In using three diagnostic steps:
Setting the Debugger to verbose.
Sometimes using the DEMO tool to reset the device.
Adding a FILL statement to memory settings.

I have started seeing a consistent failure during debug download

CortexR4: Erasing Flash Bank 0, Sector 14
CortexR4: Verifying Flash @ Address 0x000F8630 of length 0x00007FF0
CortexR4: Writing Flash @ Address 0x00100620 of Length 0x00007ff0
CortexR4: Verifying Flash @ Address 0x00100620 of length 0x00007FF0
CortexR4: Writing Flash @ Address 0x00108610 of Length 0x00007ff0
CortexR4: Verifying Flash @ Address 0x00108610 of length 0x00007FF0
CortexR4: Writing Flash @ Address 0x00110600 of Length 0x00007ff0
CortexR4: Verifying Flash @ Address 0x00110600 of length 0x00007FF0
CortexR4: Writing Flash @ Address 0x001185f0 of Length 0x00007ff0
CortexR4: Erasing Flash Bank 0, Sector 15
CortexR4: Verifying Flash @ Address 0x001185F0 of length 0x00007FF0
CortexR4: Writing Flash @ Address 0x001205e0 of Length 0x00007ff0
CortexR4: Verifying Flash @ Address 0x001205E0 of length 0x00007FF0
CortexR4: Writing Flash @ Address 0x001285d0 of Length 0x00007ff0
CortexR4: Verifying Flash @ Address 0x001285D0 of length 0x00007FF0
CortexR4: Writing Flash @ Address 0x001305c0 of Length 0x00007ff0
CortexR4: Verifying Flash @ Address 0x001305C0 of length 0x00007FF0
CortexR4: Writing Flash @ Address 0x001385b0 of Length 0x00007ff0
CortexR4: File Loader: Memory write failed: The address 0x14059f does not map to a valid Flash Bank
CortexR4: GEL: File: C:\Users\994607\workspace_v7\NeilRM46\Debug\NeilRM46.out: Load failed.
CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0 due to System Reset

Hello,

The RM46 has 1.25MBytes of flash. The starting and end address are 0x00 and 0x14_0000. The address 0x14059f is out of the range. You may use a wrong linker command file.

/*----------------------------------------------------------------------------*/

/* Linker Settings                                                            */

--retain="*(.intvecs)"

/* Memory Map                                                                 */

MEMORY{

   VECTORS (X)  : origin=0x00000000 length=0x00000020

   FLASH0  (RX) : origin=0x00000020 length=0x0013FFE0

   STACKS  (RW) : origin=0x08000000 length=0x00001300

   RAM     (RW) : origin=0x08001300 length=0x0002ED00

}

/*----------------------------------------------------------------------------*/

/* Section Configuration                                                      */

SECTIONS{

   .intvecs : {} > VECTORS

   .text    : {} > FLASH0

   .const   : {} > FLASH0

   .cinit   : {} > FLASH0

   .pinit   : {} > FLASH0

   .bss     : {} > RAM

   .data    : {} > RAM

}

Yes, I see what you are saying. Supporting FreeRTOS appears to require a change to those settings to support a KERNEL area. It is very good to know the 0x140000 limit in flash. Is there a good way to break up the flash limit for larger programs?

Neil,

You can check the code size of your code in the .map file generated during the build and match this against the datasheet of the device you are using. If you are using the FILL option, it will fill the entire flash as defined in your linker command file memory sections. These should also match the defined flash size as defined in the applicable datasheet. As noted in the other thread, please also confirm that the correct device is selected in your target configuration.

I corrected the command file.  I am still seeing the reset after flash is initialize, but I am not thinking (now that the command file is correct) that the reset happens due to flash.  It may be happening after it is correctly set.

CortexR4: Writing Flash @ Address 0x0013fda0 of Length 0x00000260

CortexR4: Verifying Flash @ Address 0x0013FDA0 of length 0x00000260

CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0 due to System Reset

Here is portion of my memory map, which may have clues at the bottom. 

******************************************************************************
                  TI ARM Linker PC v16.12.0                   
******************************************************************************
>> Linked Wed Jul 12 08:52:07 2017

OUTPUT FILE NAME:   <NeilRM46.out>
ENTRY POINT SYMBOL: "_c_int00"  address: 0000fa70

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  VECTORS               00000000   00000020  00000000  00000020     X
  FLASH0                00000020   0013ffe0  0013ffe0  00000000  R  X  ffffffff
  STACKS                08000000   00001300  00000000  00001300  RW 
  RAM                   08001300   0002ed00  00004677  0002a689  RW 

SEGMENT ALLOCATION MAP

run origin  load origin   length   init length attrs members
----------  ----------- ---------- ----------- ----- -------
00000020    00000020    0013ffe0   0013ffe0    r-x
  00000020    00000020    00011bec   00011bec    r-x .text
  00011c0c    00011c0c    00000bbe   00000bbe    r-- .const
  000127ca    000127ca    00000006   00000006    r-- $fill000
  000127d0    000127d0    000001c8   000001c8    r-- .cinit
  00012998    00012998    0012d668   0012d668    r-- $fill001
08001300    08001300    00004678   00000000    rw-
  08001300    08001300    00002000   00000000    rw- .kernelHEAP
  08003300    08003300    00001114   00000000    rw- .bss
  08004414    08004414    00000d63   00000000    rw- .data
  08005178    08005178    00000800   00000000    rw- .sysmem

                          
08005168  can_buf_rx_head                            
08005169  can_buf_rx_cnt                             
0800516a  can_buf_tx_tail                            
0800516b  can_buf_tx_cnt                             
0800516c  MaxSaved                                   
08005178  _sys_memory                                
ffffffff  __TI_pprof_out_hndl                        
ffffffff  __TI_prof_data_size                        
ffffffff  __TI_prof_data_start                       
ffffffff  __binit__                                  
ffffffff  __c_args__                                 
ffffffff  binit                                      
UNDEFED   SHT$$INIT_ARRAY$$Base                      
UNDEFED   SHT$$INIT_ARRAY$$Limit                     

[681 symbols]

Great to hear Neil. Feel free to verify your answer so the thread will be officially closed.

No problem, Neil. Hopefully your experience and solution can also help the original poster.