This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

C166 : startup with a loader

Hi,

I use a C164 chip (similar to C166).
For my project, I'll have a bootloader (witch will be located in 0xC0'0000) and an applicative software (located in 0xC1'0000).

Is it possible to have the following flow chart ?

Start 0xC0'0000
if (A_FLAG_IN_FLASH == VALID_APPLI)
  Call Applicative_Startup
else
  Call Boot_Startup
endif

Boot_Startup and Applicative_Startup are the START_V2.A66 file for each project. They will be for sure different.

I don't find the way to do that in keil s options (move ICODE section to 0xC1'0000 didn't success with the linker, ...)

If you have some tips or application note, it will be great.

thks, Nick.

Parents
  • Hello,

    If my understanding is correct, you do not want to use the standard built-in bootstrap loader but rather a custom solution which you have named "bootloader", too.

    Let us remember that the built-in bootstrap loader must be loaded via UART from outside counterpart s/w into the internal RAM at FA40h, and is only 32-byte wide; typically there are 2 more bootstrapping stages: 2nd one loads bigger f/w code still into the internal RAM, and then this second code loads the main boot application into (external) RAM. This is the 3d part which takes care about erasing/writing/reading flash and/or eeprom, etc.

    Anyway, the built-in bootstrap mechanism assumes that the UART is being used (or CAN for some MCU steps) - which is not your case. Pay attention, the bootstrapping f/w should be run from within the RAM in order to erase and write flash.

    So in other words, it is possible to have this scenario:

    Start at reset vector (0h)
    Jump to <User address>
    Check flash
    Branch either to:
     a) main application - run it,
        or
     b) custom bootloader, part #A (1/2) - run it
    In case b):
     - the #A copies another part #B (2/2) from flash to RAM
     - the #A transfers control to #B (sits now in the RAM)
    

    As a result, this is the #B who actually provides bootstrapping service.

    Note that both #A and #B are stored in the flash, but the #B - just as an array of codes. That is, this custom bootloader #B should be build in assuption it will run from RAM, not from flash - but, will reside in the flash. All of this involves additional steps when working with Keil. Look at the application note #138 (In-system FLASH Programming with C16x/ST10) for more details on technical side:
    http://www.keil.com/appnotes/docs/apnt_138.asp.
    It tells how to use compiler and linker to move program code into RAM for execution while loading flash PM.

    Regards,
    Nikolay.

Reply
  • Hello,

    If my understanding is correct, you do not want to use the standard built-in bootstrap loader but rather a custom solution which you have named "bootloader", too.

    Let us remember that the built-in bootstrap loader must be loaded via UART from outside counterpart s/w into the internal RAM at FA40h, and is only 32-byte wide; typically there are 2 more bootstrapping stages: 2nd one loads bigger f/w code still into the internal RAM, and then this second code loads the main boot application into (external) RAM. This is the 3d part which takes care about erasing/writing/reading flash and/or eeprom, etc.

    Anyway, the built-in bootstrap mechanism assumes that the UART is being used (or CAN for some MCU steps) - which is not your case. Pay attention, the bootstrapping f/w should be run from within the RAM in order to erase and write flash.

    So in other words, it is possible to have this scenario:

    Start at reset vector (0h)
    Jump to <User address>
    Check flash
    Branch either to:
     a) main application - run it,
        or
     b) custom bootloader, part #A (1/2) - run it
    In case b):
     - the #A copies another part #B (2/2) from flash to RAM
     - the #A transfers control to #B (sits now in the RAM)
    

    As a result, this is the #B who actually provides bootstrapping service.

    Note that both #A and #B are stored in the flash, but the #B - just as an array of codes. That is, this custom bootloader #B should be build in assuption it will run from RAM, not from flash - but, will reside in the flash. All of this involves additional steps when working with Keil. Look at the application note #138 (In-system FLASH Programming with C16x/ST10) for more details on technical side:
    http://www.keil.com/appnotes/docs/apnt_138.asp.
    It tells how to use compiler and linker to move program code into RAM for execution while loading flash PM.

    Regards,
    Nikolay.

Children