This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I am trying to use the SCI boot witht he TMS320F28035. I have written a simple program to blink and LED on my board. This program runs out of RAM. If I want to load this program via the SCI boot using hyperterminal what is the correct hex2000 commands to create the proper bin file to send to the bootloader using hyperterminal?
I tried the hex2000 - sci8 -boot -b option and it seems to create the proper bin file, but when I send the file via the sci port to the 28035 the program does not run (LED does not blink). If I run the program via the JTAG port all runs fine. Below is my 28035 linker cmd file contents. Is there something special I need to do in order for this to run when loaded via the SCI bootloader?
/* // TI File $Revision: /main/2 $ // Checkin $Date: February 20, 2009 15:34:01 $ //########################################################################### // // FILE: 28035_RAM_lnk.cmd // // TITLE: Linker Command File For 28035 examples that run out of RAM // // This ONLY includes all SARAM blocks on the 28035 device. // This does not include flash or OTP. // // Keep in mind that L0,L1,L2, and L3 are protected by the code // security module. // // What this means is in most cases you will want to move to // another memory map file which has more memory defined. // //########################################################################### // $TI Release: 2803x Internal Release 2 $ // $Release Date: November 11, 2008 $ //########################################################################### */ /* ====================================================== // For Code Composer Studio V2.2 and later // --------------------------------------- // In addition to this memory linker command file, // add the header linker command file directly to the project. // The header linker command file is required to link the // peripheral structures to the proper locations within // the memory map. // // The header linker files are found in <base>\DSP2803x_headers\cmd // // For BIOS applications add: DSP2803x_Headers_BIOS.cmd // For nonBIOS applications add: DSP2803x_Headers_nonBIOS.cmd ========================================================= */ /* ====================================================== // For Code Composer Studio prior to V2.2 // -------------------------------------- // 1) Use one of the following -l statements to include the // header linker command file in the project. The header linker // file is required to link the peripheral structures to the proper // locations within the memory map */ /* Uncomment this line to include file only for non-BIOS applications */ /* -l DSP2803x_Headers_nonBIOS.cmd */ /* Uncomment this line to include file only for BIOS applications */ /* -l DSP2803x_Headers_BIOS.cmd */ /* 2) In your project add the path to <base>\DSP2803x_headers\cmd to the library search path under project->build options, linker tab, library search path (-i). /*========================================================= */ /* Define the memory block start/length for the DSP2803x PAGE 0 will be used to organize program sections PAGE 1 will be used to organize data sections Notes: Memory blocks on F28035 are uniform (ie same physical memory) in both PAGE 0 and PAGE 1. That is the same memory region should not be defined for both PAGE 0 and PAGE 1. Doing so will result in corruption of program and/or data. L0 block is mirrored - that is it can be accessed in high memory or low memory. For simplicity only one instance is used in this linker file. Contiguous SARAM memory blocks can be combined if required to create a larger memory block. */ MEMORY { PAGE 0 : /* BEGIN is used for the "boot to SARAM" bootloader mode */ BEGIN : origin = 0x000000, length = 0x000002 RAMM0 : origin = 0x000050, length = 0x0003B0 RAML0L1 : origin = 0x008000, length = 0x000C00 RESET : origin = 0x3FFFC0, length = 0x000002 IQTABLES : origin = 0x3FE000, length = 0x000B50 /* IQ Math Tables in Boot ROM */ IQTABLES2 : origin = 0x3FEB50, length = 0x00008C /* IQ Math Tables in Boot ROM */ IQTABLES3 : origin = 0x3FEBDC, length = 0x0000AA /* IQ Math Tables in Boot ROM */ BOOTROM : origin = 0x3FF27C, length = 0x000D44 PAGE 1 : BOOT_RSVD : origin = 0x000002, length = 0x00004E /* Part of M0, BOOT rom will use this for stack */ RAMM1 : origin = 0x000480, length = 0x000380 /* on-chip RAM block M1 */ RAML2 : origin = 0x008C00, length = 0x000400 RAML3 : origin = 0x009000, length = 0x001000 } SECTIONS { /* Setup for "boot to SARAM" mode: The codestart section (found in DSP28_CodeStartBranch.asm) re-directs execution to the start of user code. */ codestart : > BEGIN, PAGE = 0 ramfuncs : > RAMM0 PAGE = 0 .text : > RAML0L1, PAGE = 0 .cinit : > RAMM0, PAGE = 0 .pinit : > RAMM0, PAGE = 0 .switch : > RAMM0, PAGE = 0 .reset : > RESET, PAGE = 0, TYPE = DSECT /* not used, */ .stack : > RAMM1, PAGE = 1 .ebss : > RAML2, PAGE = 1 .econst : > RAML2, PAGE = 1 .esysmem : > RAML2, PAGE = 1 IQmath : > RAML0L1, PAGE = 0 IQmathTables : > IQTABLES, PAGE = 0, TYPE = NOLOAD /* Uncomment the section below if calling the IQNexp() or IQexp() functions from the IQMath.lib library in order to utilize the relevant IQ Math table in Boot ROM (This saves space and Boot ROM is 1 wait-state). If this section is not uncommented, IQmathTables2 will be loaded into other memory (SARAM, Flash, etc.) and will take up space, but 0 wait-state is possible. */ /* IQmathTables2 : > IQTABLES2, PAGE = 0, TYPE = NOLOAD { IQmath.lib<IQNexpTable.obj> (IQmathTablesRam) } */ /* Uncomment the section below if calling the IQNasin() or IQasin() functions from the IQMath.lib library in order to utilize the relevant IQ Math table in Boot ROM (This saves space and Boot ROM is 1 wait-state). If this section is not uncommented, IQmathTables2 will be loaded into other memory (SARAM, Flash, etc.) and will take up space, but 0 wait-state is possible. */ /* IQmathTables3 : > IQTABLES3, PAGE = 0, TYPE = NOLOAD { IQmath.lib<IQNasinTable.obj> (IQmathTablesRam) } */ } /* //=========================================================================== // End of file. //=========================================================================== */
MEMORY
{
PAGE 0 :
/* BEGIN is used for the "boot to SARAM" bootloader mode */
BEGIN :
origin = 0x000000, length = 0x000002
RAMM0 :
origin = 0x000050, length = 0x0003B0
RAML0L1 :
origin = 0x008000, length = 0x000C00
RESET :
origin = 0x3FFFC0, length = 0x000002
IQTABLES :
origin = 0x3FE000, length = 0x000B50 /* IQ Math Tables in Boot ROM */
IQTABLES2 :
origin = 0x3FEB50, length = 0x00008C /* IQ Math Tables in Boot ROM */
IQTABLES3 :
origin = 0x3FEBDC, length = 0x0000AA /* IQ Math Tables in Boot ROM */
BOOTROM :
origin = 0x3FF27C, length = 0x000D44
PAGE 1 :
BOOT_RSVD :
origin = 0x000002, length = 0x00004E /* Part of M0, BOOT rom will use this for stack */
RAMM1 :
origin = 0x000480, length = 0x000380 /* on-chip RAM block M1 */
RAML2 :
origin = 0x008C00, length = 0x000400
RAML3 :
origin = 0x009000, length = 0x001000
}
SECTIONS
{
/* Setup for "boot to SARAM" mode:
The codestart section (found in DSP28_CodeStartBranch.asm)
re-directs execution to the start of user code. */
codestart : > BEGIN, PAGE = 0
ramfuncs : > RAMM0 PAGE = 0
.text : > RAML0L1, PAGE = 0
.cinit : > RAMM0, PAGE = 0
.pinit : > RAMM0, PAGE = 0
.switch : > RAMM0, PAGE = 0
.reset : > RESET, PAGE = 0, TYPE = DSECT /* not used, */
.stack : > RAMM1, PAGE = 1
.ebss : > RAML2, PAGE = 1
.econst : > RAML2, PAGE = 1
.esysmem : > RAML2, PAGE = 1
IQmath : > RAML0L1, PAGE = 0
IQmathTables : > IQTABLES, PAGE = 0,
TYPE = NOLOAD
Gary,
The first thing is to make sure that the MCU is set to 'boot from SCI' (a specific set of GPIO pins should be set a certain way) and then there's a particular SCI boot loading procedure that occurs on power up. If you have not seen it before, the Boot ROM user's guide will have much more information on the procedure (figure 3 and 12 specifically):
http://www.ti.com/lit/sprugo0
My guess is that you're creating the boot file correctly but you haven't gotten the boot process right yet.
Let me know how this goes...
Thank you,
Brett
Thanks for the quick reply.
Yes, I know that I am entering the SCI boot mode properly. I set my terminal program for 9600 baud and I see the ‘A’ character as soon as I power up my board. This board already has my application program which runs a BLDC motor code in Flash. Once I see the ‘A’ I can send another A manualy and the board jumps to flash and begins running my flash code. This is as expected since I did not send the sci boot AA08. But if I power up my board and then get the ‘A” and then send my binary file generated by the hex2000 program, the program never seems to run (or the LED never starts blinking). My next step is to write my own PC based program to send the binary file, but before I do that I just wanted to verify that I was not doing anything wrong or missing a step.
Is this the correct command to convert my CCS4 out file >>> hex2000 - sci8 -boot -b
If I send the bin file as is to the SCI port once I get the ‘A’ from the SCI bootloader should it start running my code?
Is my linker cmd file attached above as a txt file ok as is to work?
I am basically trying to rule out as much as I can before I try to dig in and debug. If you could at least confirm I am following the proper steps to get hyperterminal to load my program, that would help.
Gary,
I might recommend trying -a (ascii format) for the time being so that I can help more. When I used hex2000 in the past to do bootloading, the options I used was:
"hex2000 {OutFile} -boot -sci8 -a"
After the 'A' comes back, you should be able to send you code. After the load finishes, the device should start running your code.
I don't see obvious wrong with your linker command file. Although some very old programmers may want your program code section in PAGE 0 and the data code sections in PAGE 1. Because you're able to debug this isn't a concern though
Thank you,
Brett
Thanks for the reply.
I did try the -a option and that does not seem to work as well. It seems to me that the asc file generated by the -a option would have to be converted to a binary file before a terminal program could send it to the SCI port. I would not think the SCI boot function would except the asc file as is. When you did this bofore did you use a program like hyperterminal or did you use a custom program that read the asc file and sent it out the serial port. If so, maybe your program did the conversion. My next step is to try and connect my JTAG while in sci boot mode and see if I can confirm what is acually loaded in RAM. It would be nice if TI had some examples of this for the 28035.
Gary,
It admittedly has been several years since I did that program, but yes, thinking about it again, I do believe my C# code did the translation.
One other useful tool here may be to load up the bootrom source and see if you can tell where things are getting hung up.
\controlSUITE\libs\utilities\boot_rom\2803x\2803x_boot_rom_v1\source\
Thank you,
Brett
Gary,
pleaes take a look at thie steps listed in the forum post, it should tell you how to use realterm to send data to the device over SCI.
http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/t/221572.aspx
hope it helps.
Best Regards
santosh
Thanks. This confirms that I am doing the correct steps. I can now focus better on what my problem is. It could be my terminal program is not sending the file correctly. I will try the realterm program or write one myself. Once I get it working, I will post back here to let everyone know what my problem was just in case somone runs into the same issue later.
I got it to work using the acual Hyperterminal program. Since Windows 7 no longer has Hyperterminal I downloaded a hypertermional freeware program that I found. It does not seem to send the file correclty. So, I installed the old Windows XE hyperterminal and downloaded the binary file using the "Send Text File" command. The Binary file was generated from my CCS4 out file using the hex2000 -boot -sci8 -b command.
Thanks for the help. I can now have a Merry Christmas!
nice, thanks for updating...Merry Christmas and Happy holidays
Best Regards
santosh
I would like to add one problem I found with the HyperTerminal program that I used above. My Boot loader program that I was writing to load into RAM was working fine by using Hyperterminal to load the binary file. However, at one point as I was adding features to my ram based boot loader, HyperTerminal would no longer load the binary file properly. I finally traced it to a variable in my boot code that was set to 0x0A0D hex. It seems that HyperTerminal was not sending these character because it interpreted them as carriage return, line feed.
Instead of trying to find another terminal program, I just wrote my own in C#. The C# program just sends the binary file as is and everything started working again. Just thought I would add this note in case anyone ever followed my steps for the C2000 boot loader. I recommend writing your own terminal program or finding a terminal program that you can trust.