Hot!Bootloader problems

Author
microlit
Starting Member
  • Total Posts : 65
  • Reward points : 0
  • Joined: 2003/11/07 12:44:14
  • Location: Ireland
  • Status: offline
2012/01/04 06:04:40 (permalink)
0

Bootloader problems

I want to write a simple bootloader that will read firmware binary data in external serial Flash and use it to re-program the Main Application in PIC32 internal Flash.   The data will have been put there in the first place, and validated, by the Main App, then a soft reset causes the bootloader to run, it sees a flag in external Flash by which it knows that firmware is there, etc.

My understanding is that the bootloader will be a separate MPLAB project, with its own linker file.  The bootloader and Main App linker files have to be crafted so as to allocate each other space.  My first intention is to try to fit my bootloader into boot flash, since it is simple.

I have of course read the various forum posts on the subject, and several Microchip pdf documents, and I think I now understand the subject but clearly I do not.

I have had much difficulty.  If the linker script does not make sense to MPLAB then sometimes it reports an error, other times MPLAB will lock up, and on closing will leave part in memory and the only recourse is to re-boot the PC, which is grievous.  Thankfully I am past that stage: now I have a linker script for the Main App that LOOKS to me as if it is right, and which compiles without warning or error, and I can program my target (based on Ethernet Starter Kit). However although MPLAB says the firmware is running, it is not.  For example I have a status LED which should flash and it does not.  If I revert to the Microchip linker file, all is well again, soi it is not my code.

Not only that, but an inspection of the exported hex (programming) file shows that the linker script is only partially being obeyed.   The main memory flash is correctly loaded, but the boot flash has data not only at physical address 1FC02FF) as expected, but also from 1FC00000 to about 1FC001B9 and thereafter 0xFF up to 1FC02FE0 with the exception of 8 or 16 bytes here and there that look like exception vectors.  Which is not what my linker script asks for.

Can anyone tell me what I am doing wrong?

The following files are (1) the unaltered "procdefs.ld" that Microchip supply for the PIC32MX795F512L, and (2) my version "myprocdefs.ld" which tries to free up as much boot flash as is reasonably possible.  By the way I have also copied the Microchip "elf32pic32mx.x" to my project folder, renamed it as "elf32pic32mx.ld", and edited the include line to point to my version "myprocdefs.ld".

 
/*************************************************************************  * Processor-specific object file.  Contains SFR definitions.  *************************************************************************/ INPUT("processor.o")
/*************************************************************************  * For interrupt vector handling  *************************************************************************/ PROVIDE(_vector_spacing = 0x00000001); _ebase_address = 0x9FC01000;
/*************************************************************************  * Memory Address Equates  *************************************************************************/ _RESET_ADDR              = 0xBFC00000; _BEV_EXCPT_ADDR          = 0xBFC00380; _DBG_EXCPT_ADDR          = 0xBFC00480; _DBG_CODE_ADDR           = 0xBFC02000; _DBG_CODE_SIZE           = 0xFF0     ; _GEN_EXCPT_ADDR          = _ebase_address + 0x180;
/*************************************************************************  * Memory Regions  *  * Memory regions without attributes cannot be used for orphaned sections.  * Only sections specifically assigned to these regions can be allocated  * into these regions.  *************************************************************************/ MEMORY {   kseg0_program_mem    (rx)  : ORIGIN = 0x9D000000, LENGTH = 0x80000   kseg0_boot_mem             : ORIGIN = 0x9FC00490, LENGTH = 0x970   exception_mem              : ORIGIN = 0x9FC01000, LENGTH = 0x1000   kseg1_boot_mem             : ORIGIN = 0xBFC00000, LENGTH = 0x490   debug_exec_mem             : ORIGIN = 0xBFC02000, LENGTH = 0xFF0   config3                    : ORIGIN = 0xBFC02FF0, LENGTH = 0x4   config2                    : ORIGIN = 0xBFC02FF4, LENGTH = 0x4   config1                    : ORIGIN = 0xBFC02FF8, LENGTH = 0x4   config0                    : ORIGIN = 0xBFC02FFC, LENGTH = 0x4   kseg1_data_mem       (w!x) : ORIGIN = 0xA0000000, LENGTH = 0x20000   sfrs                       : ORIGIN = 0xBF800000, LENGTH = 0x100000   configsfrs                 : ORIGIN = 0xBFC02FF0, LENGTH = 0x10 } SECTIONS {   .config_BFC02FF0 : {     KEEP(*(.config_BFC02FF0))   } > config3   .config_BFC02FF4 : {     KEEP(*(.config_BFC02FF4))   } > config2   .config_BFC02FF8 : {     KEEP(*(.config_BFC02FF8))   } > config1   .config_BFC02FFC : {     KEEP(*(.config_BFC02FFC))   } > config0 }




 
/*************************************************************************  * (2) Processor-specific object file.  Contains SFR definitions.  *************************************************************************/ INPUT("processor.o")
/*************************************************************************  * For interrupt vector handling  *************************************************************************/ PROVIDE(_vector_spacing = 0x00000001); _ebase_address  = 0x9D001000;  /* = exception_mem */
/*************************************************************************  * Memory Address Equates  *************************************************************************/ _RESET_ADDR              = 0xBD000000; /* = kseg1_boot_mem */ _BEV_EXCPT_ADDR          = 0xBD000380; _DBG_EXCPT_ADDR          = 0xBD000480; _DBG_CODE_ADDR           = 0xBFC02000; _DBG_CODE_SIZE           = 0xFF0     ; _GEN_EXCPT_ADDR          = _ebase_address + 0x180;
/*************************************************************************  * Memory Regions  *  * Memory regions without attributes cannot be used for orphaned sections.  * Only sections specifically assigned to these regions can be allocated  * into these regions.  *************************************************************************/ MEMORY {   kseg0_program_mem    (rx)  : ORIGIN = 0x9D002000, LENGTH = 0x7E000 /* main */   kseg0_boot_mem             : ORIGIN = 0x9D000490, LENGTH = 0x970      /* startup code */   exception_mem              : ORIGIN = 0x9D001000, LENGTH = 0x1000   kseg1_boot_mem             : ORIGIN = 0xBD000000, LENGTH = 0x490   debug_exec_mem             : ORIGIN = 0xBFC02000, LENGTH = 0xFF0   config3                    : ORIGIN = 0xBFC02FF0, LENGTH = 0x4   config2                    : ORIGIN = 0xBFC02FF4, LENGTH = 0x4   config1                    : ORIGIN = 0xBFC02FF8, LENGTH = 0x4   config0                    : ORIGIN = 0xBFC02FFC, LENGTH = 0x4   kseg1_data_mem       (w!x) : ORIGIN = 0xA0000000, LENGTH = 0x20000   sfrs                       : ORIGIN = 0xBF800000, LENGTH = 0x100000   configsfrs                 : ORIGIN = 0xBFC02FF0, LENGTH = 0x10 } SECTIONS {   .config_BFC02FF0 : {     KEEP(*(.config_BFC02FF0))   } > config3   .config_BFC02FF4 : {     KEEP(*(.config_BFC02FF4))   } > config2   .config_BFC02FF8 : {     KEEP(*(.config_BFC02FF8))   } > config1   .config_BFC02FFC : {     KEEP(*(.config_BFC02FFC))   } > config0 }






Michael



post edited by microlit - 2012/01/04 06:13:15
#1

10 Replies Related Threads

    Jim Nickerson
    User 452 _
    • Total Posts : 5127
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: offline
    Re:Bootloader problems 2012/01/04 10:46:41 (permalink)
    0
    Maybe you could attach the .ld files used for the bootloader and application as xxx.ld.txt files ( must be .txt to attach ).
    Both are required to see what is going on.
    #2
    microlit
    Starting Member
    • Total Posts : 65
    • Reward points : 0
    • Joined: 2003/11/07 12:44:14
    • Location: Ireland
    • Status: offline
    Re:Bootloader problems 2012/01/05 06:50:43 (permalink)
    0

    HOW TO MAKE YOUR VERY OWN BOOTLOADER, IN BABY STEPS

    As is often the case I think I have solved my own problem.  There may be others similarly confused to me, so I will describe my solution.  Attached is a dummy project that works on the Ethernet Starter Kit (you may have to change the LED port because I have extra stuff glued onto my Kit).  You will need to add the Microchip Configs folder to define the Ethernet Starter Kit hardware as defined in attached "HardwareProfile.h", it was too big to include in the attached zip.
    Requirement
    A PIC32 bootloader that will read firmware binary image previously recorded to external serial Flash, and use it to re-program the main-application.  Thus the main-application deals with the firmware file upload from where-ever and storing it in the serial flash.  

    The dummy project attached does not include any flash routines, all it is concerned with is the demarcation of program memory required for any bootloader.  On boot-up, the bootloader code runs and tests the serial flash to see if firmware upgrade is pending.  If not it simply jumps into the start of the main-app.

    The dummy project flashes a bi-colour LED (you could use 2 separate LED's) in ways that clearly show the operating stages:
    (a) one second long flash green at boot-up
    (b) repetitive short green/ amber flashes whilst in bootloader mode while() loop
    (c) user presses a button to exit from this mode
    (d) long red flashes to indicate successfull jump into main-application

    Introduction
    I read many forum posts but these only served to confuse me.  I read a lot of Microchip documentation which has good stuff but not easy to prise out.  See reference section below.

    Not a single post described the whole process in a way that a dummy like me could understand.  Some people appeared (but I could not be sure) to make the bootloader a separate MPLAB project, but I could not see how the two projects (bootloader and main-app) could be combined at the initial programming stage.  My approach is to build both bootloader and main-app as one MPLAB project.

    Then there are those that say that a bootloader is too hard, why not shell out c. $200 for a commercial one?  But I have been there, done that.  The commericial products are doubtless good is what you want to do is within what their product can support, but more often than not what I want to do is different!

    Challenge No. 1
    A requirement is that the bootloader in its entirety must reside in a write-protected area of memory and the main-app code must reside somewhere else - there can be no overlap because the main-app region will be erased by the bootloader.  This would be easy in PIC18 assembler, but not so easy in C32.  

    Challenge No. 2
    It is hard to predict where the compiler and linker will place your code.  The bootloader needs an invariant starting point in the main-app code, so it can jump there.

    Method Overview
    Bootloader and main-application are part of a single MPLAB project.
    Changes to the linker scripts are required.
    An unused IVT entry is used as an invariant address to jump into the main-application

    Method in detail 
    (no need to check out the attached but I have included it for completeness - it is working code)
    1. Edit the linker scripts
            Copy default linker file "elf32pic32mx.x" to project folder and rename as "elf32pic32mx.ld"
            Copy default linker file "procdef.ld" to project folder
            For simplicity leave the boot flash area with its default configuration of IVT and C start up code
            Create in file "elf32pic32mx.ld2 a new section name ".bootload"
            Give it space at beginning of main flash memory in file "procdefs.ld" thus:
                    kseg0_bootload_mem   (rx)  : ORIGIN = 0x9D000000, LENGTH = 0x4000
                    kseg0_program_mem    (rx)  : ORIGIN = 0x9D004000, LENGTH = 0x7C000
            (the length 0x4000 may be reduced once I see how big the bootloader is)

    2. Alter the configuration bits to write protect the above bootloader area (can be done in 0x1000 chunks)
            
    3. Every function that is part of the bootloader has to have a section attribute like
            INT __attribute__ ((section (".bootload"))) main(void)
    to ensure that it is placed by the linker in my special, protected memory area.

    4. The bootloader needs to jump to the main-application if it has no firmware to load.  The main-application no longer has a predictable "main()" function, so its starting point could be located anywhere at the whim of the compiler and linker.  To overcome this I use an unused IVT (interrupt vector table) entry, vector(62) seems to work.  The IVT entries have fixed absolute addresses.  By using the vector attribute on the main application starting point (what used to be its "main()" like:
            void __attribute((vector(UNUSED_VECTOR))) StartProper(void) {
    the compiler will place a jump to its address at the 62'th IVT entry, thus the bootloader jumps to the known absolute address of vector 62, which in turn jumps to unknown (relative) address of StartProper.  This is a common technique in PC assembler programming.


    5. Code has yet to be written to make the bootloader do what I want.  Clearly this code must not call library routines, and cannot use interrupts because their handlers are in the main-application.  But the required task is easy enough - I think I can write non-interrupt code to read the external serial flash, and Microchip provide sample code for erasing and programming the internal program flash.

    I hope that this post helps some other poor soul and save them having to waste 3 days in a quagmire with no-one to help!

    References
    TB3015 Use PIC32 Boot Flash to expand Program Memory
    DS51686B MPLAB® C Compiler for PIC32 MCUs User’s Guide
    DS61108E  PIC32 Reference Manual: Section 8. Interrupts
    DS61156B-page 111  PIC32MX5XX/6XX/7XX Data Sheet
    DS51833A-page 137  32-Bit Assembler, Linker and Utilities User’s Guide
    DS61124E-page 32-13 Reference Manual: Section 32. Configuration


    #3
    MikeN
    Senior Member
    • Total Posts : 176
    • Reward points : 0
    • Joined: 2005/11/03 06:26:06
    • Status: offline
    Re:Bootloader problems 2012/01/05 08:44:14 (permalink)
    0
    Thanks for coming back with your solution, I was wondering about where you were.


    One way to combine two separate projects is to turn the bootloader into a byte array, and force the linker to put it in a fixed location. This ensures the library code that may be used is not shared between main and boot. Putting the two parts in the same project makes it impossible to ensure this otherwise.


    So create


    const rom boot[] = {0, 1, 2, 3 ...} and fix its location in the linker - I don't know how to do this with C32, but have done it with IAR and ARM cores, and with C18 tools.


    You will also have to ensure the vector tables are properly located for each part of the operation. I have usually put a separate jump table (array of pointers to functions) in a fixed location in C18 as they do not have the feature of moveable vector tables. This slows down the interrupt handling by a small amount.


    A tool called srec can make the data definition from an srec file (or a wide variety of others) - there are some other posts around about this.

    Hope this rambling is helpful.

    Mike Newsome, MJN Design Solutions, England
    #4
    ErnieM
    Super Member
    • Total Posts : 375
    • Reward points : 0
    • Joined: 2007/10/13 02:54:02
    • Location: 0
    • Status: offline
    Re:Bootloader problems 2012/01/05 17:48:30 (permalink)
    0
    If your bootloader sends the program counter off to the app's main() then you are bypassing any start-up code c puts there, like variable assignements. Not a good thing for the general case.

    Take a peek at AN1388 which looks like it was updated as recently as yesterday. I used that app note when I updated my SD bootloader from C32 v1.11 to c2.01, though I did not follow it exactly  since I placed kseg0_boot_mem, exception_mem, kseg1_boot_mem before kseg0_program_mem instead of after.

    Why I did that I no longer recall, except the code works once again.

    As my bootloader is too large to fit in boot flash I place it with the application. The bootloader is built on it's own and can use the default linker, though I use a custom one to raise an error if the code grows too large.

    My app code is also built on it's own using a custom link script.

    Any start of the code begins with the bootloader. The bootloader calls the application code at the kseg1_boot_mem address, which runs the start-up c code.
    #5
    microlit
    Starting Member
    • Total Posts : 65
    • Reward points : 0
    • Joined: 2003/11/07 12:44:14
    • Location: Ireland
    • Status: offline
    Re:Bootloader problems 2012/01/07 00:57:22 (permalink)
    0
    Thanks for your comments - I can see I have some more work to do!
    #6
    ControlGadgets_Geoff
    New Member
    • Total Posts : 26
    • Reward points : 0
    • Joined: 2010/10/04 00:58:03
    • Location: Australia
    • Status: offline
    Re:Bootloader problems 2012/01/17 17:46:26 (permalink)
    0
    FYI. I just got AN1388 to work with a C32MX running TCPIP with USB MSD (big program (96k words). I found two errors in the demo app linker script provided. The linker works fine for the small demo but would not work with our larger program. kseg1_data_mem (w!x) : ORIGIN = 0xA0000000, LENGTH = 0x2000 probably should be kseg1_data_mem (w!x) : ORIGIN = 0xA0000000, LENGTH = 0x20000 and kseg0_program_mem (rx) : ORIGIN = (0x9D006000 + 0x1000 + 0x970 + 0x490), LENGTH = 0x3000 kseg0_program_mem (rx) : ORIGIN = (0x9D006000 + 0x1000 + 0x970 + 0x490), LENGTH = (0x80000 - (0x1000 + 0x970 + 0x490)) I hope this helps somewone.
    post edited by ControlGadgets_Geoff - 2012/01/17 18:28:19

    Geoff Vanstan
    Software Engineer
    GNT Engineering Pty Ltd
    Australia
    All software is beta till obsolete.
    #7
    rkrishnan7
    New Member
    • Total Posts : 20
    • Reward points : 0
    • Joined: 2011/06/27 21:22:29
    • Location: USA
    • Status: offline
    Re:Bootloader problems 2012/03/07 07:43:08 (permalink)
    0
    FYI.
    I also got my UART bootloader to work yesterday after a lot of struggling. 
    Here's what:
    I followed the instructions in AN1388 (the latest version from the Microchip web site).
    I got verify errors after programming an App from the WIndows GUI.
    I threw away the .ld linker file I had meticulously created and used the Microchip supplied app.ld located at:
    C:\Universal Bootloader_011112\Universal Bootloader\Firmware\Demo_Application
    and everything worked!

    I compared my now abandoned .ld with this app.ld and found that teh difference - 
    AN1388 reccommends _ebase_address = 0x9D000000;
    app.ld :    _ebase_address = 0x9D006000;
    Ofcourse, this change in address is also evident all over the rest of the linker file.
    The bootloader app itself still points to 0x9D000000 as per AN1388.

    As I have simply stumbled on to a solution for my specific problem, I am not at sure as to why this works. Any clues?

     
    #8
    rwilcher
    New Member
    • Total Posts : 27
    • Reward points : 0
    • Joined: 2012/03/25 08:21:20
    • Location: 0
    • Status: offline
    Re:Bootloader problems 2012/07/14 15:35:06 (permalink)
    0
    Definitely helped me ! Glad you mentioned it. grin
     
    #9
    filipdimitrov.com
    Starting Member
    • Total Posts : 79
    • Reward points : 0
    • Joined: 2010/12/27 06:34:43
    • Location: 0
    • Status: offline
    Re:Bootloader problems 2012/07/16 07:37:58 (permalink)
    0
    I've completed my own UDP bootloader some time ago, so here is my experience so far.
    Bootloader & main code can co-exist in one project since they are not overlapping.
    No need for any "strange" bootloader arrays etc. You just need proper bootloader script.

    1. Use regular project to design/code/test your bootloader program as far as you can (except writing in flash, which is quite simple operation)
    Keep in mind not to use ANY library (or not) functions, outside your boot program, since they will be deleted/reallocated when bootloader re-program flash.
    Also you may consider to serve WDT just in case you need it at later stage.

    2. Merge the 2 linker scripts (elf32pic32mx.x and procdef.ld) in one and add it in project AS PROJECT LINKER SCRIPT.

    3. Gradualy remove all sh*ts from boot memory (IVT, startup code, debug code). (see also point 4)
    Debug is ICD debuger related (and some other debugger I don't remember now) so I delete all related debug stuff.
    We want all user code including IVT, GE, C startup code, to be in user memory, so user can upload any changes there with our bootloader.

    I've endup with memory layout like this :

    _ebase_address = 0x9D001000;

    _RESET_ADDR                = 0xBFC00000;                    /* Can't be changed */
    _BEV_EXCPT_ADDR            = 0xBFC00380;                    /* Can't be changed */
    _GEN_EXCPT_ADDR            = _ebase_address + 0x180;
    _STARTUP_ADDR            = 0x9D002000;

    MEMORY
    {
        kseg0_dev_config_mem    (r)        : ORIGIN = 0x9D000000, LENGTH = 0x1000        /* Application + bootloader persistent data */
        kseg0_exception_mem        (rx)    : ORIGIN = 0x9D001000, LENGTH = 0x1000        /* Exceptions/Interrupts = _ebase_address */
        kseg0_startup_mem        (rx)    : ORIGIN = 0x9D002000, LENGTH = 0x400        /* C startup code = _STARTUP_ADDR */
        kseg0_program_mem        (rx)    : ORIGIN = 0x9D002400, LENGTH = 0x80000 - 0x1000 - 0x400 - 0x1000

        kseg1_dev_config_mem    (r)        : ORIGIN = 0xBD000000, LENGTH = 0x1000        /* _DEV_CONFIG_ADDR_..., _DEV_CONFIG_BLOCK_SIZE */
        kseg1_boot_mem            (rx)    : ORIGIN = 0xBFC00000, LENGTH = 0x2FF0
        kseg1_configsfrs_mem    (r)        : ORIGIN = 0xBFC02FF0, LENGTH = 0x10

        kseg1_data_mem            (w!x)    : ORIGIN = 0xA0000000, LENGTH = 0x20000
        sfrs                            : ORIGIN = 0xBF800000, LENGTH = 0x100000

        /* DUMMY sections to satisfy compiler map file generation crap!!! */
        kseg0_boot_mem                    : ORIGIN = 0x0, LENGTH = 0x0
        exception_mem                    : ORIGIN = 0x0, LENGTH = 0x0
    }

    SECTIONS
    {
    ...............................
      /*  Starting with C32 v2.00, the startup code is in the .reset.startup section.
       *  Keep this here for backwards compatibility.
       * WELL, I LIKE startup code to be in .startup section !!!
       */
      .startup ORIGIN(kseg0_startup_mem) :
      {
        KEEP(*(.startup))
      } > kseg0_startup_mem

      /*
       * Boot memory code, keep above other TEXT sections
       */
      .bootloader_code :
      {
        *\Proc_*.o (.text .rodata)
        . = ALIGN(4) ;
      } >kseg1_boot_mem
    ...............................
    }

    4. Add C startup code directly to your project (copy crt0.S file to your project dir and remove option form project settings to add startup code).
    At the begining of file, change code startup section like :
            ##################################################################
            # Startup code
            ##################################################################
    #if defined(USE_OLD_DOTSECTION)
            .section .startup,"ax",@progbits
    #else
            .section .startup,code
    #endif
            .set noreorder
            .ent _startup
    _startup:........


    5. Reallocate bootloader program in boot memory. In linker script above, I'm redirecting all output from all files started with "Proc_" to go to boot memory.
    You can also use function attributes, but this is easyer.

    6. Make custom boot C startup code. Copy original startup code from crt0.S, and strip it as you want.
    Save file as Proc_crt0.S for example.

    7. At begining of Proc_crt0.S write code to deal with various device reset flags...well this requires knowledge of ASM a bit, but not so much.
    For example I want my device to enter PROG (or PROC my typing mistake in examples :) when device is reset by MCLR reset.
    I have jumper in my board (use ICSP header actually), so if SW/FW blocks, I can reset it in prog mode and reprogram.
    You can make it to enter PROG mode also if WDT reset is in place.
    I have actually configuration bits for this in kseg0_dev_config_mem memory, which can be configured with UDP request.
    This part is a bit tricky, because if PIC have devices that hold down MCLR till power is stable, each reset will enter PROG mode.
    If this is the case, check if reset because of POWER drop, skip MCLR check if it, since it will be allways ON.

    8. Add code in Proc_crt0.S that checks for valid program in flash.
    For example, when I begin program, I first erase all flash with BULK erase (without bootloader mem of course). Then program. Then verify. Then write firmware version in a fixed location.
    If my bootloader detect that there is no valid program in flash (firmware version is 0xFF or 0x00), I go to PROG mode.

    9. Develop code, that may switch to PROG mode from main code, without HW reset. (if required).
    In my case I'm simulating MCLR reset by manipulating device reset bits.

    10. Develop application (windows, linux whatever) capable of program/reset (in various modes) these devices. (if required)

    ===========================
    Using this (or ANY) bootloader, we have some restrictions in main code :
    1. All projects must use our new linker script
    2. All projects must use initial configuration bits (they cannot be reprogrammed)
    SRS levels are especially hard to remember to sync :D WDT times etc.
    3. Use our custom crt0.S
    4. At the begining of MAIN code, check (if need to) and CLEAR RCON bits for reset : SWR, EXTR, POR, BOR, WDTO before any other code.

    ======================================



    All things that you want to do for bootloaders allready exist in Microchip provided code.
    For example going from Proc_crt0.S to bootloader C code, exist in crt0.S to main().
    There is no need to use interrupts etc to do this. Especially if they are in user program space, whwre user can easily overlap this vector.

    This is only a general guide, you need of course some more changes in linker script. I can't post more code since its a bit confidential.
    Hope this helps someone.

    Filip
    #10
    GANDAMALA
    New Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2018/03/19 22:37:34
    • Location: 0
    • Status: offline
    Re:Bootloader problems 2018/04/05 23:15:44 (permalink)
    0
    Hello Friends,

     
    Myself G. Praveen Kumar. I am a new participant in this group. I want information about 2-Stage Booting like "Boot Stage 1(Microchip)", "Boot Stage 2 (Application)" and "the applications .
     
    At present, I have Bootloader and its application project. But I want to know about Second Stage Boot Loader. Can anyone help me out and tell the detailed procedure about the 2-Stage Boot Loader.
     
    One point I want to add that I am using MPLAB IDE V3.65 XC32(V2.05), pic32mz2048efg100 
     
    I will be waiting for your replies.
     
     
    Thank you,
     
    Yours faithfully,
    G. Praveen Kumar
    #11
    Jump to:
    © 2018 APG vNext Commercial Version 4.5