Hot!how to add bootloader on my project for dsPIC33 using EZBL library??

Author
piffi
New Member
  • Total Posts : 10
  • Reward points : 0
  • Joined: 2018/08/23 04:36:17
  • Location: 0
  • Status: offline
2018/08/31 03:47:33 (permalink)
0

how to add bootloader on my project for dsPIC33 using EZBL library??

Hi,
I have an MPLABX project (v5.0) compiled with XC16 (ver.1.35) for my dsPIC33 board fully functional. I would like to add to this project the bootloader in order to update the firmware from uart U2 port.
I have performed all the steps of exercises number 1,2 and 3 described in the "EZBL Hands-on Bootloading Exercises.pdf" document.
In this way I can upload via uart on my dsPIC33 board  the sample application "ex_app_led_blink" and everything works properly.
At this point I thought of copying in my new project folder the "ezbl_integration" folder and the "makefile" file from the example "ex_app_led_blink" used before.
In MPLABX I imported the following files into the respective sections:
-ezbl_integration/ezbl.h
-ezbl_integration/ezbl_app.mk
-ezbl_integration/ex_boot_uart.merge.gld
-ezbl_integration/ex_boot_uart.merge.S
I deleted in the the main.c all "#pragma config" statements and I tried to build all my new project.
Initially I had the following error:
...ation/ex_boot_uart.merge.S:72: undefined reference to `__reset'
following this guide I solved:
https://www.microchip.com/forums/m979702.aspx
and the compilation was successful.
now my new project is loaded via uart in my card but I get this error:
"Bootloader read-back verification mismatch in reserved address range"
 
Is correct this method to add the bootloader to a working standalone project??
 
What does this error message mean ??
 
thank you all
#1

8 Replies Related Threads

    HowardSchlunder
    MCU16 Applications
    • Total Posts : 744
    • Reward points : 0
    • Joined: 2007/06/14 16:26:19
    • Location: Chandler, AZ
    • Status: offline
    Re: how to add bootloader on my project for dsPIC33 using EZBL library?? 2018/09/06 20:51:34 (permalink)
    5 (3)
    In EZBL v2.10 and newer editions (EZBL v2.11 is the current latest), all run-time programming error messages are documented in "help\EZBL Library Documentation.pdf" -> ezbl_comm C Project -> Communications Status Codes and Error Messages. Click on the 0xFFE7: EZBL_ERROR_SOFT_VERIFY_ERROR (-25) link for your particular message.
     
    This error means the bootloader defined by your ex_boot_uart.merge.S/.gld files do not match the bootloader you already have executing in flash on your target chip.
     
    EZBL requires an exact binary 1-to-1 match between the bootloader on the target and the ex_boot_uart.merge.S contents (+ consistent .gld information) because these files define the flash geometry occupied by the Bootloader, indirectly defines the flash geometry that the linker is allowed to stuff your Application code into, sets the address the Application must place its Interrupt Goto Table at, and tells the linker where the Application's __reset entry point needs to be. Also, because EZBL permits Application projects to directly call Bootloader functions without having a duplicate copy of such functions in flash, the .merge.S file tells the linker the exact addresses where all the Bootloader's functions and global variables individually start at.
     
    You receive this error due to procedural problem - typically by rebuilding and programming via ICSP a modified Bootloader without updating the ex_boot_uart.merge.S and ex_boot_uart.merge.gld files in the Application, or, by rebuilding a modified Bootloader and successfully propagating the .S/.gld files, but forgetting to reprogram the Bootloader via ICSP after changing it.
     
    Resolve the problem by reprogramming your Bootloader via ICSP, ensure the ex_boot_uart\dist\uart\production\ex_boot_uart.merge.S and .gld files are the exact same files as the ones included in your Application project, then rebuild and reattempt bootloading the Application.
     
    By default, the ezbl_boot.mk makefile in your Bootloader project auto-propagates the .merge.S/.gld files to the ex_app_led_blink\ezbl_integration folder as a post-build step that executes every time you rebuild the Bootloader, so the projects stay in agreement at the project/file-system level. To retain this functionality when introducing a new Application project, you should add the relative path to your appProject.X/ezbl_integration folder to the appMergeDestFolders variable located near the top of of the Bootloader's ezbl_boot.mk file. Alternatively, you could delete your appProject.x\ezbl_integration\*.S and *.gld files (to eliminate accidental future use) add the relative path to the ex_boot_uart\ezbl_integration\ex_boot_uart.merge.S and .gld files to your MPLAB Application project.
     
     
    Regarding the "undefined reference to '__reset'" error, can you provide the:
    • Version of EZBL you are using
    • Target device part number
    • PC's OS
    • Full linking command line shown in the output window. This is the xc16-gcc line just before the memory report and contains the .elf filename in it and only .o input files, not .c or .s files as well.
    __reset is a symbol defined in the Compiler Run-Time (CRT) and I believe the linker should be able to find it unless your linker script has missing or malformed CRT0_STARTUP() and/or CRT1_STARTUP() statements, or, you've checked the xc16-ld "Exclude standard libraries" checkbox, but haven't provided a replacement CRT. Neither of these cases seem very likely though, so could you also indicate if adding:
    EZBL_KeepSYM(_resetPRI); to one of your .c files works instead of changing .merge.S's goto statement?
     
    Note that there is only one leading underscore on the symbol name in this macro call, not two like it appears in .s/.gld files and you have to #include "ezbl_integration\ezbl.h" before this statement appears.
    #2
    Jim Nickerson
    User 452
    • Total Posts : 5445
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: offline
    Re: how to add bootloader on my project for dsPIC33 using EZBL library?? 2018/09/07 06:23:43 (permalink)
    0
    Howard,
    Very clever method to enable "Application projects to directly call Bootloader functions"
    #3
    piffi
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2018/08/23 04:36:17
    • Location: 0
    • Status: offline
    Re: how to add bootloader on my project for dsPIC33 using EZBL library?? 2018/09/11 00:40:13 (permalink)
    0
    Hi HowardSchlunder,
    before writing on the forum I had already read the description of the error messages on the document "help \ EZBL Library Documentation.pdf" but the solution reported (essentially the same as you wrote on the post) did not solve the problem.
    I have already used in the new my project the same files used for the ex_app_led_blink test project (fully functional)  and therefore uploaded to the dsPIC. In addition, in MPLABX I imported the following files into the respective sections:
    -ezbl_integration / ezbl.h
    -ezbl_integration / ezbl_app.mk
    -ezbl_integration / ex_boot_uart.merge.gld
    -ezbl_integration / ex_boot_uart.merge.S
    I solved the problem of the message "Bootloader read-back verification mismatch in reserved address range" by removing empirically the check (before compiling) under "Allow overlapped sections" in xc16-ld "Project Properties".
    what does this mean ?? is the correct solution ??
     
    The "__reset" problem has already been reported in this post https://www.microchip.com/forums/m979702.aspx
    anyway
    Version of EZBL: 2.10
    Target device part number: dsPIC33EP256GM310
    PC's OS: Windows 7 64 bit
    command line shown in the output window:
     
    nbproject/Makefile-default.mk:247: recipe for target 'dist/default/production/SCH_SDCB_conBOOT_new.production.hex' failed
    nbproject/Makefile-default.mk:90: recipe for target '.build-conf' failed
    nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
    c:/program files (x86)/microchip/xc16/v1.35/bin/bin/../../lib\libpic30-elf.a(crt0_extendedep.o)(.init+0x0): In function `__reset':
    : multiple definition of `__resetPRI'
    c:\program files (x86)\microchip\xc16\v1.35\bin\bin\..\bin/elf-ld.exe: Link terminated due to previous error(s).
    make[2]: *** [dist/default/production/SCH_SDCB_conBOOT_new.production.hex] Error 255
    make[1]: *** [.build-conf] Error 2
    make: *** [.build-impl] Error 2

    BUILD FAILED (exit value 2, total time: 11s)
     
    thank you all
    #4
    piffi
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2018/08/23 04:36:17
    • Location: 0
    • Status: offline
    Re: how to add bootloader on my project for dsPIC33 using EZBL library?? 2018/09/14 08:28:53 (permalink)
    0
    I managed to integrate the bootloader to my project. The problem was that the project configuration was not like with 'uart' configuration of the "ex_app_led_blink" example. Furthermore, my project had the .X extension and for this reason it did not compile. Now everything works but I would like to take another step forward. I would like the bootloader to free the uart2 and return to the application so that it can be used for other functions. Currently the uart2 continues to be managed by a background task that allows the loading of the firmware at any time when the app is running.
    I removed the comment from this piece of code on the "main.c" of ex_boot_uart but it did not work


                    // Optionally turn off all Bootloader ISRs and forward the
                    // interrupts to the Application so we become a passive classic
                    // bootloader.
                    // NOTE: You are giving up useful timing and communications APIs
                    // if you do this. Also, the automatic bootloader wakeup upon
                    // .bl2 file presentation won't work. To minimize flash, the
                    // App can just reuse the bootloader APIs as is, keeping the
                    // NOW Timer interrupt and communications ISRs active in the
                    // background (which have minimal run-time execution cost).
                    EZBL_RAMSet((void*)&IEC0, 0x00, (unsigned int)&IPC0 - (unsigned int)&IEC0);   // Clear every bit in all IECx Interrupt Enable registers
                    EZBL_ForwardAllIntToApp();                                                    // Forward all Interrupts to the Application
                    NOW_EndAllTasks();                                                            // Terminates the EZBL_BootloaderTask() from executing via background NOW ISR and when a NOW_32() or NOW_64() call is made which indirectly needs the timer ISR to execute and perform a carry propagation.


    How can I use uart2 in my application and stop the background bootloader task?
    thanks
    post edited by piffi - 2018/09/14 08:30:03
    #5
    piffi
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2018/08/23 04:36:17
    • Location: 0
    • Status: offline
    Re: how to add bootloader on my project for dsPIC33 using EZBL library?? 2018/09/17 00:17:36 (permalink)
    0
    up please!!
    #6
    HowardSchlunder
    MCU16 Applications
    • Total Posts : 744
    • Reward points : 0
    • Joined: 2007/06/14 16:26:19
    • Location: Chandler, AZ
    • Status: offline
    Re: how to add bootloader on my project for dsPIC33 using EZBL library?? 2018/09/19 15:58:35 (permalink)
    0
    Hello piffi,
     
    "Allow overlapped sections" tells the linker it is free to place two or more variables or code at the exact same address in RAM/flash. This option should never be enabled, except for the purpose of debugging an immediately preceding "Section '...' overlaps ..." linker abort message. Enabling this option suppresses this type of linker abort, allowing full .map and .elf files to be generated for analysis. However, immediately afterwards, it should be returned to its default unchecked state because your .hex output artifact will either fail spectacularly at run-time, or be subject to failing spectacularly at any future point in time when you rebuild the project.
     
    Removing this option definitely is a correct thing to do. Any error is possible if RAM variables are being overwritten by other RAM variables. Catastrophic run-time outcomes can happen with any project when overlapped sections are allowed, with or without dependency on EZBL components.
     
     
    I have read the thread regarding the multiple __reset definitions linker abort. However, I am no better able to understand what is happening because of it. As far as I can tell, such an error shouldn't happen. I cannot reproduce the problem at all. Also, because XC16 defines both of the __reset definitions that are in conflict, I can't discern if the underlying problem exists in EZBL, in XC16, in the way MPLAB X IDE is calling XC16, in your particular project settings, or on your particular PC due to conflicting GCC/GCC-derived/Cygwin tools in the system path or environment variables.
     
    The output window data you provided unfortunately does not help. I need to see the linking command line itself, not the output from the linker. For example, please share the immediately preceding line that looks like this:
    "C:\Program Files (x86)\Microchip\xc16\v1.35\bin\xc16-gcc.exe"  -o "C:\ezbl-v2.11\ex_boot_uart\ezbl_integration\ezbl_partial_link.elf"  build/uart/production/hardware_initializers/dspic33ep512gm710_explorer_16.o build/uart/production/hardware_initializers/pic24fj128ga010_explorer_16.o build/uart/production/hardware_initializers/dspic33ep512mu810_explorer_16.o build/uart/production/hardware_initializers/pic24fj256gb110_explorer_16.o build/uart/production/hardware_initializers/pic24fj256ga110_explorer_16.o build/uart/production/hardware_initializers/pic24fj64ga004_explorer_16.o build/uart/production/hardware_initializers/dspic33ep256gp506_explorer_16.o build/uart/production/hardware_initializers/dspic33fj256gp710a_explorer_16.o build/uart/production/hardware_initializers/pic24fj1024gb610_explorer_16.o build/uart/production/hardware_initializers/pic24fj256gb410_explorer_16.o build/uart/production/hardware_initializers/dspic33ep64gs502_digital_power_starter_kit.o build/uart/production/hardware_initializers/dspic33ev256gm106_can_lin_starter_kit.o build/uart/production/hardware_initializers/pic24fj64ga104_explorer_16.o build/uart/production/hardware_initializers/pic24fj128ga310_explorer_16.o build/uart/production/hardware_initializers/dspic33ch128mp508_explorer_16.o build/uart/production/hardware_initializers/pic24fj128gc010_analog_starter_kit.o build/uart/production/main.o build/uart/production/emulated_eeprom.o    ezbl_integration\ezbl_lib.a  -mcpu=24FJ1024GB610        -omf=elf -DEZBL_BOOT_PROJECT=uart -DXPRJ_uart=uart  -legacy-libc    -Wl,-DEZBL_PASS_1_LINK,--defsym=EZBL_BOOT_PROJECT=1,-DEZBL_BOOT_PROJECT=EZBL_BOOT_PROJECT,-D__24FJ1024GB610__=1,--local-stack,,--defsym=__MPLAB_BUILD=1,,--script="ezbl_integration\ezbl_build_standalone.gld",--stack=16,--no-check-sections,--data-init,--pack-data,--handles,--no-isr,--gc-sections,--fill-upper=0,--stackguard=16,--no-force-link,--smart-io,-Map="dist/uart/production/ex_boot_uart.production.map",--report-mem,--memorysummary,dist/uart/production/memoryfile.xml,--defsym=_BOOTID_HASH0=0xFE07C793,--defsym=_BOOTID_HASH1=0x57F877D8,--defsym=_BOOTID_HASH2=0xCD24AEBD,--defsym=_BOOTID_HASH3=0x4854ADED  1>NUL
     
     
    Back on the topic of UART2, the three lines you uncommented in the bootloader definitely will cease all background EZBL behaviors. However, the UART peripheral itself will still remain in the same state it was while the Bootloader was using it. This may or may not be compatible with the way your Application tries to reinitialize and use the UART.
     
    Notably, U2MODEbits.UARTEN will stay == '1' when the Application starts, which means hardware will block certain configuration changes from taking effect. For example, U2MODE<ABAUD> cannot be cleared by software whenever the UARTEN bit is set. I believe U2STAbits.UTXEN also becomes read-only.
     
    To put all UART2 SFRs and internal state (like the hardware TX and RX FIFO contents) in a freshly reset state, regardless of their prior state, you should execute:
        _U2MD = 1;
        _U2RXIP = 4;
        _U2TXIP = 4;
        _U2RXIF = 0;
        _U2TXIF = 0;
        _U2MD = 0;
    Execute this either in the Application before you try to initialize UART2 for your Application's use or in the Bootloader before launching the Application. The act of setting then clearing the PMDx<U2MD> bit will auto-reset all peripheral level SFRs and internal state, so you don't have to worry about existing U2MODE/U2STA/U2BRG values.
    #7
    piffi
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2018/08/23 04:36:17
    • Location: 0
    • Status: offline
    Re: how to add bootloader on my project for dsPIC33 using EZBL library?? 2018/09/20 02:57:49 (permalink)
    0

    hello HowardSchlunder,
    thank you very much for the punctual and precise answers.
    Comparing my project with the example "ex_app_led_blink" in addition to the "Allow overlapped sections" configuration there were also other different settings.
    Setting the configurations of the project in the same way as "ex_app_led_blink" the __reset problem no longer occurs.
    As for the UART2 you were right: in fact it remained configured by the bootloader and the application could not initialize it as I wanted. I solved by adding the following function to the application before configuring the uart: EZBL_COMBootIF = UART_Reset (2, FCY, 115200, 1);
    Can this work? or is it better to set the registers you told me?

    Another question. From the main of my application I have commented all the #pragma config as described in the exercise. What problems can this cause to my application? Can I define these configurations in other parts of the application?


    Thank
    #8
    HowardSchlunder
    MCU16 Applications
    • Total Posts : 744
    • Reward points : 0
    • Joined: 2007/06/14 16:26:19
    • Location: Chandler, AZ
    • Status: offline
    Re: how to add bootloader on my project for dsPIC33 using EZBL library?? 2018/09/25 23:30:31 (permalink)
    0
    Calling UART_Reset() in the Application will have the effect of reinitializing the UART SFRs for the specified baud rate/auto-baud setting, clearing any existing data recorded in the UART2_RxFifo and UART2_TxFifo structures, clearing _U2RXIF/_U2TXIF, setting _U2RXIE/_U2TXIE, restoring _U2RXIP = 0x2/_U2TXIP = 0x1, and (re)setting EZBL_STDOUT = &UART2_TxFifo/EZBL_STDIN = &UART2_RxFifo. The code for UART_Reset() is designed to be called at any time and the outcome should always be the same (i.e. prior state related to the UART should not affect the outcome), so indeed it is valid to call this in the Application.
     
    Having said this, the only thing you appear to be trying to update via this call is the baud-rate (U2BRG contents) and auto-baud enable (U2MODEbits.ABAUD = 0). You could instead call EZBL_FIFOSetBaud(&UART2_RxFifo, 115200); to achieve this. Doing so will have the potential benefit of retaining the prior contents, if any, in the software RX and TX FIFOs.
     
    I can't say if it is better to call UART_Reset(), EZBL_FIFOSetBaud(), or independently toggle _U2PMD and write to various SFRs, as all are valid and the most appropriate choice depends on what you are trying to accomplish/what you wish to avoid. None of these options are costly in terms of code size since UART_Reset()/EZBL_FIFOSetBaud() will already exist in the Bootloader's flash and get inherited by the Application for free.
     
    #pragma config statements tell the compiler to emit const values in flash at the FICD/FOSC/FOSCSEL/etc. config word addresses. As a global hardware function tied to specific addresses in program space, it does not matter if you define them in different files of the Application, in one of the files in the Bootloader, or scattered wherever - they will have the same hardware effect. There is one requirement, however:
    - You can't declare data for the same address more than once, even if the data is the same. These are true global objects that can exist in exactly zero or one place. The #pragma config statements obfuscate this some since they split the same 24-bit flash location into non-addressable, subatomic bitfields, but the result of assigning a value to any one or more bitfield in the same parent config word results in a physical declaration defining all 24-bits of the flash location.
     
    Working with EZBL and your target processor adds extra restrictions:
    - You can't declare data for a config word in one project and data for the immediately adjacent config word in the other project whenever the adjacent config word lies on the same 48-bit flash double word. For example, you will get a link time error building the Application project if you define the FICD config value (or any bitfields within it) in any of the Bootloader source files and then try to define the FWDT config value (or any bitfields within it) in any of the Application source files. This is due to FICD residing at flash address 0x02AFF0 and FWDT residing at 0x02AFF2, which shares the same 48-bit flash double word. This corresponds to the 48-bit minimum programmable unit size on the dsPIC33EP256GM310 which has to be defined all at the same time or not at all.
    - The Bootloader treats all addresses occupied by itself as read-only and will actively reject an attempt to change them during Application reprogramming. This implies any config words defined in your Bootloader or clobbered by the adjacency rule can never be changed in the field and all Applications will be stuck with whatever the Bootloader set. Only the config words absent from the Bootloader and not clobbered by adjacency can be defined and changed during Application updates.
    #9
    Jump to:
    © 2018 APG vNext Commercial Version 4.5