Bootloader PIC32MX550F256L：需要在Application中使用Bootloader的驱动代码

最简单的方法是在链接器脚本中有一个公共定义的区域，以及它所在的位置。然后，把文件分配给你想要共享的区域。这种方法的一个告诫是，如果地址改变，一个或两个都将中断。有时甚至编译器的更新也会破坏这种方法。因此，计划使用相同的编译器，可能是Orthy/USB框架的同一版本。



      以下为原文

    The simplest way is to have a common defined area in the linker script, and where it is located. Then, assign the files to that area that you want shared.
 
One caveat to this approach is that if an address changes, one or both will break. Sometimes even an update to the compiler will break this approach. So plan for using the same compiler, and probably the same version of Harmony/USB framework.

你好，拉里，我尝试过一些建议（使用C32），但是我对属性地址有问题，编译器没有把函数放在我预期的地址中。此外，我尝试使用属性部分，但问题是函数没有在完全相同的地址中结束。而且我知道地址属性应该这样做，因为我成功地使用C30编译器，并设法在应用程序和BooLoad之间共享一个库。Unesty是，你曾经尝试过我上面描述过的东西，并且使用XC32编译器得到了预期的结果吗？此外，当您将库分配给一个特定的内存段时，您是否为该库中的每个函数分配了一个属性，或者您找到了一种方法同时对整个文件进行处理？谢谢，问候，



      以下为原文

    Hello Larry,
 
I tried something that suggested before (using C32) but i had problem with the attributes address, the compiler didnt put the function in the address i expected. Also, i tried using the attribute section but the problem was that the function didnt end up in the exact same addresses.
 
And i know that the address attribute should do that because i did it succesfully using the C30 compiler, and manage to share a library between application and botloader.
 
So, my question is, have you ever tried something like i described above and got the expected result using XC32 compiler? also, when you assign the library to one specific memory section, did you do it assigning an attribute for every function in the library or you find a way to do it to the whole file at once?
 
Thanks,
 
Regards,

当我用XC32在Bootloader中做它时，我输入了一个跳转表，这样函数就不重要了，有一个固定的表地址。该表包含函数指针所在函数指针。然后我所要解决的就是呼叫表。



      以下为原文

    When I did it in my bootloader with XC32, I put in a jump table so that it didn't matter where the functions were, there was a fixed table address.  The table then contained function pointers to where the functions actually were.  Then all I had to fix was that call table.

嗨，ZDIENKJS，我认为你的想法会起作用，我需要你的另一个帮助，如何定义Bootloader和应用程序在链接器脚本中的共同区域，以及如何将驱动程序源文件分配给那个内存。



      以下为原文

    Hi zdenekjs, i think your idea will work, i need another help from you, how to define a common area for bootloader and application in linker script, and how to assign driver source files to that memory.

我上次在4年前做过这个项目，所以我可以给你我当时做的事情。我不再记得细节了，只是基本概念而已。从那时起，XC32已经改变了一些。基本上，您设置了一个满是函数指针的结构，并修复了它，以便应用程序能够读取它。然后，每当需要该函数时，只需查找表中的函数指针即可。如果需要的话，可以创建包装函数。两个项目之间的公共标题：这里是启动函数表的Bootloader中的C文件：这里是两个项目共同的链接器部分：



      以下为原文

    I last worked on that project over 4 years ago, so I can give you what I did then.  I don't remember the details anymore, just the basic concepts.  XC32 has changed some since then.
 
Basically, you set up a structure full of function pointers, and fix that so the app can read it.
 
Then whenever you need that function, you just look up the function pointer in the table.  You can create wrapper functions that if needed.
 
The common header between both projects:

/*
 * Bootloader Functions. These should be called from the same
 * RAM context as the bootloader runs in.
 * Otherwise, the functions may not operate properly
 */

/* Bootloader function table */
typedef struct bootldr_fntab_s {
    unsigned int table_rev; /* Revision of table */
    /*
     * Generic support functions
     */
    void (*DelayUs)(unsigned int cnt); // Delay Count*us
    void (*DelayMs)(unsigned int cnt); // Delay Count*ms
...

   /*
     * USB
     */
    void (*USBTask)(void);
    BYTE (*USBHostMSDSCSIMediaDetect)(void);
    BYTE (*USBHostMSDSCSIMediaReset)(void);
    
    void (*USBFuture1)(void);
    void (*USBFuture2)(void);
    void (*USBFuture3)(void);
    void (*USBFuture4)(void);

    /*
     * FatFS
     */
    FRESULT (*f_mount)(BYTE vol, FATFS* fs); /* Mount/Unmount a logical drive */
    FRESULT (*f_open)(FIL* fp, const TCHAR* path, BYTE mode); /* Open or create a file */
    FRESULT (*f_read)(FIL* fp, void* buff, UINT btr, UINT* br); /* Read data from a file */
    FRESULT (*f_close)(FIL* fp); /* Close an open file object */

   /*
     * USB
     */
    void (*USBTask)(void);
    BYTE (*USBHostMSDSCSIMediaDetect)(void);
    BYTE (*USBHostMSDSCSIMediaReset)(void);
    
    void (*USBFuture1)(void);
    void (*USBFuture2)(void);
    void (*USBFuture3)(void);
    void (*USBFuture4)(void);

    /*
     * FatFS
     */
    FRESULT (*f_mount)(BYTE vol, FATFS* fs); /* Mount/Unmount a logical drive */
    FRESULT (*f_open)(FIL* fp, const TCHAR* path, BYTE mode); /* Open or create a file */
    FRESULT (*f_read)(FIL* fp, void* buff, UINT btr, UINT* br); /* Read data from a file */
    FRESULT (*f_close)(FIL* fp); /* Close an open file object */

} bootldr_fn_tab_t;

 
Here's the C file in the bootloader that sets up the function table:
/* Bootloader function table */
const bootldr_fn_tab_t bootldr_fn_tab __attribute__ ((section (".boot_jmptab") )) = {
    .table_rev = 1, /* Revision of table */
    /*
     * Generic support functions
     */
    .DelayUs = DelayUs,
    .DelayMs = DelayMs,
..
    /*
     * USB
     */
    .USBTask = USBTask,
    .USBHostMSDSCSIMediaDetect = USBHostMSDSCSIMediaDetect,
    .USBHostMSDSCSIMediaReset = USBHostMSDSCSIMediaReset,
    
    .USBFuture1 = NULL,
    .USBFuture2 = NULL,
    .USBFuture3 = NULL,
    .USBFuture4 = NULL,

    /*
     * FatFS
     */
    .f_mount = f_mount,
    .f_open = f_open,
    .f_read = f_read,
    .f_close = f_close,
    
    .f_lseek = NULL,
    .f_opendir = NULL,
    .f_readdir = NULL,

    .fileio_future1 = NULL,
    .fileio_future2 = NULL,
    .fileio_future3 = NULL,
    .fileio_future4 = NULL,
}

 
 
Here's the linker portion common to both projects:
MEMORY
{
    /* All Bootloader C Files will be located here */
    btl_program_mem (rx) : ORIGIN = 0x9D000000, LENGTH = 0x9000
    /* Bootloader C Startup code */
    btl_boot_mem : ORIGIN = 0xBFC00000, LENGTH = 0x490
    /* Bootloader hard located data */
    btl_version_mem (r) : ORIGIN = 0xBFC00800, LENGTH = 16
    btl_build_mem (r) : ORIGIN = 0xBFC00810, LENGTH = 32
    btl_jmptab_mem (rx) : ORIGIN = 0xBFC00900, LENGTH = 256
    /* Bootloader Debug stub */
    btl_debug_stub_mem (rx) : ORIGIN = 0xBFC00F80, LENGTH = 128
    /* Bootloader Interrupt vector table */
    btl_exception_mem : ORIGIN = 0x9FC01000, LENGTH = 0x1000
    /* Debug exec */
    debug_exec_mem : ORIGIN = 0xBFC02000, LENGTH = 0xFF0





    /* Interrupt vector table */
    /* Reserve first 128 bytes for a CRC or hash - Not actually used in app exception memory */
    app_crc_hash_mem (r) : ORIGIN = 0x9D009000, LENGTH = 0x80
    app_exception_mem : ORIGIN = (0x9D009000 + 0x80), LENGTH = 0x1000 - 0x80
    app_version_mem (r) : ORIGIN = (0x9D009000 + 0x1000 + 0x10), LENGTH = 16
    app_build_mem (r) : ORIGIN = (0x9D009000 + 0x1000 + 0x20), LENGTH = 32
    /* C Startup code */
    app_boot_mem : ORIGIN = (0x9D009000 + 0x1000 + 0x30), LENGTH = 0x490
    /* All App C Files will be located here */
    app_program_mem (rx) : ORIGIN = (0x9D009000 + 0x1000 + 0x30+ 0x490), LENGTH = 0x80000 - (0x9000 + 0x1000 + 0x490 + 0x30)



    /* Dummy. Only used to prevent warnings from ld */
    kseg0_boot_mem : ORIGIN = 0x9FC00000, LENGTH = 0

    /* RAM allocation. Split separately so bootloader does not overwrite
     * our persistent area. Make extra big, the application can always
     * define the persistent area it actually wants. We don't need it
     * for the bootloader anyway */
    /* kseg1_data_mem (w!x) : ORIGIN = 0xA0000000, LENGTH = 128K */
    dbg_data_mem (w!x) : ORIGIN = 0xA0000000, LENGTH = 0x200
    btl_data_mem (w!x) : ORIGIN = 0xA0000200, LENGTH = 48K - 0x200
    app_data_mem (w!x) : ORIGIN = 0xA0000200, LENGTH = 128K - 8K - 0x200
    persist_data_mem (w!x) : ORIGIN = 0xA0000000 + 128K - 8K, LENGTH = 8K - 0x30
    btl_exit_persist_mem (w!x) : ORIGIN = 0xA0000000 + 128K - 0x30, LENGTH = 0x10
    btl_entry_persist_mem (w!x) : ORIGIN = 0xA0000000 + 128K - 0x20, LENGTH = 0x20
}

这种方法只适用于某种类型的函数，即函数不具有静态内存分配。例如，如果在Bootloader中有这样的函数：当您通过函数指针从调用表中调用应用程序时，应用程序代码显然对缓冲区分配一无所知，并且执行将失败。



      以下为原文

   
This kind of method would only work with certain type of functions, namely functions don't have static memory allocation. For example, if you have a function in the bootloader that looks like this:

void Foo(void)
{
     static int buffer[10]; // buffer is allocated by the bootloader
     ...
}

When you call it from application via a function pointer off a call table, then obviously the application code knows nothing about the buffer allocation and the execution will fail.

嗨，ZDIENKJS，谢谢分享你的代码，我可以把硬编码区域放在程序快闪存储器中。



      以下为原文

    Hi zdenekjs, thanks for sharing your code, can i place hard coded region in program flash memory.

嗨，ZDIENKJS，我需要一些建议来创建链接器脚本中的一个新的部分，我已经尝试过你在上面的评论中建议的方式，但是有些东西不起作用，我看不到在MMAP文件中创建的一个部分。



      以下为原文

    Hi zdenekjs, i need some suggestions for creating a new section in linker script, i have tried the way you suggested in above comment, but something is not working, i can't see a section created in map file.

看起来有更多的个人链接器脚本。在应用程序链接器脚本：



      以下为原文

    Looks like there's more in the individual linker script.
 
In the app linker script:


INCLUDE ../Common/linker_script/common_mx5_6_7.ld

/* Define bootloader version variables */
PROVIDE(bootloader_version = ORIGIN(btl_version_mem));
PROVIDE(bootloader_build_string = ORIGIN(btl_build_mem));
PROVIDE(bootloader_jmptab = ORIGIN(btl_jmptab_mem));


SECTIONS
{
    /* Persistent data - Use the new C 'persistent' attribute instead. */
  .persist :
  {
    _persist_begin = .;
    *(.persist .persist.*)
    *(.pbss .pbss.*)
    . = ALIGN(4) ;
    _persist_end = .;
  } >persist_data_mem
}

几个月前，我为一个客户做了一些事情。它归结为在链接器脚本中创建一个新的区段：然后，在部分区域中，我定义了哪些文件应该进入共享内存区域。



      以下为原文

    I did something a few months ago for a customer. What it boiled down to was creating a new section in the linker script:
MEMORY
{
  kseg0_program_mem (rx) : ORIGIN = (0x9D000000 + 0x13000), LENGTH = (0x80000 - 0x13000) /* All C Files will be located here */
  shared_lib_mem (rx) : ORIGIN = 0x9D00C000, LENGTH = 0x4000 /* Shared between bootloader and app */
  kseg0_boot_mem : ORIGIN = 0x9D000000 + 0x13000, LENGTH = 0x0 /* This memory region is dummy */
  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
  debug_exec_mem : ORIGIN = 0xBFC02000, LENGTH = 0xFF0
  configsfrs : ORIGIN = 0xBFC02FF0, LENGTH = 0x10
}
Then, in the SECTIONS area, I defined which files should go into that shared memory region.

.shared_text ORIGIN(shared_lib_mem):
{
  KEEP(*bsp.o(.rodata))
  KEEP(*bsp.o(.text.*))
} >shared_lib_mem

谢谢拉里，这很有帮助。



      以下为原文

    Thank you Larry that was helpful