• State Resolved
  • Locked Locked
  • Replies 25 replies
  • Subscribers 85 subscribers
  • Views 4426 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Using F2808 With Multiple SW Images ...

YUSUF FARRAH
Prodigy 190 points
Other Parts Discussed in Thread: TMS320F2808

I am new to using the TMS320F2808  dsp based micro-controller   My project requires that I use 2 software images.  A bootstrap image and an application image must both be co-resident in different sectors of the 64Kx16 flash memory.  The bootstrap image will be constrained to a 16K chunk of flash and the rest is allocated to the application image.  Both software images will be written in C, however since the bootstrap image is memory constrained it will be a NOT use the DSP-BIOS, while the application image will task advantage of the DSP-BIOS's RTOS capabilities.  After a reset of any kind the bootstrap image will execute and under the appropriate conditions initiate a switch to the application image.

My basic question is how does one reliably switch from executing in the boostrap image to the application image software.  I am sure more is involved than a simple C setjmp & longjmp execution from the boostrap code executing to the address of the C init entry point (i.e. -  _c_int00) in the application image's flash sector.  Some general guidance and specific issues to be addressed would be highly appreciated.

  • 0
    TI__Guru 61235 points

    Yusuf,

    Actually, you are right on target.  It is pretty much as simple as just branching from the bootstrap code to the _c_int00 entry point of the main app.  The trick is that you don't know where _c_int00 will be from build to build, so you want to set things up so the linker will manage this.  Here's how:

    First, both your bootstrap and main app will be completely independent projects (you already seem to know this).  They will each have their own _c_int00 routine, etc.  You will notice in all the TI code examples that there is this file called CodeStartBranch.asm.  This contains a single branch instruction in a named section called 'CodeStart' to the _c_int00 of the code project (actually, it usually branches to a watchdog disable routine in the regular .text section, which in turn branches to _c_int00).  For your bootstrap project, you link section 'CodeStart' to the ROM bootloader target address for your device, provided in the datasheet.  For F2808, this is address 0x3F7FF6.  So after reset, the ROM bootloader runs, sees you want jump-to-flash mode, and branches to address 0x3F7FF6.  The code there is a single branch to the start of your code.

    To transfer control to the main app, do the same thing.  Pick a specific address in flash that is part of your main app.  You need two 16-bit words (to hold the branch)  I'd suggest the very last address in flash that you plan to use for your main app.  Alternately, use the very first address in flash.  Doesn't really matter.  Point is don't pick an address in the middle of your main application as that will bust up your flash.  For your main app, you will link your section 'CodeStart' to the hard address you have chosen using the linker command file (you peel out the two words from the main flash, and list them seperately in the MEMORY section of the linker .cmd file.  Then link 'CodeStart' to that memory).  For your bootstrap, it will simply execute a branch to that hard address, which is now known.  You could probably just use inline assembly for this.  For example, suppose you chose the first address in flash as the transfer address.  This is 0x3E8000.  In the bootstrap code, you could do this in your C-code:

        asm(" LB 0x3E8000");

    When the bootstap executes this, it will branch to the transfer address, and your main app will start.

    Just to be clear, the reason we choose a hard, knowm transfer address is that it will never change.  The linker can do whatever it wants in terms of placing the boostrap and main app in memory at build time, but your hard transfer address is locked in to the .cmd file and the transfer will always work.  If you didn't do this, you need to build the main app first, look at the .map file to see where _c_int00 ended up, and then adjust the boostrap code to branch to that address.  That would be a pain.  Much better to use a hard transfer address.

    P.S. remember to take into account the watchdog during the control transfer if the bootstrap has the WD enabled.  You may need to service it right before the transfer to give time for the main app to get up and running.

    Regards,

    David

  • 0 in reply to David M. Alter
    Prodigy 190 points

    Your suggestion seems to be spot on for what I am looking to do and pretty straight forward.  Using your approach I could put my application within the first 48 K of the F2808's  flash, the bootstrap in the bottom 16K,   Link edit the application software's  "codestart" section of memory in the application to be 0x3E8000, thereby locating "wd_disable" assembly routine which thereby calls "_c_int00" at the same location.  The boostrap applications "codestart" section is link edited to normal  flash entry address of 0x3F7FF6.  When the bootstrap software is prepared to switch to application software execution a simple inline assembler  of asm(" LB 0x3E8000");  will simulate the startup from a reset for the application software.  Follow-up questions;

    1. Is the aforementioned  a correct regurgitation of your suggested procedure?

    2.  Since the bootstrap software would do the appropriate code security module (CS) unlocking there is no need to do this a second time in the application software correct?

    3. Is there any recommended hardware clean-up over and above disabling the Watchdog Timer & disabling interrupts by the bootstrap software before attempting the switch from bootstrap to application software operation  (e.g. - Clean-up of RAM used as stack for the bootstrap)?

    4.  Part of the what the bootstrap will be doing is to update the flash sectors containing the application software when appropriate with the  new application software  image data provided externally via the CAN bus communication.  Might  this inject some unexpected complication to what you have suggested?

    Thanks,

    Yusuf

  • 0 in reply to YUSUF FARRAH
    TI__Guru 61235 points

    Yusuf,

    YUSUF FARRAH said:

    1. Is the aforementioned  a correct regurgitation of your suggested procedure? 

    Yes, with these clarifications:

    You said you'd put the "Bootstrap in the bottom 16K" of flash.  Unsure what "Bottom" means.  So let me be clear.  You want the bootstap in flash sector A.  That is where the ROM bootloader jump-to-flash target address is.  Sector A would never reprogrammed during in-field reprogramming.  That way, if you loose power during field reprogramming, your bootstrap code is still intact and you can start over again.  The bootstrap would usually contain a checksum check for the main app to make sure the main app was intact before it transfered control to it.  If the main app was compromised, the bootstrap would go into field reprogramming mode and request a new main app from whatever facilities you have provided.

    Note that the wd_disable routine for the main app (or any app) is usually in the .text section and could be linked anywhere by the linker.  It is only the codestart section that must be place, for your example, at 0x3E8000.  It will consume exactly two 16-bit words, 0x3E8000 and 0x3E8001.  It will branch to wherever your wd_disable routine happens to be.

    YUSUF FARRAH said:

    2.  Since the bootstrap software would do the appropriate code security module (CS) unlocking there is no need to do this a second time in the application software correct?

    It sounds like you are not planning to use the CSM.  If so, then the ROM bootloader will unlock it for you (because you've left the passwords as all 0xFFFF).  Neither your boostrap nor your main app need to take any action.  If you do want to use the CSM, you don't unlock it and you'd need to manage the memory usage as appropriate to be able to use the CSM.

    YUSUF FARRAH said:

    3. Is there any recommended hardware clean-up over and above disabling the Watchdog Timer & disabling interrupts by the bootstrap software before attempting the switch from bootstrap to application software operation  (e.g. - Clean-up of RAM used as stack for the bootstrap)?

    Well, I would disable global interrupts (INTM bit) prior to transfer.  Let the main app turn them back on when it is ready to do so.  The WD is something that your application requirements need to be considered for.  The easiest thing to do is have the bootstrap turn it off before the transfer and let the main app turn it on when it is ready.  But this may not be acceptable in your application since there will be a period of time that the product is not WD protected.  If you need continuous WD protection, then maybe service the dog just before transfer, and then you need to make sure you service it again in the main app before it times out.

    Note that you do not necessarily have to lock the PLL again in your main app.  If the bootstrap already did it, you can just leave it alone in the main app.  Some people prefer to have the main app completely standalone however, so they have the main app do everything again as if it was starting up from a reset (instead of relying on the bootstrap to do certain things).  Also note that the main app can re-use the RAM that the bootstrap uses.  The bootstrap doesn't need the RAM anymore.  The main app can use all the RAM in the chip.

    YUSUF FARRAH said:

    4.  Part of the what the bootstrap will be doing is to update the flash sectors containing the application software when appropriate with the  new application software  image data provided externally via the CAN bus communication.  Might  this inject some unexpected complication to what you have suggested?

    This is a common thing that people do.  The scheme I've proposed is suited for this purpose.  Again, you never reprogram the bootstrap (flash sector A).  That way you can always recover if something goes wrong during flash updating.  Now, some people do leave a way for the bootstrap to re-flash itself for "Emergency" purposes, but this is risky in the field since if something goes wrong you need to use JTAG to recover.

    Good luck,

    David

  • 0 in reply to David M. Alter
    Prodigy 190 points

    Again the previous feedback focused in on exactly what I am targeting.  Just to be brutally clear what specifically I mean by the application in the "Application in the top 48K" of flash and "Bootstrap in the bottom 16K" of flash is to:

    1. Physically allocate to the application F2808 Flash space in addresses 0x3E8000 through 0x3F3FFF

    2. Physically allocate to the bootstrap F2808 Flash space in addresses 0x3F4000 through 0x3F7FF7 (Skipping the 128-bit Password area + The 120 Words prior to the start of the CSM passwords) and a two word section 0x3F7FF6.

    3. By Flash sector s A through D I take you mean:

    FLASHA : origin = 0x3F4000, length = 0x003F80 /* on-chip FLASH */
    FLASHC : origin = 0x3EC000, length = 0x004000 /* on-chip FLASH */
    FLASHB : origin = 0x3F0000, length = 0x004000 /* on-chip FLASH */
    FLASHD : origin = 0x3E8000, length = 0x004000 /* on-chip FLASH */

    Does aforementioned clarifications above address your earlier point about placing the bootstrap software in "Sector A" where the ROM boot  loader address of 0x3F7FF6 is located?

  • 0 in reply to YUSUF FARRAH
    TI__Guru 61235 points

    You are correct on all points 1 through 3.

    YUSUF FARRAH said:

    3. By Flash sectors A through D I take you mean:

    FLASHA : origin = 0x3F4000, length = 0x003F80 /* on-chip FLASH */
    FLASHC : origin = 0x3EC000, length = 0x004000 /* on-chip FLASH */
    FLASHB : origin = 0x3F0000, length = 0x004000 /* on-chip FLASH */
    FLASHD : origin = 0x3E8000, length = 0x004000 /* on-chip FLASH */

    Yes, although your table is in a weird order.  Seems correct.  I'd prefer this table, easier to read:

            FLASHD : origin = 0x3E8000, length = 0x004000 /* on-chip FLASH */
            FLASHC : origin = 0x3EC000, length = 0x004000 /* on-chip FLASH */
            FLASHB : origin = 0x3F0000, length = 0x004000 /* on-chip FLASH */
            FLASHA : origin = 0x3F4000, length = 0x003F80 /* on-chip FLASH */ 

    - David

  • 0 in reply to YUSUF FARRAH
    Prodigy 190 points

    David,

    Thank you very much for your insight and patience!

  • 0 in reply to David M. Alter
    Intellectual 805 points

    I am using an F28M36x part and exploring software architectures to allow for in-field reprogramming of the main code on both cores.

    I understand the concept described earlier in this post, but wonder what you might suggest for extending it to both cores. Would I need some sort of permanent bootstrap code residing in the flash of both the master and control sub-systems? What would be the most efficient way to transfer the new image over to the control sub-system?

    I plan to use a USB connection for in-field reprogramming. I will also have the option of using most other communication ports and an SD card for data storage.

  • 0 in reply to David M. Alter
    Mastermind 7675 points

    David,

    I know this is an old thread but I'm doing a bootloader skeleton, where my bootstrap is in the flashA sector. The bootstrap performed a LB to the FlashD sector, where my Main app exist. I'm using the F28027 and CCSv5.4.

    In the linker cmd file of the Main app I define :

    MEMORY

    {

    ..

    BEGIND      : origin = 0x3F0000, length = 0x000002

    FLASHD      : origin = 0x3F0002, length = 0x001FFE     /* on-chip FLASH */

    ..

    }

    SECTION

    {

    ..

    codestart           : > BEGIND        PAGE = 0

    ..

    }

    looking the map file of the Main app I see the ENRY POINT is:

    ENTRY POINT SYMBOL: "code_start"  address: 003f04d0

    in the SECTION ALLOCATION MAP I see:

    codestart

    * 0 003f0000 00000002
    003f0000 00000002 start_branch.obj (codestart)

    Shouldn't the ENTRY POINT be 0x3F0000? I missed something?

    the .text has the same origin (003f04d0) ? Why the ENTRY POINT has the same origin that the .text?

    Regards

    Gastón

  • 0 in reply to Gaston_Melo_Arg
    TI__Guru 61235 points

    Hello Gaston,

    I think you've done it correctly.  There is a difference between "codestart" and "code_start".  You have defined the section "codestart" which I assume contains a single LB instruction that branches to either a watchdog disable routine or maybe straight to _c_int00.  You seem to have linked this correctly.

    The "code_start" that is confusing you is a symbol created by the codegen tools.  It is completely artificial, and only affects CCS.  If you do a "Restart" in CCS, it will set the PC to the entry point of your program (i.e., code_start symbol location).  By default, code_start is the address of _c_int00 (unless you change it using the -e linker option).

    Try your code transfer to your main app (step through it the first time).  I think it will work just fine.

    Regards,

    David

  • 0 in reply to David M. Alter
    Mastermind 7675 points

    David,

                    Thanks for the quick reply. I'm asking because looking at the map file of the bootstrap (in the FlashA sector) the origin of the "code_start" and the "codestart" are the same, in this case : 0x3F7FF6. (which is the Boot from Flash).

    I wanna use the Scia port of the piccolo to be able to do the upgrade of the main app (in the FlashD sector), but I have some doubts regarding how can achieve this, regarding how to store the incoming data and then program the sector with the new app. Do I have to define a big buffer to store X lenght of incoming data and then, using the FLASH API, program it. Once this is done, resume to the incoming data? Is this approach correct? 

    Reading other post, I see they perform a "checksum", how can I do this? Is there a pdf about this?

    Regards

    Gastón

  • 0 in reply to Gaston_Melo_Arg
    TI__Guru 61235 points

    Gaston,

     

    Gaston_Melo_Arg said:

    I wanna use the Scia port of the piccolo to be able to do the upgrade of the main app (in the FlashD sector), but I have some doubts regarding how can achieve this, regarding how to store the incoming data and then program the sector with the new app. Do I have to define a big buffer to store X lenght of incoming data and then, using the FLASH API, program it. Once this is done, resume to the incoming data? Is this approach correct? 

    Yes, that is what is typically done.  First, you have the APIs erase the sectors that need erasing.  Then you send over a data a bit at a time and store in RAM.  This can be as large or as small in length as you want and have RAM available.  Maybe 1KB or 2KB at a time.  You will want to utilize the same data flow as the bootloader uses.  The hex utility (hex2000) will create a hex file that you can send.  Each section is sent as length, address, then data.  A length of zero means there are no more sections.  You will have to handle the case where a section is large in length than your RAM buffer.  You'll need to split the section as it is sent.

    Gaston_Melo_Arg said:

    Reading other post, I see they perform a "checksum", how can I do this? Is there a pdf about this?

     
    That is up to you.  People will typically do some sort of checksum on each buffer of data they send over.  The last word(s) sent being the calculated checksum of the data packet.  The C2000 then performs the same checksum computation as validates against the last value(s).  The checksum could be as simple as an actual summation of the op-codes, although this simple an approach can easily miss multiple bit errors.  There are a lot of different approaches to data integrity validation (checksum, CRC, etc.).  You can canvas the web and choose whatever suits your needs.
     
    Regards,
    David
  • 0 in reply to David M. Alter
    Mastermind 7675 points

    Hi David,

                        I just finished the bootloader and I'm able to flash the piccolo with new application data using the hex file generated by hex2000. It works great, but I'm still having problems with the Entry Point. As I mention before, the Entry Point of the Main app is :

    BEGIND      : origin = 0x3F0000, length = 0x000002

    But looking at the map file generated by the hex2000, the Entry Point is:

    ENTRY POINT SYMBOL: "code_start"  address: 003f04d0

    Using a soft app Im able to download this hex file (generated by hex2000) to the piccolo using the scia port. But if  I use the Entry Point generated by the hex2000 the main app never start.

    I have to change the hex file manually to the Entry Point defined by me (0x3F0000) to start the Main app. I guess the solution will be to change the Entry Point of my app to 0x3F04D0 but I'm trying to understand why is this happening. What happens if I decide to change the Entry Point of my main app, Do I have to change the Entry Point in the cmd file by the Entry Point that appears in the map file once I finish to compile the main app in CCS? How can I sove this issue?

    How can I modify the cmd file of the main app to get the same Entry Points (the one specified by me and the other specified by the map file)?

    Regards

    Gastón

  • 0 in reply to Gaston_Melo_Arg
    TI__Guru 61235 points

    Gaston,

    Again, the Entry Point is an artificial thing used by CCS.  It does not affect code execution.  What you're telling me is your secondary bootloader is branching to address 0x3F0000, but your main app is not running.  That means the main app does not have the proper branch instruction linked to address 0x3F0000.

    What does the main app have linked to 0x3F0000?

    Please post the .map file for your project.

    Regards,

    David

  • 0 in reply to David M. Alter
    Mastermind 7675 points

    Hi Andy,

                     maybe I expressed myself in the wrong way. This is happening:

    The file generated by the hex2000 have the Entry Point as follows (showing first line of ascii file of Main App):

    AA 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3F 00 D0 04 BB 00

    As you can see the Main App has the next Entry point (according to hex2000) : 0x3F04D0

    In the command file of the Main App. I define the Entry Point as: 0x3F0000 (FlashD)

    Whats the problem: If I use the ascii file generated by the hex2000 to download the Main App. using The Entry Point 0x3F04D0 the application won't run. So I have to change the ascii file manually to get the 0x3F0000 as the Entry Point . By doing this, the Main app will run perfectly.

    The Question: why does the hex2000 has the Entry Point as 0x3F04D0, if I chosen the Entry Point as 0x3F0000?

    part of the map file:

    SECTION ALLOCATION MAP

    output attributes/
    section page origin length input sections
    -------- ---- ---------- ---------- ----------------
    .pinit 0 003f0002 00000000 UNINITIALIZED

    MySect 0 00008500 0000004a UNINITIALIZED
    00008500 0000004a Master_main.obj (MySect)

    codestart
    * 0 003f0000 00000002
    003f0000 00000002 start_branch.obj (codestart)

    ramfuncs 0 003f0002 000003cd RUN ADDR = 00008000
    003f0002 00000337 Master_main.obj (ramfuncs)
    003f0339 00000077 Master_main.obj (ramfuncs:retain)
    003f03b0 0000001b DSP2802x_SysCtrl.obj (ramfuncs)
    003f03cb 00000004 DSP2802x_usDelay.obj (ramfuncs)

    .econst 0 003f03d0 00000100 RUN ADDR = 000083ce
    003f03d0 00000100 DSP2802x_PieVect.obj (.econst)

    .text 0 003f04d0 00000667
    003f04d0 000001de Master_main.obj (.text)
    003f06ae 0000012b DSP2802x_SysCtrl.obj (.text)
    003f07d9 000000ff DSP2802x_DefaultIsr.obj (.text:retain)
    003f08d8 00000081 DSP2802x_EPwm.obj (.text)
    003f0959 00000075 DSP2802x_CpuTimers.obj (.text)
    003f09ce 0000005a rts2800_ml.lib : fs_mpy.obj (.text)
    003f0a28 00000044 : boot.obj (.text)
    003f0a6c 00000029 : fs_tol.obj (.text)
    003f0a95 00000028 DSP2802x_PieCtrl.obj (.text)
    003f0abd 00000025 DSP2802x_PieVect.obj (.text)
    003f0ae2 00000019 rts2800_ml.lib : args_main.obj (.text)
    003f0afb 00000019 : exit.obj (.text)
    003f0b14 00000015 DSP2802x_MemCopy.obj (.text)
    003f0b29 00000009 rts2800_ml.lib : _lock.obj (.text)
    003f0b32 00000005

    Gatón

  • 0 in reply to Gaston_Melo_Arg
    TI__Guru 61235 points

    Gaston,

    I'm not quite understanding the procedure you are using here.  The entry point does not control program execution.  It is artificial.  The entry point that appears in the hex file is only used by the ROM bootloader.  Are you using the ROM bootloader?  I don't believe so.  I suspect that if you do not specify an entry point in the hex utility using the -entry_point=addr option, the hex utility probably uses the address of the _c_int00 symbol.  I'm speculating on this, but it would explain what you are seeing in the hex file.

    I thought that what you were doing is writing your own secondary bootloader, and that bootloader branches to hard address 0x3F0000.  From your last post, your main app has its code-start-branch branch located at 0x3F0000, so the code transfer should be working.  That's why I'm not following what you must be doing here.

    Regards,

    David

    P.S. Incidentally, you can attach a file to the forum post!  This is easier to read than cutting and pasting from a file.

  • 0 in reply to David M. Alter
    Mastermind 7675 points

    Solve it!!!

    I added the -e option in the hex2000 utility (my case -e=0x3F0000).

    Thanks David

    Regards Gastón

    P.S : I tried to add the file but the page doesn't allow me (using chrome)

    P.S1: How can I mark this one as answered?

  • 0 in reply to Gaston_Melo_Arg
    TI__Guru 61235 points

    I'm still not sure what you're doing that the specified entry point matters, but if it fixed your problem OK.  The -e is just shorthand notation for the -entry_point option.

    You can close the thread by marking a post as verified.

    Regards and good luck,

    David

  • 0 in reply to David M. Alter
    Mastermind 7675 points

    David,

               If there is a way to send you in private the two codes (main and bootloader) to check it will be appreciated.

    Regards

    Thanks again

    gastón

  • 0 in reply to David M. Alter
    Mastermind 7675 points

    The problem with the Entry Point was an error in the start branch of the main app. Now is working properly.

    Regards

    Gastón

  • 0 in reply to David M. Alter
    Expert 1345 points

    David,

    I am confused about how to configure my linker command files to get flashed code to operate upon power-on.

    I'm trying to do something similar to Yusuf. My main program code will communicate with a PC and serially upload a binary file image of code that blinks an LED. I am using the F28335 with Code Composer v5.3. I have the Flash_API set up in my main program project and have successfully been able to erase, write and read various flash sectors with no issues within the operation of the main program.

    My goal is to have the main program reside in Flash Sector A and always try to communicate with a PC upon power up. So if I shut off my Experimenter's Kit and turn power back on, the main program will attempt to communicate with the PC and wait for the PC to send the binary file to the Experimenter's Kit. The main program running from the Experimenter's Kit Flash Sector A takes the binary file and writes it to Flash Sector F. After the Flash Sector F is checked and verfied, I want to copy the data from Flash Sector F into Flash Sector C.

    At this point, I want to be able to shut off the Experimenter's Kit and power on. Upon power on, I want the blinking LED code to execute. The blinking LED code would be the uploaded binary file flashed into Sector F then into Sector C.

    So far, I can convert a blinking LED project into a binary image file using hex2000. My main program can upload the file via SPI and I have confirmed correct flashing into Sector F and can copy the data into Flash Sector C by reading Flash Sector F and writing the result into Flash Sector C.

    At this point, I shut off my Experimenter's Kit and turn it back on without the emulator connected. Nothing happens. I can see the correct data using the Memory Browser in Flash Sector C, but it doesn't appear to be executing because the LED does not blink.

    I am confused about configuring the linker command file for the main program versus the linker command file for the blinking LED program.

    Do I set BEGIN_FLASH to be 0x33FFF6 for F28335's Sector A for the main program

    AND

    set BEGIN_FLASH to be 0x328000 for F28335's Sector C for the blinking LED program? Remember, I put the binary

    image of the blinking LED program into Flash Sector C using the main program.


    I am also confused by your reference to the codestart address. I have looked all over for these addresses in the CodeStartBranch.asm files and do not seem to see anything that resembles an address for the start of specific code.

    Or do I simply put  asm(" LB 0x328000");  at the end of my binary file transfer and flash routine in the main program?

    Thank you for your help,

    Chuck

     

     

     

  • 0 in reply to Charles Jackel
    TI__Guru 61235 points

    Hello Charles,

    First, a suggestion.  It is better to start a new thread instead of posting to an old thread, in particular a thread that is already marked as answered.  Once a thread is answered (or dated), it is much more likely to not get responded to.

    To your issue, the ONLY address that matters to the F28335 hardware in jump-to-flash bootmode is address 0x33FFF6 in flash sector A.  That is the address that the ROM bootloader will branch.  After that, the code will do what you tell it to.  There are no other address that the hardware has specified.  No "code_start" or "codestart" or any other "code" or "start" variant.  These are all software or debugger symbols that are man-made.  The C2000 peripheral header files have a file called codestartbranch.asm that contains a branch instruction pointing to the beginning of the code, and in a section called "codestart".  The intent of this is to link the section to 0x33FFF6 in a standard code setup.

    In your case, the ROM bootloader will branch to 0x33FFF6.  You need to have a branch there that jumps to the start of your main program.  What is the start of your main program?  Well, typically this is the _c_int00 routine which sets up the C compiler environment and then jumps to main().  Often however, people will want to disable the watchdog before this so instead of _c_int00 they branch to a small ASM routine that turns off the dog and then jumps to _c_int00.

    If you want to run your sector F or sector C code, you need to pick a hard address in these sectors where for the sector F or C project you link a branch statement that points to the start of the sector F or C code.  This address is entirely up to you (I suggest that first or last two 16-bit addresses in the sector).  The section codestart in these projects can be linked to this address to provide the needed branch.  Then adjust the branch destination to point to the symbol that is the start of your sector code project (e.g., _c_int00, or wd disable function, etc.).

    Regards,

    David

  • 0 in reply to David M. Alter
    TI__Guru 61235 points

    David M. Alter said:

    If you want to run your sector F or sector C code, you need to pick a hard address in these sectors where for the sector F or C project you link a branch statement that points to the start of the sector F or C code.  This address is entirely up to you (I suggest that first or last two 16-bit addresses in the sector).  The section codestart in these projects can be linked to this address to provide the needed branch.  Then adjust the branch destination to point to the symbol that is the start of your sector code project (e.g., _c_int00, or wd disable function, etc.).

    I should have added, your main code then branches to this hard address when it wants to run the sector F or C code.

    - David

  • 0 in reply to David M. Alter
    Expert 1345 points

    David,

    For my example using the F28335 chip, my main program resides in Flash Sector A (0x338000 to 0x33FF7F).

    I serially transmit a binary file and flash one byte at a time into Flash Sector F (0x310000 to 0x317FFF).

    When the file transmission/flash to F is finished, I read each byte in Flash Sector F and write each byte to Flash

    Sector C (0x328000 to 0x32FFFF).

    In the linker command file for my main program, the BEGIN_FLASH address is the factory coded Boot-To-Flash entry point of (0x33FFF6 to 0x33FFF7). The rest of the main program resides in Flash A and some functions in RAM.

    My questions:

    1. How do I configure the Linker command file for the program that I flashed into Flash Sector C BEFORE I convert the .out file to a binary file?

    2. How do I "adjust the branch destination" to point to the Flash Sector C code?

    3. I see you suggested adding asm(" LB 0x328000") into my main program to point to the address of the Flash Sector C.

    So do I place this instruction following my file transfer/flash code in the main program?

    4. For the Flash Sector C code, what should the BEGIN_FLASH address be ?

    Thank you,

    Chuck

  • 0 in reply to Charles Jackel
    TI__Guru 61235 points

    Chuck,

    I'm not seeing why your flashing the code into sector F, and then flashing it again into sector C.  Why not dump it into sector C in the first place?

    Regardless, your main app in sector A controls program execution.  The main app will ALWAYS run after a power cycle.  It then decides if and when it wants to transfer control to a different program (e.g., the code in sector C).  For your sector C code, you need to pick a hard address in sector C as I said earlier.  That is where you link the codestart section for the sector C project.  The main app then needs to branch to that hard, known address when it wants to transfer program control over to the sector C code.

    Charles Jackel said:

    1. How do I configure the Linker command file for the program that I flashed into Flash Sector C BEFORE I convert the .out file to a binary file?

    The codestart section (in file codestartbranch.asm) is linked to a known, hard address in sector C.  You then build the project.

    Charles Jackel said:

    2. How do I "adjust the branch destination" to point to the Flash Sector C code?

    You cannot have the ROM bootloader branch to sector C code.  The ROM bootloader will always branch to address 0x33FFF6, and that is in sector A.  Your main app has its code start branch instruction there.  You cannot change that.  It is your main app that must branch to the sector C code at the known, hard address you picked for this purpose in sector C.

    Charles Jackel said:

    3. I see you suggested adding asm(" LB 0x328000") into my main program to point to the address of the Flash Sector C.

    Assuming 0x328000 is the hard address you have selected for the execution transfer point in your sector C code project, then yes inline assembly is one way to do it.  Alternately, you could use a function pointer in C and assign the function pointer to that address.  People do it different ways.

    Charles Jackel said:

    4. For the Flash Sector C code, what should the BEGIN_FLASH address be ?

     
    The BEGIN_FLASH memory will be the known, hard address that you select in sector C for the code execution transfer point.  That address is up to you.  As I've said before, I suggest either the first or last address in the flash sector(s) that will be holding a particular project.  That gets the codestart section out of the way instead of busting up your flash in the middle of the sectors.
     
    - David
  • 0 in reply to David M. Alter
    Guru 20525 points

    Hello David!

    David M. Alter said:

    Hello Charles,

    First, a suggestion.  It is better to start a new thread instead of posting to an old thread, in particular a thread that is already marked as answered.  Once a thread is answered (or dated), it is much more likely to not get responded to.

    (Just in case). The fact that Charles has already started his thread on this topic  http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/293311/1022687.aspx#1022687. 

    But unfortunately I could not help him and none has answered him except me. Thank you for your answer.

    Regards,

    Igor