Programming TMS570 (MCBTM570) via XDS100v2

This may not be your problem but it is something I have come across before. When hitting the little bug button, CCS does a build of code.  Thus the time taken includes this build (you can see it on the console).  The worst thing however is that if you have freshly run CCS, it does a full Rebuild of code and this can take minutes, depending on your program.  This means from the time you hit the bug to it being ready can get rather long.

If you dont already, I would try building your code separately from hitting the little bug button.  This should mean loading Debug should be roughly constant each time.  If it is still 4minutes long then you are likely to have some problem somewhere else unfortunately.

Thanks,

Tim

Jairo,Tim,

Programming Flash using  XDS100v2 is relatively slower than XDS510USB. The XDS100v2 is used here for board simplicity .

You can follow few tips in CCS4 , like disabling verification and  enabling sector programming to get the the programming done relatively earlier.

Regards,

Pratip

Tim, I've noticed that but unfortunately the problem seems to be elsewhere.  My project takes no more than 10 seconds to build.  

Pratip, it sounds like using the XDS100v2 is not very practical when developing code and testing it on the target.  Bummer.  Along with the XDS510USb, what other programmers are compatible with this board and CCS?

Also, for debugging code, can writing to flash be avoided altogether and have the emulator write straight to RAM?  Seems like this would be a faster approach

SECTIONS
{
    .intvecs : {} > VECTORS
    .text    : {} > FLASH0 | FLASH1 | FLASH2 | FLASH3
    .const   : {} > FLASH0 | FLASH1 | FLASH2 | FLASH3
    .cinit   : {} > FLASH0 | FLASH1 | FLASH2 | FLASH3
    .pinit   : {} > FLASH0 | FLASH1 | FLASH2 | FLASH3
    .bss     : {} > RAM
    .data    : {} > RAM

}

SECTIONS
{
    .intvecs : {} > RAM
    .text    : {} > RAM
    .const   : {} > RAM
    .cinit   : {} > RAM
    .pinit   : {} > RAM
    .bss     : {} > RAM
    .data    : {} > RAM

}

Jairo,

Have a look at this and let me know if it helps : http://processors.wiki.ti.com/index.php/Quick_Tips

The TMS570 Microcontroller USB Kit is quite compact and affordable and gets you quickly started. We may need to make the tools setup based on the requirement.

Regards,
Pratip

Pratip, where do I find the script that can swap the RAM to be at offset 0?  Is this something that can be done in CCS?  

In my cmd file I know I can redefine RAM to be at offset 0, but that doesn't re-arrange the physical address of RAM in the bus, or does it? 

-- edit --

I have an issue regarding linking all the code sections to RAM.  When I debug the project the stack stays in:

0 _c_int00() at sys_startup.c:408 0x08004bfc

If I had to guess I would say that my application doesn't like having .intvecs in RAM.    However, editing the cmd file to link .intvecs back in the VECTORS memory as such:

SECTIONS
{
	.intvecs : {} > VECTORS
	...
}

returns an error when compiling.  The error reads:

"../sys_link_dev.cmd", line 45: error: placement fails for object ".intvecs",
   size 0x20 (page 0).  Available ranges:
   VECTORS      size: 0x20         unused: 0x20         max hole: 0x20      
error: errors encountered during linking; "HelloWorld.out" not built

It looks like the size of VECTORS is large enough (0x2)  for the object (0x20).  

Any suggestions?

Jairo,

It's  just the mapping that can be swapped. In the CCS4 script tab you should see this option.

This script interacts with the hardware to remap the 0x000000 address lines to RAM instead of Flash.

Let me know if you dont see this.

Best Regards,

Pratip

I read about this in the TRM (spnu489) and did find these menus in CCS.  I couldn't find these because these menus aren't available until you enter a debug session.

Anyway, regarding the Scripts menu I have a few questions:

1. Is there any documentation that captures what specifically these do and or how?  
2. Is there source code for these scripts?   
3. Also, there are two menus under Scripts and they both read like they do a similar thing.  If there's no documentation for these, do you mind explaining what the difference is between the two?
4. Also, is the swap retained after a power cycle or do I have to execute the script each time I power the board?  Do I have to do it each time I enter a debug session?

Linker Cmd

Regarding the linker command file, this is how I wrote it.  Assuming that I was able to swap the flash/ram mapping, does this look correct?

--retain="*(.intvecs)"

MEMORY
{
    VECTORS  (X)  : origin=0x00000000 length=0x00000020
    STACKS   (RX) : origin=0x00000020 length=0x00001300
    RAM	     (XRW): origin=0x00001320 length=0x00027FE0
}


SECTIONS
{
    .intvecs : {} > VECTORS
    .text    : {} > RAM
    .const   : {} > RAM
    .cinit   : {} > RAM
    .pinit   : {} > RAM
    .bss     : {} > RAM
    .data    : {} > RAM
    .sysmem  : {} > RAM

}

Thanks again,

Jairo,

The source code of the scripts are in your gel file.

The 1st menu is to map the address to flash or RAM. The 2nd one is to swap the RAM and flash. Normally when you switch RAM to 0x00, CCS4 will do the reset, and the 0x00 is still mapped as ROM, so you need re-map it to RAM. Otherwise you will get error when loading program. 

Your CMD looks fine.

Regards,

QJ

Jairo,

You will not find the scripts tab enabled until you launch the debugger session because the script needs to talk to the micro and is possible only after connecting to the micro through a debugger session.

Regards,

Pratip

Hello Jairo,

I had same issue with debugger, So I tried following you and changed Sys_Link.cmd file.

But this is the error which I got when I was trying to debug "sys_link.cmd", line 47: error:    placement fails for object ".intvecs", size 0x20 (page 0).  Available
   ranges:
   VECTORS      size: 0x20         unused: 0x20         max hole: 0x20     
sys_link.cmd", line 48: error:    placement fails for object ".text", size 0xadfc (page 0).  Available ranges:   RAM          size: 0x6d00       unused: 0x68bc       max hole: 0x68bc   
error: errors encountered during linking;

Is there anything which I am missing before debug?

Thanks

Swetha,

You may need to increase the size of the sections.

In linker command file replace 0x6d00 with 0xADFC or or higher value.

Regards,

Pratip

Hello Pratip,

I did change the size to 0xADFC.It still shows error at line47 of cmd file."Placement Fails for object".intvecs", size 0x20 (page 0) .

Available ranges: VECTORS  size :0x20     unused:0x20         maxhole: 0x20

error encountered during linking file.

How large can be the size?

Thanks

Swetha

Swetha,

You may send me the complete command file, lets see if there is any overlap.

Theoretically this value could be anything upto 0xFFFFFFFF , technically this should match your micro's memory map.

Regards,

Pratip

Hello Pratip

This is the stuff I have in my file.

/* USER CODE BEGIN (0) */
/* USER CODE END */

/*----------------------------------------------------------------------------*/
/* Linker Settings                                                            */

-l rtsv7R4_T_be_v3D16_eabi.lib

--retain="*(.intvecs)"

/* USER CODE BEGIN (1) */
/* USER CODE END */

/*----------------------------------------------------------------------------*/
/* Memory Map                                                                 */

MEMORY
{
    VECTORS (X)  : origin=0x00000000 length=0x00000020
    FLASH0  (RX) : origin=0x00000020 length=0x001FFFE0
/*    FLASH1  (RX) : origin=0x00080000 length=0x00080000
    FLASH2  (RX) : origin=0x00100000 length=0x00080000
    FLASH3  (RX) : origin=0x00180000 length=0x00080000
    STACKS  (RW) : origin=0x00000000 length=0x00001300*/
    RAM     (RW) : origin=0x08000000 length=0x00006D00

/* USER CODE BEGIN (2) */
/* USER CODE END */
}

/* USER CODE BEGIN (3) */
/* USER CODE END */

/*----------------------------------------------------------------------------*/
/* Section Configuration                                                      */

SECTIONS
{
    .intvecs : {} > VECTORS
    .text    : {} > RAM /*FLASH0 | FLASH1 | FLASH2 | FLASH3*/
    .const   : {} > RAM /*> FLASH0 /*| FLASH1 | FLASH2 | FLASH3*/
    .cinit   : {} > RAM /*> FLASH0 /*| FLASH1 | FLASH2 | FLASH3*/
    .pinit   : {} > RAM /*> FLASH0 /*| FLASH1 | FLASH2 | FLASH3*/
    .bss     : {} > RAM /*FLASH0 /*RAM*/
    .data    : {} > RAM /*FLASH0 /*RAM*/

/* USER CODE BEGIN (4) */
/* USER CODE END */
}

/* USER CODE BEGIN (5) */
/* USER CODE END */

/*----------------------------------------------------------------------------*/
/* Misc                                                                       */

/* USER CODE BEGIN (6) */
/* USER CODE END */

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

Thanks

Swetha

Swetha,

Are you running the code from Flash or RAM ?

If RAM it should be as follows:

    VECTORS (X)  : origin=0x00000000 length=0x00000020
    RAM     (RW) : origin=0x00000020 length=0x00008000

Remember to Swap the mapping using the scripts.

After swapping the memory map, the address 0x08000000 would become Flash.

Regards,

Pratip

Hi Pratip,

I'm still unable to run from RAM.  I've tried swapping the memory  map to no avail.  I will try to explain every step I'm taking and see if you can identify where the issue is.  

Thanks.

My linker script/cmd file:

sys_link_dev.cmd said:

MEMORY
{
    VECTORS  (X)  : origin=0x00000000 length=0x00000020
    STACKS   (RX) : origin=0x00000020 length=0x00001300
    RAM	     (XRW): origin=0x00001320 length=0x00027FE0
}

SECTIONS
{
    .intvecs : {} > VECTORS
    .text    : {} > RAM
    .const   : {} > RAM
    .cinit   : {} > RAM
    .pinit   : {} > RAM
    .bss     : {} > RAM
    .data    : {} > RAM

    .sysmem  : {} > RAM
}

First, I compile the project successfully.

Console output said:

...

'Finished building target: MyProject.out'

' '

Build complete for project MyProject

Then I hit "Debug Active Project" under "Target".  The debugger connects to the target, followed by a load:

After a few moments the debugger session is suspended on main()

And the Console outputs the following:

CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0

This is where I execute the GEL scripts:  Scripts >TMS570LS20216 Memory Switch > Target_RAM_to_0x0.  The Console then outputs the following message:

R4: GEL Output: NOTES:
	The Flash/RAM memory adresses of the device will be switched.
CortexR4: GEL Output: 	At the end of this routine the device will be reset.
CortexR4: GEL Output: 	
This might lead to an popup message stating an error!
CortexR4: GEL Output: 	Just re-connect after the message appeared.
CortexR4: GEL Output: 	Memory swap is done.
CortexR4: GEL Output: 	In case a popup message appaered, re-connect to the device.

I don't receive a popup message so I do not attempt to re-connect after executing the script.  As far as I can tell the target is still connected.  

I then hit "Run" and nothing happens.  

At this point I issue a "CPU Reset" and  although I am able to verify that some of the code executes, my application terminates unexpectedly.  If I were to guess I would say there is an issue with interrupts... 

Any suggestions/comments are appreciated.

Thanks

Swetha Reddy said:

But when I open CCSV4 I see Scripts menu inactive

Swetha, Pratip addressed you question earlier in this thread:

Pratip said:

You will not find the scripts tab enabled until you launch the debugger session because the script needs to talk to the micro and is possible only after connecting to the micro through a debugger session.

Also, you may find this useful in understanding the "Scripts" menu:

http://processors.wiki.ti.com/index.php/GEL

Jairo,

I launched debug session but my device is in disconnected status. I checked my configuration and everything seems correct but it still says device not connected.

What  may be the reason for this?

Thanks

Swetha

Swetha, 

Off the top of my head possible reasons for your issue are the xds100v2 drivers, ccs project setup, among other things.  I would strongly suggest you start a new thread to address your issues.  Having 2 conversations/issues on the same thread can get confusing and can lead to un-answered questions.

Take a look at this wiki for additional info:

http://processors.wiki.ti.com/index.php/Category:TMS570

Swetha,

The general sequence should be :

Step 1. Connect debugger  . (You can confirm this by opening a memory window and writing into a RAM location 0x08000000)

Step 2. Run RAM swap script .by clicking through the script tab.((You can confirm this by opening a memory window and writing into a remapped RAM location 0x000000)

Step 3. Compile and load your code. (Since you already have the RAM memory window open , have a look if RAM shows your code)

Let me know if the wiki link helps.

Let me know if you are stuck up with step 1 , I can elaborate on that.

We can start a new thread if you like to.

Regards,

Pratip

Swetha,

I'm not quite familiar with TESSY , but looks like a automation tool suitable for regression.

I haven't tried UDE over xds100 v2 , you need to check if the debugger supports it.

Regards,

Pratip

Hello Pratip,

I want to send you a document, can you say me the best way to attach it to you.

Thanks

Swetha

Swetha,

In the editor you need to use inser file icon to attache a file.

As shown below....

1856.TI_HelpDoc.docx

I did attached a document, Can you please look into that once.

Thanks

Swetha

Swetha,

The command file for you should be as follows :

MEMORY

{

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

    RAM     (RW) : origin=0x00000020 length=0x00080000

}

Probably in your ccs4 settings when you compile it automatically loads . So you may have to first disable automatic load.

After disabling this you can first connect the debugger do the swap and then compile and then load .

If you do not disable automatic load  you will encounter an error first time you enter debugger you may swap and and then rebuild and load ,

the second time it should go through.

Best Regards,

Pratip

Pratip,

Just to confirm, You said I can take the RAM origin from 0x00000020 and length 0x00080000.

In datasheet it says Flash origin= 0x00000000 length= 0x001FFFFF and for RAM it says origin = 0x08000000 length = 0x08027FFFF.

So can I still change as you mentioned ?

Thanks

Swetha

Pratip,

I was going through CCS and found GEL file.When I see that file it shows bydefalut the memory map is done to FLASH.

So can I change it to RAM if I have rights to change the GEL file.

Thanks

Swetha

Pratip,

When am loading after the swap it shows me below error

Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map.

I guess its talking abt ".text" section.

 What do u suggest?

Thanks

Swetha

Sweha,

After the swap are you able to manually write (a random data ) into the address 0x00000 through the memory window ?

If this happens the CCS should not complain.

And may be for simplicity you can start with a small piece of code , may be just a boot code.

Best Regards,

Pratip

Hello Pratip,

I`m now able to load in ram but in overall it doesn`t seem to speed up the load process that much.

I guess the main reason is that the rebuilt/all process is slow in my case, probably due to the RTSC tool.

Question:

Once you pause the running programm and change something in the code, do I have to runs the two scripts again, rebuilt/all and load the code, each time?

Why rebuilt/all, is built could be ok?

It appears that my loading process works 50% of the time and I don`t know why.

My platform is evmTMS570L20216

Simon

Simon,

When you change something you may have to just build. Rebuild all is not required.

If you are using CCSv4 , for spending less time on Flash programming time, follow the below suggested settings:

In the flash settings there is a section for Erase Options.  There are 3 options:

• Entire Flash
• Necessary Sectors Only (for Program Load)
• Selected Sectors only <- when you select this one it enables some more options for selecting which banks to erase

Try changing the option to the second one.

Regards,

Pratip