• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 83 subscribers
  • Views 3264 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.

Question about boot-loading and firmware update for F28335

Cedric 40627
Expert 1580 points
Other Parts Discussed in Thread: CONTROLSUITE, C2000WARE

Hi everyone,

I have read several post and documents but there are still some elements I am confused about regarding boot-loading of my F28335.

I would like to implement a firmware upgrade mode which would be active at boot-up when the main application is blank, corrupted (crc fails) or when an explicit call is made by a Host computer. From what I have understand, the most commonly way to do it is to have 2 independent projects : one for the main application and a second one which has the required interface drivers / Flash API. I followed this approach.

My project containing my main application is located in sectorD. I have checked the memory mapping and everything look in order.

My project which is used for upgrading is located in sectorA.

As a starting point, I have used the boot_rom example from controlSuite ( \libs\utilities\boot_rom\2833x). I use Init_Boot.asm (unchanged) as Initialization. From what I understand I can modify the selectMode_Boot.c to branch my code based on event described earlier.  The value returned from selectMode_Boot.c ("EntryAddr") would point to either the firmware upgrade code (somewhere in SectorA) or my main application somewhere in sectorD? Am I correct here ?

Any comments/ suggestions is welcome,

Thanks

  • 0
    TI__Guru 61235 points

    Cedric,

    You sound like you know what you are doing with the two projects.  Only thing I question is why you're using the boot ROM code as your model.  Forget about the TI boot ROM.  Let it run, and it will always go to your secondary bootloader in sector A.  All you need to do in your secondary bootloader is check the CRC (for example).  If it passes, branch to the hard coded control transfer address that starts your main app (you pick this hard address, and it is the same for both projects.  In secondary bootloader, you branch TO the address.  In main app project, you have a branch to the start of your main app (e.g., _c_int00) linked there).  If the CRC fails, start your flash reprogramming routine.  Simple.

    The ROM bootloader code is more extensive.  You don't need all that functionality.

    Regards,

    David

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

    David,

    Thanks again for your help. Actually I did that with my first design attempt ! ... but I had a problem to jump to my main app... so I figured there was something wrong with my boot-loader... That's why I have used boot rom ( I kept the Init boot .asm identical but I have stripped down all other useless files for my project) . OK well, I was on the right track thanks for your confirmation.

    In main app project, you have a branch to the start of your main app (e.g., _c_int00) linked there).

    Do I get the entry-point of my main app project from the header of the memory map once compiled with CCS( in my case it is 0x320000, for sectorD). When I jump to my main application I will have to jump to this address, correct ?

    Regards


  • 0 in reply to Cedric 40627
    TI__Guru 61235 points

    Cedric 40627 said:

    Do I get the entry-point of my main app project from the header of the memory map once compiled with CCS( in my case it is 0x320000, for sectorD). When I jump to my main application I will have to jump to this address, correct ?

     
    No.  That is not the best way because everytime your main app changes you need to change your secondary bootloader.  Pick a fixed address in the main app flash (typically the last two words in the flash that the main app uses).  You link the codestart section from the file CodeStartBranch.asm in your main app to this known address.  The codestart section contains a single LB (long branch) to the start of your main app (probably either wd_disable routine, or _c_int00).  Then all you need to do is have your secondary bootloader branch to this known address.  You can use inline assembly for this if needed.  Remember, you are not branching to a symbol, but a known address, e.g.
     
      asm(" LB 0x123456");
     
    - David
  • 0 in reply to David M. Alter
    Expert 1580 points

    Got it ! Thank you David :)

  • 0 in reply to Cedric 40627
    Expert 1580 points

    Hi David,

    It seems like I have a little problem here... I have restored my original work and I still have two projects.

    The DSP starts correctly my secondary bootloader, I can load my SCI driver and flash correctly the code of my main application to sectorD. After verification of the flashing I jump to a known location at the end of sector D (the two last bytes as suggested) with the assembly inline command asm("    LB 0x327FFE"); from my secondary bootloader code. After this jump, I am effectively in sectorD.

    At this known address, I have my mainAppCodeStartBranch.asm from my mainapp project which is just a simple "LB _c_int00" which let me jump to the entry point of my main app. I have verified and it effectively jumps to the entry point specified by the memory map of the main app.   However nothing happens after that and my DSP eventually resets.

    The dog is disabled.

    If I debug my main app as stand-alone with CCS, it is working properly. Did I misunderstand something you explained me ?

  • 0 in reply to Cedric 40627
    TI__Guru 61235 points

    Cedric,

    How do you know the dog is disabled?

    I don't think this problem has to do with the program transfer to your main app.  It sounds like you are getting there correctly.  Suggest setting a breakpoint at the LB 0x327FFE instruction, and stepping (I suspect you already did this).  So you get to _c_int00() for your main app.  Check the dog registers.  Make sure it is disabled.  What happens if you step through _c_int00?  Does it step OK?  The _c_int00 is probably too long to step through completely, so you will eventually do a Go Main (or set a BP at main at do a run, same thing).

    When you start running your main app, you need to load the symbols for that project (Run->Load->Load_Symbols in CCS).  You don't load the project, just the symbols.

    You can also replace your main app with a trivial, very simple project so you can completely step through _c_int00 and get a better idea what is happening.

    Personally, I am still suspicious of the dog.

    - David

     

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

    Suggest setting a breakpoint at the LB 0x327FFE instruction, and stepping (I suspect you already did this).  So you get to _c_int00() for your main app.

    Yes I did that, actually I arrive at the address of "boot.obj" of "rts2800_fpu32.lib". And yes it steps OK. The dog is disabled, my WDCR register is set to 0x00C0 (WDFLAG =1 and WDDIS =1) while I am running through it.

    As you suggested I put a ESTOP0 breakpoint as first instruction of my main app and it stops correctly there (and the dog is still disabled).

    The problem must be tied to my application then... As first functions of the main app, I execute the configuration of the clocks, interrupts, etc. as it would be for a boot up from reset. It works when I debug the project as stand-alone but maybe there is some conflicts when the secondary boot-loader is used.


    Thanks again David for your time.

    Regards,


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

    Sir what is flash reprogramming routine? how can i reprogram my flash? can you share some example scenario and code?

  • 0 in reply to Zohiab Wahab
    TI__Mastermind 19810 points
    Zohaib,
    please open a new thread for this question, so it gets attention.

    flash reprogramming is , performing an erase operation on the flash and programming with a new code/data in flash. The term comes into use mostly when we talk about firmware upgrades on an embedded system, when there is an application already running from flash but it needs an update. In which case the application provider will use a combination of options available in ROM or Flash to perform an erase on flash and program the new application.

    TI releases a flash kernel example in controlSuite or C2000ware depending on your device. For F28335x the example can be found in
    C:\ti\controlSUITE\device_support\f2833x\v142\DSP2833x_examples_ccsv5\f28335_flash_kernel

    Also you will have to refer to the flash api guide for your device to understand more on the Flash API.

    Hope this helps and I would suggest to open a new forum thread and post your questions over there. You can refer to this thread or other threads in your new post by pasting links as they seem relevant to you.

    Best Regards
    Santosh Athuru