infineon4engineers Facebook

infineon@google+ Google+

infineon@linkedin linkedin

infineon4engi@twitter twitter

infineon@youtube youtube

+ Reply to Thread
Results 1 to 4 of 4

Thread: UART bootloader with checksum capability (project attached)

  1. #1
    Intermediate Intermediate ErnieT is on a distinguished road
    Join Date
    Feb 2018
    Location
    Germany
    Posts
    16
    Points
    305

    UART bootloader with checksum capability (project attached)

    Hello!

    I guess a lot of people wrote their own bootloaders for the XMC4x00. Attached you'll find a DAVE 4 project of an UART bootloader which parses Intel .HEX files and transfers it to the application flash.

    specs:
    - no DAVE CE, just plain code
    - parses Intel .hex file and flashes it to application flash
    - for XMC4300, but will also run on XMC4800 with small changes (already ran it there)
    - supports custom .hex record with checksum (optional)
    - UART on P0.0 (RX) and P0.1 (TX), USIC 1, ch. 1
    - baudrates supported from 115200 to 1200000 baud
    - incoming data is buffered into RAM during flash operation to allow sending the .hex file in burst mode
    - can be controlled by simple terminal program, if UART-to-USB chip is used (FTDI/Microchip and others provide those chips)
    - bootloader is triggered by pin 15.3: high -> bootloader, low -> application (if it exists)
    - bootloader requires application to include ABM 1 header
    - optional bootloader-to-application bridge may be integrated into application to call specific PCB initialization code when switching to bootloader

    The code is documented (please read header file comments first). If you find bugs or have questions/recommendations, please reply here.

    Make sure to relocate your application to the 2nd flash page (starting at 0x4000) and include an ABM 1 header, because that's what the loader is looking for. If you need an example for that, leave a reply.

    Best regards,
    Ernie T.
    ?????
    Last edited by ErnieT; Yesterday at 11:29 PM. Reason: typos

  2. #2
    Beginner Beginner mprt is on a distinguished road
    Join Date
    May 2018
    Posts
    6
    Points
    130
    Thanks for the well documented example.

    But what's the advantage of the code running completely in RAM?
    That it can update itself?

    and why is
    #if defined(DEBUG_BUILD)
    void BOOTLOAD_startApp();
    #endif
    ?

    I didn't get how the Bootloader would then start the actual application through the ABM.
    (well, at least I can't locate the function in the code.)

    Is there any reason you used ABM1 for the Application and not ABM0?
    Last edited by mprt; Dec 13th, 2018 at 01:14 PM.

  3. #3
    Intermediate Intermediate ErnieT is on a distinguished road
    Join Date
    Feb 2018
    Location
    Germany
    Posts
    16
    Points
    305
    Quote Originally Posted by mprt View Post
    But what's the advantage of the code running completely in RAM?
    That it can update itself?
    Not sure why I ran it from RAM. I was used to do so when working with early Cortex chips, because they did not allow to access the flash while flashing. The XMC series has some nice flash cache, which probably allows fetching a few more instructions from flash before crashing too. But again, I'm not sure about it. Guess it does not make much difference performance wise whether you use RAM or ROM.

    Edit: The bootloader currently cannot update itself. I guess this could be made possible, because the XMC device has plenty of RAM to store the received data. Makes it easy to check data integrity before doing the actual flashing. But if flashing fails, there's no way going back, because the start-up code needs to be within first flash page.

    Quote Originally Posted by mprt View Post
    and why is
    #if defined(DEBUG_BUILD)
    void BOOTLOAD_startApp();
    #endif
    ?
    Seems this some code part from an earlier version, which can be deleted. I had problems running the application in debug mode for several reasons.

    Quote Originally Posted by mprt View Post
    I didn't get how the Bootloader would then start the actual application through the ABM.
    (well, at least I can't locate the function in the code.)
    The actual start-up of the application is placed in xmc/system.c in SYSTEM_startAppIfRequested(). This method is called from start-up code and decideds whether to start the app or the bootloader branch. The actual loading of the app is performed within the last block of code in this method:

    Code:
    		/* jump to application */
    		SCU_RESET->RSTCLR		= 1 << SCU_RESET_RSTCLR_RSCLR_Pos;						/* clear latest reset reason (otherwise debugger will fail) */
    		SCU_GENERAL->STCON		= BOOTLOAD_START_APP << SCU_GENERAL_STCON_SWCON_Pos;	/* set boot mode to use Alternate Boot Mode 1 (=application) */
    
    		__DSB();																		/* ensure completion of outstanding memory accesses before reset */
    		SCB->AIRCR 				= 0x5FAU << SCB_AIRCR_VECTKEY_Pos
    									| 1U << SCB_AIRCR_SYSRESETREQ_Pos;
    		__DSB();
    		for(;;) {																		/* wait until reset */
    			__asm volatile ("nop");
    		}

    Quote Originally Posted by mprt View Post
    Is there any reason you used ABM1 for the Application and not ABM0?
    ABM0 is placed earlier in flash than ABM1. Using ABM1 allows to me have a bigger contiguous area in flash for actual code. Saves me from wasting my time on scatter files.
    Last edited by ErnieT; Yesterday at 08:29 AM.

  4. #4
    Intermediate Intermediate ErnieT is on a distinguished road
    Join Date
    Feb 2018
    Location
    Germany
    Posts
    16
    Points
    305
    About running from RAM:
    XMC does not support fetching code from flash while doing erase and/or flash operations. After you uploaded the content and commanded the flash operation to start, the controller cannot fetch the next instructions placed in flash, because it is busy. As said before, the flash has a cache which may help you advancing a few steps in code, if the next few instructions are already cached. If not, your code execution is screwed. (Result may be a bus error or any other hardware interrupt.)

    If you decide to not actively wait for the flash operation to finish (as in the example code), you're better off running everything from RAM.
    Please read this thread: https://www.infineonforums.com/threa...ing-from-Flash

+ Reply to Thread

Tags for this Thread

Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.