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.

inquiry about boot loader of tms320F28335.

Other Parts Discussed in Thread: TMS320F28335

HI

I want to boot tms320f28335 from flash boot.

and i am refering to SPRU963A which is tms320x2833x boot rom reference guide.

you can see the figure 2-1. bootloader flow diagram.

i am wondering if  i can modify initboot function and selectbootmode function code.

and i can't find entry point in the 28335 example code. where can i find entry point?

 

 

  • Hello Choi,

    choi wonseok said:

    I want to boot tms320f28335 from flash boot.

    and i am refering to SPRU963A which is tms320x2833x boot rom reference guide.

    you can see the figure 2-1. bootloader flow diagram.

    i am wondering if  i can modify initboot function and selectbootmode function code.

    and i can't find entry point in the 28335 example code. where can i find entry point?

    You cannot modify the ROM bootloader.  The ROM is factory masked, and cannot be changed.

    The jump-to-flash destination address is given in the device datasheet, SPRS439m, Table 3-1, p.38.

    If you need a custom bootloader, what you can do is write your own and link it to flash sector A.  This is the flash sector where the jump-to-flash destination is.  When the ROM bootloader jumps to the destination address, you put a branch there that then jumps to your "Secondary" (custom) bootloader.  You can then do whatever you need to do.

    The idea here is that you do not re-flash sector A in the field, ever.  That way, your secondary bootloader is always intact and valid after a reboot, even if you were in the middle of field flash reprogramming.

    Regards,

    David

     

  • Thank you for your fast response.

    I understand what you are saying completely.

    But there is another I am wondering.

    I am planning to use flash boot from the application code composed hex code with hex2000.exe.

    28335 will receive hex code with UART COMMUNICATION.

    Following is the thing I am wondering.

     

    1.  I don’t know where I have to write application code(hex code) which flash sector.(sector A? B? C? H?....)

    And how do I handle rest of flash sector after program application code to flash?

     

          2.     Is it ok that I separate all sector to load address and run address?

    As I know, To use ramfunc, flash API, I must sort ramfunc section, flash section into load address, run address.

    Do I have to sort all section into load address, run address to access to flash sector while program running?

    For example, Program is running based on the flash A sector. And all section is based on the ram, flash A on the linker command file.

    After power on, Can Application program access to write flash sector A?

     

    I am very urgent.  i hope to receive your response as soon as possible

  • Choi,

    Just to make sure we're both thinking the same here, you are going to write two different code projects.  The first is your secondary bootloader.  It incorporates the flash API algorithms and is capable of re-flashing your main applications.  The secondary bootloader resides in flash sector A (and if it doesn't fit, you spill into sector B, etc.).  The second is your main application project, and it resides in any/all of the flash sectors except those used by the secondary bootloader.  The two projects are completely independent.  RAM can generally be re-used (both projects can use the same RAM, since they do not both run at the same time).  There is more information on this in a number of different forum threads.  Here are a couple of them:

    http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/255125/893359.aspx#893359

    http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/257010/900551.aspx#900551

    >>     2.     Is it ok that I separate all sector to load address and run address?

    Curious why you would want to do this.  Why not execute your code from flash, except perhaps the most critical code that you copy to and run from RAM?

    >> Do I have to sort all section into load address, run address to access to flash sector while program running?

    You only have to copy the flash API algorithms and I suppose the kernel that operates them to RAM.  The rest of your secondary bootloader can just stay in flash, as it is not running while you flash your main applications.

    Regards,

    David

  • Thank you for your fast response.

    What you understand is the little same that I want to design.

    I see the following document you send.

    http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/255125/893359.aspx#893359

    but this is not exact same environment I want.

     

    But the difference is exist.

    I don’t’ want that two project don’t exist in the internal flash simultaneously.

    The second bootloader project must do following.

    1.Using Flash API to write in flash sector B except those used by second bootloader.     

    All section related second bootloader is linked with sector A in the  cmd file.

    2.Receiving hex.file(main.app) through UART communication. Don’t’ think about that how can DSP receive uart message. Because we use FPGA.

     

    At this point. I have wondering.

         Cod start branch.asm is telling that  branch to the c_int00.

         Question 1 : what is in the entry point?  Flash start address to execute project?

         Question 2 : can I modify entry point?

     

    Second boot loader write hex.file(main.app) to flash sector B.

    And memory map will be composed that flash sector A(second boot loader), flash sector B(main.app).

    After power off. And power on.

    Question 3: How can dsp starting from sector B not A?

                  I think entry point still point  at flash sector A(second bootloader)? So I must modify cmd file or asm to jump to sector B(main.app) not A(second boot loader).

                  So how can dsp execute main.app not second bootloader?

                 

    I am urgent. I appreciate your fast response.

  • Choi,

    choi wonseok said:

         Cod start branch.asm is telling that  branch to the c_int00.

         Question 1 : what is in the entry point?  Flash start address to execute project?

    _c_int00 is the C environment initialization routine in the compiler RTS library.  It must run before you execute C code.  It sets up the stack, initializes all initialized global variables, and then calls main().

    choi wonseok said:

         Question 2 : can I modify entry point?

    I'm not certain what you are referring to when you say "entry point."  The ROM bootloader will jump to a known, hard address in flash, 0x33FFF6.  This is in flash sector A, and you cannot change this.  What code does after this is up to you.  As I suggested, you should have your secondary bootloader located in flash sector A so that it will run on a jump-to-flash bootload.

    choi wonseok said:

          Question 3: How can dsp starting from sector B not A?

          So how can dsp execute main.app not second bootloader?

    The ROM bootloader always jumps to 0x33FFF6.  The secondary bootloader then runs, and people will have it make a decision on whether there is a valid main app present in the flash (e.g using checksum or CRC).  If the main app is valid, the secondary bootloader will jump to the main app.  If invalid, the secondary bootloader will enter bootloading mode and download a new main app and flash it.

    Isn't this what you need to do?

    - David

  • I am appreciated your help.

    You are so kind that I can understand what you are saying.

    But there is something that I am wondering until now.

    Refer to the above attachment file

    Picture is drawing that I understand to the your account.

    I hope to receive your response.

  • Choi,

    From your attachment file:

    >> Question 1: How can I give control of device from second bootloader.c to main.c?
    >>             just use asm(“LB 0x33 0000”)(sector B hard address) in bootloader.c?

    Basically, yes.  You link your secondary bootloader to your main app in the same way the TI ROM bootloader is linked to your secondary bootloader.  Pick a hard address in the main app flash (probably use the last two 16-bit words in the flash for the main app to keep these words out of the way).  You link the section 'codestart' (from CodeStartBranch.asm) to this address using the linker .cmd file for the main app.  Then in your secondary bootloader, you do a asm("LB hard_address") when you want to transfer control to your main app.

    >> Question 2: How can second bootloader.c distinguish between procedure of updating main.c
    >>                     and giving control to main.c immediately.

    That is something you need to design.  As I mentioned previously, many people have the secondary bootloader run a validation on the main app in flash (e.g., checksum or CRC).  If the main app is valid, the secondary bootloader transfers control to the main app.  If invalid, the secondary bootloader enters the flash reprogramming procedure.  Also, you can put facilities in the main app such that when some particular command comes in from the user (e.g., via serial port), you also enter flash re-programming mode.  For example, you could have the main app zero out the validation value (e.g., checksum result or CRC result that is stored with the main app flash), and then cause a reset (e.g., write a bad value to the WDCR register).  Then, the secondary bootloader will check the main app and validation will fail.  It will then enter flash reprogramming.  There are other ways to do this.  I just suggested one possibility.

    Regards,

    David

  • is it possible to give me your phone number. i think that it's better to call you about this porblem.

  • don't think about reply... because i can' speak english well.

    i have wondering until now.

    You told me that 28335 have boot to flash sector A automatically after power on.

    and you told me that i must utilize asm("LB 0X33 0000") to transfer control to the Flash sector B(main.app).

    It means that do i have to write flash secotr A because of writing asm("LB 0X33 0000) while running second bootloader is running on the falsh sector A?

     

     

  • so this is why i want to seperate all section between load address and run address in the linker cmd file.

    To write main.app on the FLASH SECTOR A while bootloader is running on the FLASH SECTOR A.

  • Choi,

    Your english is just fine.  I understand your writings.

    choi wonseok said:

    It means that do i have to write flash secotr A because of writing asm("LB 0X33 0000) while running second bootloader is running on the falsh sector A?

    I'm not sure you are following what I outlined.  Your secondary bootloader goes in sector A.  The main app goes in the other sectors, and has no content in sector A.

    After a reset, the ROM bootloader jumps to sector A (address 0x33FFF6), and your secondary bootloader runs.  To do this, your secondary bootloader links its 'codestart' section to 0x33FFF6.  What your secondary bootloader then needs to do is decide if it should jump to your main app, or if it needs to flash your main app.  To do this, I suggested using a checksum or CRC to validate the main app.  If the secondary bootloader finds a valid main app in the other flash sectors (not sector A), it jumps to the main app.  You need to pick a hard address in the flash used by the main app, and link the main apps 'codestart' section there (from file CodeStartBranch.asm).  I would suggest using the last two addresses in sector B for this (0x337FFE and 0x337FFF).  This keeps them out of the way of the rest of your main app.  So, your secondary bootloader will execute asm(" LB 0x337FFE"); to transfer control to the main app.

    Again, there is NO PART of the main app in flash sector A.

    If the secondary bootloader does not find a valid main app, then it enters flash reprogramming mode and needs to download and flash the main app.  People will generally download the main app in small pieces, say 256, 512, or 1024 words at a time and flash that buffer.  This is because you cannot fit the entire main app into RAM all at once.

    Your entire secondary bootloader does not need to be moved to RAM.  To flash the main app, the portion of your secondary bootloader that does the flash erasing/programming needs to be running from RAM.  So, yes, you will need to copy the relevant sections from flash to RAM before running them.  People will typically also move the control kernel that manages the communication for the main app download, keeps track of the data buffering, and calls the flash APIs, etc., to RAM.  Just easier that way.

    You can also make facilities in your main app to trigger a main app update when some user command comes in over a communication link (for example).  To invalidate the main app, you could program the checksum/CRC result that is a data word(s) in the main app to all 0's.  This is done with the flash APIs, and would be incorporated into your main app (nothing to do with the secondary bootloader here).  After invalidating itself, the main app can reset the processor (e.g., write a bad value to the watchdog WDCR register) to force the secondary bootloader to run, or you could also just have the main app branch to 0x33FFF6 which is the start of the secondary bootloader in flash sector A.  The secondary bootloader will fail to find a valid main app, and therefore will enter main app reprogramming.

    Regards,

    David

  • hi

    i am very very thank you for your help.

    Following is what i understand about your comment.

    < Role of the code start branch.asm>

    1. decision between 1 prgramming sector B(main.app) or 2 branch asm("LB 0x337FFE") from external GPIO pin state

    2. case 1

    Code start branch.asm can communicate to receive main.c(hex file).

    Program sector B with main.c(hex file)

    case 2

    Branch asm("LB 0x337ffe")

    Watch dog disable. LB _C_INT00

     

    Above is that i undertand. is this right?

    but it's burden for me to design case 1 with assembly language.

    do you have some example for using assembly language?

  • particulary.

    in case of 2,

    i had plan to use FLASH API to write sector B. so it's impossible to use FLASH API in the code branch. asm

  • because FLASH API can be used after branch _c_init00.

    so i want to run second bootloader in the c environment after branch _c_init00.

    is it possible?

    it's very difficult to use FLASH API in the asm code.

  • Choi,

    No assembly coding is required here.  I think you're misunderstanding what I am saying.

    You will have two completely seperate projects: the secondary bootloader (call it "SBootloader"), and the main app.  Each is a completely independent CCS project.  Each project has a file CodeStartBranch.asm that contains little more than a LB (long branch) to the start of the respective program (well, CodeStartBranch.asm typically also contains a watchdog disable function, and the LB branches there.  The WD disable then branches to _c_int00 which is the start of the C environment startup routine).

    For the SBootloader, the section codestart (which contains only the LB instruction) is linked to address 0x33FFF6.  This is the ROM bootloader jump-to-flash target address, so after a reset the ROM bootloader will transfer control to your SBootloader.

    For the main app, you link its section codestart to a hard address in the flash sectors the main app is using (e.g., sectors B through H).  I suggested address 0x337FFE previously in sector B.  When the SBootloader wants to transfer control to the main app, it just has to do asm(" LB 0x337FFE");.

    Your Sbootloader has the flash APIs incorporated into them, in C.  It can reflash the main app when it wants/needs to.

    The only assembly code here is in CodeStartBranch.asm, and that has already been written by TI.  The section 'codestart' has nothing but a single LB instruction in it.  There is also a very small watchdog disable routine as I mentioned.  But again, this has already been written by TI.  You don't need to modify this code.

    Regards,

    David

  • I understand what you mean.

    but our customer's requirement is totally differnet what you think.

    they think that second bootloder project and application project must be melted in one project.

    it means that second boot loader project must be part of the application project.

    i must make only one project which is composed of FLASH SECTOR A(Second Boot Loader) and FLASH SECTOR B(Application Project).

    So look at the attachment file.

    you can see the what i want to design.

    please let me know if attachment content is right.

    is it possible to use Branch asm("LB 0X33RFFE") in the main.C on the FLASH SECTOR A.

  • Choi,

    Your attachment is missing from your post.  But you say your customer wants a single project that contains the secondary bootloader and the main app.  Why?  This makes things very complicated.  When you go to do a main-app update in the field, are you also planning to replace the secondary bootloader with a new one?  If no, then you still need a seperate main app project, right?

    Trying to make a secondary bootloader and a main app all in a single project is very complicated if you plan to leave the secondary bootloader alone in flash as the main app is updated.  The addresses resolved by the linker may not match anymore with the old seconday bootloader.  The _c_int00 routine can have difficulty since there is only one of these but it is trying to boot a mix of old and new code.  This is really not the way to do it.  I strongly recommend that you make the secondary bootloader and the main app seperate projects (if you plan to update the main app in the field, but leave the secondary bootloader alone).

    If all you're trying to do is update the entire flash in the field (secondary bootloader and main app at the same time), that is a different matter.  Then, you don't really need a secondary bootloader.  You just incorporate the flash APIs into your main app, and when it is time to update the code software copies the routines to RAM and runs them.  The entire flash would be erased and re-programmed.  The downside of this is that if you lose power or have some other glitch after erasing the flash, you cannot recover with JTAG.  Most people do NOT do what I just described because of this possibility.

    Here is a related thread on this subject, for reference:

    http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/383624/1358336.aspx#1358336

    Regards,

    David

  • i think it's better to update entire flash sector wiht only one project.

    One project include second bootloader.c and main.c

    At first. so i was asking about the linker cmd file.

    please refer to the attachment file

    Frankly i don't have confidence for modifying linker cmd file.

    pleask let me know.

    refer to the attachment file.

  • attachment file is my plan.

    please check if it is right.

  • Dear Choi,

    Recently i done a project in this programming the software without using Emulator .

    What i have did attached the document i hope it is useful to you. 

    I use one linker cmd file for both Flash API and Application soft.

    Give specific FLASH and RAM memory for both API and App Soft.

    Attachment: 5672.Flash Programming With out UsingEmulator.pptx

  • hi

    thank you for your help.

    but i don't understand some part of attachment file which you send to me.

    1. is it possible using asm("LB 0X317E00) in the Flash_main()?

    Can app main1 start with only using asm("LB 0X317E00)?

    2. how can main1 move to flash to ram?

    3. how can i call app_main?

     if you give me cmd file, i appreciate you.

    i hope to receive your response.

  • if you give me call number. i can call you to ask help.

    send me your phone number.

    my e-mail is choiwonseok@lignex1.com

  • 1. is it possible using asm("LB 0X317E00) in the Flash_main()?

        Yes,it is possible in TMS320F28335 controller  control goes from RAM to Flash and viceversa.

    2. how can main1 move to flash to ram? how can i call app_main?

          Anything written in the .c file or asm file memory will create.This memory creation depends on  type of data(i.e. sections)

    sections are initialized (  .text , .const ...,) and Uninitialized sections (.ebss)

    If specific routing given data will store in corresponding addr location otherwise data will store in sections.These sections you already routed in cmd file.

    In my project these sections routed to Flash E , From 0x317E00 location i have Flash to RAM copy Functions and at the end of all sections iam calling App Main(all these functions specific routing given) ,so after completing Flash to RAM copy(App main related data) control goes to App main.

    Giving cmd file is not possible because i am working in a R&D company.

     

  • My mobile number sent to you

  • HIlong time long see.i have been a business trip.
    so i can't deal with my problem related 28335 upload project.
    i read power point document you send me.
    so i use asm("LB 0X330000") in the C file.Follwoing is c file.while(1) {
    if(mode_selection == image_upload_mode) { switch(Decode_cmd)
    { case MSG_ID_UPLOAD_READY: { DELAY_US(500000);
    Decode_cmd = 0; ack_plus(0x87); break; }
    case MSG_ID_UPLOADING: {
    if(finished_storing_image_in_fpga == 0) {
    write_512byte_to_flash(); } else
    { Program_IMG_flash(); Decode_cmd = 0;
    } DELAY_US(500000); break; }
    default: { break; } }
    } else if(mode_selection == mission_mode) {
    asm("LB 0x330000"); }
    GpioDataRegs.GPADAT.bit.GPIO29 = 0; GpioDataRegs.GPBDAT.bit.GPIO32 = 0;
    DELAY_US(0100000); GpioDataRegs.GPADAT.bit.GPIO29 = 1;
    GpioDataRegs.GPBDAT.bit.GPIO32 = 1; DELAY_US(0100000);
    but i see the error message.
    "C:/ti/ccsv5/tools/compiler/c2000_6.2.0/bin/cl2000" -v28 -ml -mt --float_support=fpu32 --include_path="C:/ti/ccsv5/tools/compiler/c2000_6.2.0/include" --include_path="D:/dsp_workspace/f2/F2_UPLOAD_VER2/header" -g --diag_warning=225 --display_error_number --diag_wrap=off --preproc_with_compile --preproc_dependency="MAIN.pp" "../MAIN.c"
    "C:\Users\70805\AppData\Local\Temp\0708010", ERROR! at line 444: [E0002] Invalid mnemonic specification
    LB 0x330000why?please help me to solve the problem
  • asm(" LB 0x00317E00");

    Note that there is a space before the LB. You must have a space.
  • Hi Thank you for your help.
    I solve the problem related asm(" LB 0x330000"); thank to you.
    But after execute asm(" LB 0x330000");
    interrupt void ILLEGAL_ISR(void) // Illegal operation TRAP{
    // Insert ISR Code here
    // Next two lines for debug only to halt the processor here
    // Remove after inserting ISR Code asm(" ESTOP0"); for(;;);}
    Ccs stop in the above ISR in the DSP2833X_Defaultisr.c file.
    I don’t know why my upload project stopped in the ISR.Please help me.
    Following is the file including asm(" LB 0x330000").switch(Decode_cmd)
    {
    case MSG_ID_UPLOAD_READY:
    {
    DELAY_US(500000);
    Decode_cmd = 0;
    ack_plus(0x87);
    break;
    }
    case MSG_ID_UPLOADING:
    {
    if(finished_storing_image_in_fpga == 0)
    {
    write_512byte_to_flash();
    }
    else
    {
    Program_IMG_flash();
    Decode_cmd = 0;
    }
    DELAY_US(400000);
    break;
    }
    case mission_mode:
    {
    Decode_cmd = 0;
    asm(" LB 0x330000");
    break;
    }
  •  

    And following is my linker.cmd

    Following linker command file is used by upload.prj and application.prj in common.

    Upload.prj is project which receive hex image. And write hex image to FLASH SECTOR C.

    Application.prj is using SECTOR C .

    Difference between upload.prj and application.prj command file each is flash sector.

    upload.prj is using sector A

    application.prj is using sector C instead of A.

     

     

    Following is upload command file

     

    MEMORY

    {

    PAGE 0:    /* Program Memory */

               /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */

     

       ZONE0       : origin = 0x004000, length = 0x001000     /* XINTF zone 0 */

       RAML0       : origin = 0x008000, length = 0x001000     /* on-chip RAM block L0 */

       RAML1       : origin = 0x009000, length = 0x001000     /* on-chip RAM block L1 */

       RAML2       : origin = 0x00A000, length = 0x001000     /* on-chip RAM block L2 */

      RAML3       : origin = 0x00B000, length = 0x001000     /* on-chip RAM block L3 */

       ZONE6       : origin = 0x0100000, length = 0x100000    /* XINTF zone 6 */

       ZONE7A      : origin = 0x0200000, length = 0x010000   /* XINTF zone 7 - program space */

       FLASHH      : origin = 0x300000, length = 0x008000     /* on-chip FLASH */

       FLASHG      : origin = 0x308000, length = 0x008000     /* on-chip FLASH */

       FLASHF      : origin = 0x310000, length = 0x008000     /* on-chip FLASH */

       FLASHE      : origin = 0x318000, length = 0x008000     /* on-chip FLASH */

       FLASHD      : origin = 0x320000, length = 0x008000     /* on-chip FLASH */

       FLASHC      : origin = 0x328000, length = 0x008000     /* on-chip FLASH */

       FLASHA      : origin = 0x338000, length = 0x007F80     /* on-chip FLASH */

       CSM_RSVD    : origin = 0x33FF80, length = 0x000076     /* Part of FLASHA.  Program with all 0x0000 when CSM is in use. */

       BEGIN       : origin = 0x33FFF6, length = 0x000002     /* Part of FLASHA.  Used for "boot to Flash" bootloader mode. */

       CSM_PWL     : origin = 0x33FFF8, length = 0x000008     /* Part of FLASHA.  CSM password locations in FLASHA */

       OTP         : origin = 0x380400, length = 0x000400     /* on-chip OTP */

       ADC_CAL     : origin = 0x380080, length = 0x000009     /* ADC_cal function in Reserved memory */

     

       IQTABLES    : origin = 0x3FE000, length = 0x000b50     /* IQ Math Tables in Boot ROM */

       IQTABLES2   : origin = 0x3FEB50, length = 0x00008c     /* IQ Math Tables in Boot ROM */

       FPUTABLES   : origin = 0x3FEBDC, length = 0x0006A0     /* FPU Tables in Boot ROM */

       ROM         : origin = 0x3FF27C, length = 0x000D44     /* Boot ROM */

       RESET       : origin = 0x3FFFC0, length = 0x000002     /* part of boot ROM  */

       VECTORS     : origin = 0x3FFFC2, length = 0x00003E     /* part of boot ROM  */

     

    PAGE 1 :   /* Data Memory */

               /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE0 for program allocation */

               /* Registers remain on PAGE1                                                  */

     

       BOOT_RSVD   : origin = 0x000000, length = 0x000050     /* Part of M0, BOOT rom will use this for stack */

       RAMM0       : origin = 0x000050, length = 0x0003B0     /* on-chip RAM block M0 */

       RAMM1       : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */

       RAML4       : origin = 0x00C000, length = 0x001000     /* on-chip RAM block L1 */

       RAML5       : origin = 0x00D000, length = 0x001000     /* on-chip RAM block L1 */

       RAML6       : origin = 0x00E000, length = 0x001000     /* on-chip RAM block L1 */

       RAML7       : origin = 0x00F000, length = 0x001000     /* on-chip RAM block L1 */

    //   ZONE7B      : origin = 0x20FC00, length = 0x000400     /* XINTF zone 7 - data space */

       FLASHB      : origin = 0x330000, length = 0x008000     /* on-chip FLASH */

     

          DEV_EMU     : origin = 0x000880, length = 0x000180     /* device emulation registers */

       FLASH_REGS  : origin = 0x000A80, length = 0x000060     /* FLASH registers */

       CSM         : origin = 0x000AE0, length = 0x000010     /* code security module registers */

     

       ADC_MIRROR  : origin = 0x000B00, length = 0x000010     /* ADC Results register mirror */

     

       XINTF       : origin = 0x000B20, length = 0x000020     /* external interface registers */

     

       CPU_TIMER0  : origin = 0x000C00, length = 0x000008     /* CPU Timer0 registers */

       CPU_TIMER1  : origin = 0x000C08, length = 0x000008     /* CPU Timer0 registers (CPU Timer1 & Timer2 reserved TI use)*/

       CPU_TIMER2  : origin = 0x000C10, length = 0x000008     /* CPU Timer0 registers (CPU Timer1 & Timer2 reserved TI use)*/

     

       PIE_CTRL    : origin = 0x000CE0, length = 0x000020     /* PIE control registers */

       PIE_VECT    : origin = 0x000D00, length = 0x000100     /* PIE Vector Table */

     

       DMA         : origin = 0x001000, length = 0x000200     /* DMA registers */

     

       MCBSPA      : origin = 0x005000, length = 0x000040     /* McBSP-A registers */

       MCBSPB      : origin = 0x005040, length = 0x000040     /* McBSP-B registers */

     

       ECANA       : origin = 0x006000, length = 0x000040     /* eCAN-A control and status registers */

       ECANA_LAM   : origin = 0x006040, length = 0x000040     /* eCAN-A local acceptance masks */

       ECANA_MOTS  : origin = 0x006080, length = 0x000040     /* eCAN-A message object time stamps */

       ECANA_MOTO  : origin = 0x0060C0, length = 0x000040     /* eCAN-A object time-out registers */

       ECANA_MBOX  : origin = 0x006100, length = 0x000100     /* eCAN-A mailboxes */

     

       ECANB       : origin = 0x006200, length = 0x000040     /* eCAN-B control and status registers */

       ECANB_LAM   : origin = 0x006240, length = 0x000040     /* eCAN-B local acceptance masks */

       ECANB_MOTS  : origin = 0x006280, length = 0x000040     /* eCAN-B message object time stamps */

       ECANB_MOTO  : origin = 0x0062C0, length = 0x000040     /* eCAN-B object time-out registers */

       ECANB_MBOX  : origin = 0x006300, length = 0x000100     /* eCAN-B mailboxes */

     

       EPWM1       : origin = 0x006800, length = 0x000022     /* Enhanced PWM 1 registers */

       EPWM2       : origin = 0x006840, length = 0x000022     /* Enhanced PWM 2 registers */

       EPWM3       : origin = 0x006880, length = 0x000022     /* Enhanced PWM 3 registers */

       EPWM4       : origin = 0x0068C0, length = 0x000022     /* Enhanced PWM 4 registers */

       EPWM5       : origin = 0x006900, length = 0x000022     /* Enhanced PWM 5 registers */

       EPWM6       : origin = 0x006940, length = 0x000022     /* Enhanced PWM 6 registers */

     

       ECAP1       : origin = 0x006A00, length = 0x000020     /* Enhanced Capture 1 registers */

       ECAP2       : origin = 0x006A20, length = 0x000020     /* Enhanced Capture 2 registers */

       ECAP3       : origin = 0x006A40, length = 0x000020     /* Enhanced Capture 3 registers */

       ECAP4       : origin = 0x006A60, length = 0x000020     /* Enhanced Capture 4 registers */

       ECAP5       : origin = 0x006A80, length = 0x000020     /* Enhanced Capture 5 registers */

       ECAP6       : origin = 0x006AA0, length = 0x000020     /* Enhanced Capture 6 registers */

     

       EQEP1       : origin = 0x006B00, length = 0x000040     /* Enhanced QEP 1 registers */

       EQEP2       : origin = 0x006B40, length = 0x000040     /* Enhanced QEP 2 registers */

     

       GPIOCTRL    : origin = 0x006F80, length = 0x000040     /* GPIO control registers */

       GPIODAT     : origin = 0x006FC0, length = 0x000020     /* GPIO data registers */

       GPIOINT     : origin = 0x006FE0, length = 0x000020     /* GPIO interrupt/LPM registers */

     

       SYSTEM      : origin = 0x007010, length = 0x000020     /* System control registers */

       SPIA        : origin = 0x007040, length = 0x000010     /* SPI-A registers */

       SCIA        : origin = 0x007050, length = 0x000010     /* SCI-A registers */

       XINTRUPT    : origin = 0x007070, length = 0x000010     /* external interrupt registers */

     

       ADC         : origin = 0x007100, length = 0x000020     /* ADC registers */

     

       SCIB        : origin = 0x007750, length = 0x000010     /* SCI-B registers */

     

       SCIC        : origin = 0x007770, length = 0x000010     /* SCI-C registers */

     

       I2CA        : origin = 0x007900, length = 0x000040     /* I2C-A registers */

     

       CSM_PWL     : origin = 0x33FFF8, length = 0x000008     /* Part of FLASHA.  CSM password locations. */

     

       PARTID      : origin = 0x380090, length = 0x000001     /* Part ID register location */

    }

     

    /* Allocate sections to memory blocks.

       Note:

             codestart user defined section in DSP28_CodeStartBranch.asm used to redirect code

                       execution when booting to flash

             ramfuncs  user defined section to store functions that will be copied from Flash into RAM

    */

     

    SECTIONS

    {

       PieVectTableFile : > PIE_VECT,   PAGE = 1

     

    /*** Peripheral Frame 0 Register Structures ***/

       DevEmuRegsFile    : > DEV_EMU,     PAGE = 1

       FlashRegsFile     : > FLASH_REGS,  PAGE = 1

       CsmRegsFile       : > CSM,         PAGE = 1

       AdcMirrorFile     : > ADC_MIRROR,  PAGE = 1

       XintfRegsFile     : > XINTF,       PAGE = 1

       CpuTimer0RegsFile : > CPU_TIMER0,  PAGE = 1

       CpuTimer1RegsFile : > CPU_TIMER1,  PAGE = 1

       CpuTimer2RegsFile : > CPU_TIMER2,  PAGE = 1

       PieCtrlRegsFile   : > PIE_CTRL,    PAGE = 1

       DmaRegsFile       : > DMA,         PAGE = 1

     

    /*** Peripheral Frame 3 Register Structures ***/

       McbspaRegsFile    : > MCBSPA,      PAGE = 1

       McbspbRegsFile    : > MCBSPB,      PAGE = 1

     

    /*** Peripheral Frame 1 Register Structures ***/

       ECanaRegsFile     : > ECANA,       PAGE = 1

       ECanaLAMRegsFile  : > ECANA_LAM    PAGE = 1

       ECanaMboxesFile   : > ECANA_MBOX   PAGE = 1

       ECanaMOTSRegsFile : > ECANA_MOTS   PAGE = 1

       ECanaMOTORegsFile : > ECANA_MOTO   PAGE = 1

     

       ECanbRegsFile     : > ECANB,       PAGE = 1

       ECanbLAMRegsFile  : > ECANB_LAM    PAGE = 1

       ECanbMboxesFile   : > ECANB_MBOX   PAGE = 1

       ECanbMOTSRegsFile : > ECANB_MOTS   PAGE = 1

       ECanbMOTORegsFile : > ECANB_MOTO   PAGE = 1

     

       EPwm1RegsFile     : > EPWM1        PAGE = 1

       EPwm2RegsFile     : > EPWM2        PAGE = 1

       EPwm3RegsFile     : > EPWM3        PAGE = 1

       EPwm4RegsFile     : > EPWM4        PAGE = 1

       EPwm5RegsFile     : > EPWM5        PAGE = 1

       EPwm6RegsFile     : > EPWM6        PAGE = 1

     

       ECap1RegsFile     : > ECAP1        PAGE = 1

       ECap2RegsFile     : > ECAP2        PAGE = 1

       ECap3RegsFile     : > ECAP3        PAGE = 1

       ECap4RegsFile     : > ECAP4        PAGE = 1

       ECap5RegsFile     : > ECAP5        PAGE = 1

       ECap6RegsFile     : > ECAP6        PAGE = 1

     

       EQep1RegsFile     : > EQEP1        PAGE = 1

       EQep2RegsFile     : > EQEP2        PAGE = 1

     

       GpioCtrlRegsFile  : > GPIOCTRL     PAGE = 1

       GpioDataRegsFile  : > GPIODAT      PAGE = 1

       GpioIntRegsFile   : > GPIOINT      PAGE = 1

     

    /*** Peripheral Frame 2 Register Structures ***/

       SysCtrlRegsFile   : > SYSTEM,      PAGE = 1

       SpiaRegsFile      : > SPIA,        PAGE = 1

       SciaRegsFile      : > SCIA,        PAGE = 1

       XIntruptRegsFile  : > XINTRUPT,    PAGE = 1

       AdcRegsFile       : > ADC,         PAGE = 1

       ScibRegsFile      : > SCIB,        PAGE = 1

       ScicRegsFile      : > SCIC,        PAGE = 1

       I2caRegsFile      : > I2CA,        PAGE = 1

     

    /*** Code Security Module Register Structures ***/

       CsmPwlFile        : > CSM_PWL,     PAGE = 1

     

    /*** Device Part ID Register Structures ***/

       PartIdRegsFile    : > PARTID,      PAGE = 1

     

     

     

       /* Allocate program areas: */

       .cinit              : > FLASHA      PAGE = 0//NOLOAD SECTION, used to initailize c Global varalbles at startup, initialized section

       .pinit              : > FLASHA,     PAGE = 0//global constructors for c++program.

       .text               : > FLASHA      PAGE = 0//Program code, initialized section

       codestart           : > BEGIN       PAGE = 0

       ramfuncs            : LOAD = FLASHA,

                             RUN = RAML0,

                             LOAD_START(_RamfuncsLoadStart),

                             LOAD_END(_RamfuncsLoadEnd),

                             RUN_START(_RamfuncsRunStart),

                             PAGE = 0

     

       csmpasswds          : > CSM_PWL     PAGE = 0

       csm_rsvd            : > CSM_RSVD    PAGE = 0

     

       /* Allocate uninitalized data sections: */// uninitailized section is not load. allocate only once for uninitialized section for run address. ignore load address

       .stack              : > RAMM1       PAGE = 1

       .ebss               : > RAML4       PAGE = 1

       .esysmem            : > RAMM1       PAGE = 1

     

       /* Initalized sections go in Flash */

       /* For SDFlash to program these, they must be allocated to page 0 */

       .econst             : > FLASHA      PAGE = 0

       .switch             : > FLASHA      PAGE = 0

     

       /* Allocate IQ math areas: */

       IQmath              : > FLASHA      PAGE = 0                  /* Math Code */

       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)

     

       }

       */

     

       FPUmathTables    : > FPUTABLES, PAGE = 0, TYPE = NOLOAD

     

       /* Allocate DMA-accessible RAM sections: */

       DMARAML4         : > RAML4,     PAGE = 1

       DMARAML5         : > RAML5,     PAGE = 1

       DMARAML6         : > RAML6,     PAGE = 1

       DMARAML7         : > RAML7,     PAGE = 1

     

       /* Allocate 0x400 of XINTF Zone 7 to storing data */

       ZONE7DATA        : > ZONE7A,    PAGE = 0

     

       /* .reset is a standard section used by the compiler.  It contains the */

       /* the address of the start of _c_int00 for C Code.   /*

       /* When using the boot ROM this section and the CPU vector */

       /* table is not needed.  Thus the default type is set here to  */

       /* DSECT  */

       .reset              : > RESET,      PAGE = 0, TYPE = DSECT

       vectors             : > VECTORS     PAGE = 0, TYPE = DSECT

     

       /* Allocate ADC_cal function (pre-programmed by factory into TI reserved memory) */

       .adc_cal     : load = ADC_CAL,   PAGE = 0, TYPE = NOLOAD

     

     

     

     

         Flash28_API:

       {

            -lFlash28335_API_V210.lib(.econst)

            -lFlash28335_API_V210.lib(.text)

       }                          LOAD = FLASHA,

                                          RUN = RAML0|RAML1|RAML2|RAML3,

                                          LOAD_START(_Flash28_API_LoadStart),

                                          LOAD_END(_Flash28_API_LoadEnd),

                                          RUN_START(_Flash28_API_RunStart),

                                          PAGE = 0

     

     

     

    }

     

  • HiI solved the problem thank to you.I did it as you say in the power point.
    At first it didn’t work.So I have following 2 entry point to be the same.


    First is following hex.cmd
    Following entry point is "_c_int00" address: 00338976 in the map file


    ** =============== hex.cmd ====================***/
    UPLOAD.out /* input COFF file */
    --map UPLOAD.map /* create a hex map file */
    -a /* create ASCII image */
    --image /* Create a memory image (no discontinuities) */
    --order=LS /* little endian */
    --zero /* reset address origin to 0 for output file(s) */
    --memwidth 16
    --boot /* create a boot table for all initialized sects */
    --entrypoint=0x0032898dROMS{
    wonseok: org = 0x328000, len = 0x2000, romwidth = 16, files = {.\upload_final.hex}, fill = 0xffff
    }

    Following is the map fileOUTPUT FILE NAME: <UPLOAD.out>
    ENTRY POINT SYMBOL: "_c_int00" address: 00338976Second is upload.prj
    asm(" LB 0x0032898d");//entry point

    following is the main.c in the upload.prj


    while(1) {
    switch(Decode_cmd)
    {
    case MSG_ID_UPLOAD_READY:
    {
    DELAY_US(500000);
    Decode_cmd = 0;
    ack_plus(0x87);
    break;
    }
    case MSG_ID_UPLOADING:
    {
    if(finished_storing_image_in_fpga == 0)
    {
    write_512byte_to_flash();
    }
    else
    {
    Program_IMG_flash();
    Decode_cmd = 0;
    }
    DELAY_US(400000);
    break;
    }
    case mission_mode:
    {
    Decode_cmd = 0;
    asm(" LB 0x0032898d");//entry point
    break;
    }


    Then it work that I intend.But problem is occurred.
    Whenever main.prj code is modified, entry point will be changed because of code size.
    So how can upload.prj know the changing entry point address?
    I want to fix entry point.Is it possible to fix entry point from the .map file?
    If it is impossible, I want have upload.prj receive the changed entry point. And asm(" LB changing");//entry point
    Do I make code in assembly?Please helpThank you for your help.

  • Control goes to ITRAP whenever address location contains "0xFFFF" (control will not execute 0xFFFF)

    For checking this execute the software step by step manner and parallely see the corresponding address location data(i.e data present in the memory location using Disassembly or memory browser option)

    In your command file 0x330000 is not routed to any section so there is a no data (default it contains 0xFFFF) i think due to this control goes to ITRAP.

    once check it step by step in which instruction control goes to ITRAP in your software .

    For more information regarding ITRAP read "FLASH API Read me" Document .