Harmony V2.05 Bootloader链接器脚本不起作用

有人有建议，或者我看的是1388附注的指导？2年仍然是问题。



      以下为原文

    Anyone have an suggestions, or am I looking at the AN1388 appnote for guidance?
2 years and still issues.

什么类型的问题，崩溃中断启用，或什么？



      以下为原文

    What types of issues, crash on interrupt enables, or what?

中断发生时，我会收到例外情况。但是调试器列表然后在正常代码中。如果禁用了和声脚本，则使用默认链接器脚本并构建良好。我现在正在使用它继续编码。我想我会复制默认值并改变RAM大小。我认为这很容易。我更关心应用程序链接器脚本。



      以下为原文

    I get exceptions when the interrupts happen. But the debugger list then in normal code. If I disable the Harmony script, it then uses the default linker script and builds fine. I am using that for now to continue to code. I guess I will copy the default and change the ram size.
I assume that will be easy.
I am more concerned about the application linker script.

哪个处理器？我使用MZ Bootloader和应用脚本在DA上没有问题，除非应用程序使用Fieltos时描述了什么。它的修复是提供的（{eBaseAddio= 0x9D04000）；而不是1000。我在某个论坛上发现了这一点，但我很想知道为什么。



      以下为原文

    Which processor? 
 
I am using the MZ bootloader and application scripts without issues on a DA, excepting that the application does what you describe when using FREERtos.  The fix for that is PROVIDE(_ebase_address = 0x9D004000); instead of 1000.  I found that on a forum somewhere and it works, but I'd really like to know why.

这是我的问题，MZ和MX微芯片似乎都不提供如何编辑链接器脚本的信息。由于IVT更复杂，MZ是可变长度的。MX应该像PIC24一样固定。MZ你需要留出足够的空间（没有细节）。当我仍然在引导加载程序上时，我还没有尝试应用脚本。



      以下为原文

    That is my issue with both MZ and MX Micro chip does not appear to provide information on how to edit the Linker scripts.  The MZ in more complicated since the IVT is variable length.  The MX is supposed to be fixed like the PIC24.  The MZ you need to leave enough room for it (no details).  As I sais I am still on the Bootloader, I have not tried the application script yet.

这些设备的Bootloader链接器脚本和默认链接器脚本之间的主要区别在于，它将IVT从闪存（默认）的末端移到开机（Bootloader）。由于这些设备只有3K的启动闪存，所以没有足够的空间来放置IVT，因为在MX设备中有12K的启动闪存。我前面没有硬件，但是在通过MHC生成USB设备引导加载程序之后，模拟器似乎就可以了。模拟器对你有用吗？



      以下为原文

    The chief difference between the bootloader linker script and default linker script for these devices is that it moves the IVT from the end of Flash memory (default) to the beginning (bootloader). Since these devices have only 3K of boot flash, there isn't enough room to put the IVT there, as there is in the MX devices with 12K of boot flash.
 
I don't have hardware in front of me, but after generating a USB device bootloader through MHC, the simulator seems to be okay with it. Does the simulator work for you?

中断是在引导加载程序中发生的，还是在应用程序中发生的？你的中断向量在哪里？在引导加载程序内存或应用程序内存中？（看看地图文件）我只记得编辑链接器脚本是一件痛苦的事情。当使用精确的和声模型时，罐头链接器脚本只能起作用。一旦你足够坚挺地实现你自己的引导加载程序，你就失去了。主要原因是链接器脚本是纯黑客！我还在1.09岁，我知道为什么。Nick



      以下为原文

    Do the interrupts happen while in the boot loader or while in the application?
Where are your interrupt vectors? In boot loader memory or in application memory? (look at the map file)
 
I just remember that it was a pain to edit the linker script to work properly. The canned linker scripts only do work, when you use exactly Harmonies model. As soon as you are nuts enough to implement you own boot loader, you lost.
Main cause is, that the linker script is a pure hack!
I'm still on 1.09 and I know why.
 
Nick

我用XC32修改了脚本。我使用了AppNotes中的注释，并与Hyn 2.05脚本进行了比较。它们似乎基本相同。我必须增加更多的空间，因为我的引导加载程序不适合它提供的8K。所以我添加了一个页面。（对我来说似乎有点大，肯定比芯片设计者认为Bootloader更大）我确实注意到IVT的移动到了开始。我不知道交易的开始或结束。在我改变的参数中，和声脚本相似。但是脚本中的许多后面的项目是不同的。我不知道它们是否重要。但我必须假设他们这样做，至少对于我的照片来说。我很少使用模拟器。我直接去硅。我假设我会对应用程序脚本有同样的问题。



      以下为原文

    I have it working with a modified script from XC32. I used the notes from the appnotes and a comparison to the harmony 2.05 script.
They appear to be mostly the same. I had to add more space since my boot loader did not fit it to the 8k provided. So I added a page. ( seems a little big to me, certainly bigger than the chip designer thought a bootloader would be)
I did notice the moving of the ivt to the beginning. I do not know the trade offs for beginning or end.
The harmony script appears similar in the parameters I changed. But many of the later items in the script are different. I do not know if they matter. But I would have to assume they do, at least for my pic. I rarely use the simulator. I go right to silicon.

I assume I will have the same issue with application script.

我还使用提供的链接器文件和协调V2.03B的Bootloader得到异常和崩溃，但是使用PIC32 MK1024GPE100。协调器V2.03B为该设备添加的链接器文件是为另一设备制造的，并且配置位的正确放置丢失且不正确。链接器文件中还有一些其他问题，所以我结合了工作标准链接器文件和提供的BooDoubuleLink文件。我已经附加了文件，它们当然不是完美的，但是为我工作，也许有人发现它们有用。请注意，它们是针对PIC32 MK1024GPE100而不是MX设备，并且我将它们重命名为*.txt。
BTLYMX.TXT（56.65 KB）-下载119次



      以下为原文

    I also got exceptions and crashes using the bootloader with the provided linker files and Harmony v2.03b, but with a PIC32MK1024GPE100. The linker files which Harmony v2.03b adds for this device are made for another device and the correct placement of the configuration bits is missing and not correct. There were also some other issues in the linker files so I combined the working standard linker files and the provided bootloader linker files. I have attached the files, they are certainly not perfect, but work for me, maybe someone finds them useful. Note that they are for a PIC32MK1024GPE100 and not a MX device and I renamed them to *.txt.
   Attachment(s)

app_mx.txt (56.31 KB) - downloaded 122 times
btl_mx.txt (56.65 KB) - downloaded 119 times

我有一些工作形状的引导装入链接器脚本。3K引导块有点不同于12K的引导块。我对应用程序脚本有一些问题。这个。重置部分似乎没有添加。附件是脚本，我认为是内存映射。和谐移动eBASE到Buton，XC32将它放在内存的顶部。这两种方法都有好处吗？Excel＝MAPP32 MX530F128H.LD＝XC32 V1.44 Script TopAppMx.LD＝Hyror应用程序Script PtBL*MX.LD＝和谐Bootloader Script Pt32 MX530F128H APP.LD＝基于XC32 ONE的我的应用程序脚本.p32 MX530F128H-BTL.LD＝基于XC32的Bootloader脚本。
P32 MX530F128H.LD.TXT（32 KB）-下载了91次P32 MX530F128HAPAP.L.TXT（32.67 KB）-下载了113次P32 MX530F128H-BTL.L.TXT（32.24 KB）-下载了101次



      以下为原文

    I have the Bootload Linker script in some working shape. The 3K boot block are a little different that the 12K ones.
I am having some issue with the application script.  the . Reset section does not appear to be added.
Attached is both script and what I think is the memory map.
 
harmony moves ebase to the Botton, XC32 has it at the top of memory.  is there a benefit to either method?
 
excel = map
p32MX530F128H.ld = XC32 V1.44 script
app_mx.ld = Harmony app  script
btl_mx.ld = Harmony  bootloaderscript
p32MX530F128H-app.ld = my app script based on the XC32 one.
p32MX530F128H-btl.ld  = my bootloader script based on the XC32 one.
 
 
   Attachment(s)

Memory Map.xls (36.00 KB) - downloaded 65 times
p32MX530F128H.ld.txt (32.00 KB) - downloaded 91 times
p32MX530F128H-app.ld.txt (32.67 KB) - downloaded 113 times
p32MX530F128H-btl.ld.txt (32.24 KB) - downloaded 101 times

CONTIONBFC02FF0:{Cube（*..FaskBFC0BF0）} & CONTIXBFC02FF4: {Cube（*（.CONTIOBBFC000 BF4）} & gt2.2.CONFIXBFC02FF8:{FIX（*.CONFIXBFC0BF8）} & GTIG1.CONTIONBFC02FFC:{FECK（*.CONFIXBFC900BFC）} & Gt；这是由和声脚本编写的。假设在XC32中匹配？
BTLYMX.L.TXT（13.88 KB）-下载102次



      以下为原文

    This is from the Harmony script.
SECTIONS
{
   .config_BFC02FF0 : {
   KEEP(*(.config_BFC00BF0))
   } > config3
   .config_BFC02FF4 : {
   KEEP(*(.config_BFC00BF4))
   } > config2
   .config_BFC02FF8 : {
   KEEP(*(.config_BFC00BF8))
   } > config1
   .config_BFC02FFC : {
   KEEP(*(.config_BFC00BFC))
   } > config0
}
 
are these suppose to match like in the XC32 one?
   Attachment(s)

app_mx.ld.txt (28.83 KB) - downloaded 98 times
btl_mx.ld.txt (13.88 KB) - downloaded 102 times

这似乎更接近工作：SyReStEdAdDR=（0x9DMAM+0x3000）；而不是（0xBDMAM+0x3000）；我猜不同的段不同的地址。



      以下为原文

    This appears to be closer to working:
_RESET_ADDR                    = (0x9D000000 + 0x3000);  as opposed to  (0xBD000000 + 0x3000); 
I guess different segment different address.

从您在POST 11中发布的链接器脚本开始。P32 MX530F128H BTL。LD。TXT：1。既然你有900万兆的EBASE，也将Exchange Type MIM改为9D00万。这是向量表的所在地。2。调整Sk00SuffyToMym到9D01000，以适应这种变化。现在，您的整个应用程序有效地启动于9D04000。在MPLABX中进行这些更改：Pp32 Mx795F512LyApp.LDCube两个构建配置，一个用于调试，另一个用于发布。转到Projts属性-gt；xc32 LD，在“附加选项”字段中，为调试添加“-dyReSeTeLoC＝0xbfc000”和“-dlReSeTeLoC＝0xBD04000”以供释放。现在，您可以为两个构建使用相同的链接器脚本，调试和发布之间唯一的区别是放置重置和启动代码的位置。



      以下为原文

    Start with the linker scripts you posted in Post#11.
p32MX530F128H-btl.ld.txt:
1. Since you have ebase at 9D00_0000, change exception_mem to 9D00_0000 as well. This is where the vector table goes.
2. Adjust kseg0_program_mem to 9D00_1000 to accommodate this change.

PROVIDE(_vector_spacing = 0x0001);
PROVIDE(_ebase_address = 0x9D000000); /* Move IVT (was 0x9D01F000) - NSK */
...
kseg0_program_mem (rx) : ORIGIN = 0x9D001000, LENGTH = 0x3000 /* Change length to 12K - NSK, All C Files will be located here */
exception_mem : ORIGIN = 0x9D000000, LENGTH = 0x1000

 
Now your entire application effectively starts at 9D00_4000. Make these changes in p32MX795F512L_app.ld

PROVIDE(_vector_spacing = 0x0001);
PROVIDE(_ebase_address = 0x9D005000); /* ebase */
 
_RESET_ADDR  = _RESET_LOC; /* application entry point */
 
kseg0_program_mem (rx) : ORIGIN = 0x9D006000, LENGTH = (0x80000 - 0x6000) /* Main app code */
exception_mem : ORIGIN = 0x9D005000, LENGTH = 0x1000 /* vector table */
kseg1_boot_mem : ORIGIN = _RESET_LOC, LENGTH = 0x1000 /* reset + startup code */

 
Create two build configurations in MPLABX, one for debug and one for release. Go to Project Properties -> xc32-ld, in the "Additional options" field, add "-D_RESET_LOC=0xBFC00000" for debug and "-D_RESET_LOC=0xBD004000" for release. Now you can use the same linker script for both builds, and the only difference between the debug and release is where you put the reset and startup code.
 

谢谢，我会在星期一完成这个。MIPS CPU对于小型程序来说似乎是浪费的。我不知道为什么他们认为3K引导块是有用的。我的最后一个链接脚本工作。我看到地址必须匹配的空间或坏事发生。谢谢你的输入。γ



      以下为原文

    Thank you I will go through this on Monday.
The mips cpu seems wasteful for small programs. I am not sure why they thought a 3K boot block was useful.
My last linker script did work. I see the address must match the space or bad things happen.
Thanks for the input.

3K引导块没有命名，因为它是用于引导装载程序（但它可以足够小），但因为它在那里，芯片启动。它还包含调试执行程序，通常包含一个异常向量块和应用程序的启动代码（没有引导加载程序）。



      以下为原文

    The 3K boot block is not named as it is because it is to be used for a bootloader (but it can if small enough) but because it is there the chip boots up. It also contains the debug executive and normally one exception vector block and the startup code for the application (with no bootloader).
 
/Ruben

谢谢。Microchip有一个长期的习惯，使得引导加载程序的可锁定区域太小。但是“BooBug”不仅仅是针对PIC32 MX上的引导加载程序。向未来读者致意。我的Bootloader工作，所以这些脚本是实用的。更新：不，它们不是，我会重新发布正确的脚本。



      以下为原文

    Thanks. Microchip has a long term habit of making the lockable area for the boot loader to be too small. But “bootblock” is not just for bootloaders on a pic32mx.

FYI to future readers. My bootloader worked so these scripts are functional.
Update: No they are not, I will re-post the correct ones.

这些是我希望的PIC32 MX530的引导加载程序脚本，它们与XC32 V1.44一起工作，和声V2.05No.APP脚本将独立运行。这意味着引导加载程序或主机需要屏蔽重复的地址。这可能不适合所有需要（文件的校验和将不匹配PIC），如果有人看到并发布回他们。链接器脚本是很多工作。P32 MX530F128H.LD =从XC32 V 1.44 p32 MX530F128H APP.LD =默认的主应用程序p32 MX530F128H-BTL.LD=对于BooDouthLoad Maul.Mx.xLs=我认为事情应该是，或者可以是
P32 MX530F128HAPAP.L.TXT（32.90 KB）-下载88次P32 MX530F128H-BTL.L.TXT（32.30 KB）-下载75次内存MAP.xLS（36 KB）-下载49次



      以下为原文

    These are my hopefully Final Boot loader scripts for the PIC32MX530
They are working with XC32 V1.44 and Harmony V2.05
Note the App script will run standalone.  That means the Bootloader or Host needs to mask out the duplicate addresses.  This may not suit all needs (the Checksum of the File will not match the PIC)
 
If anyone sees and issue Post them back.  Linker scripts are a lot of work.
 
p32MX530F128H.ld       = The default from XC32 V 1.44
p32MX530F128H-app.ld = For the Main Application
p32MX530F128H-btl.ld  = For the Bootloader
Memory Map.xls            = where I think things should be, or can be
   Attachment(s)

p32MX530F128H.ld.txt (32.00 KB) - downloaded 55 times
p32MX530F128H-app.ld.txt (32.90 KB) - downloaded 88 times
p32MX530F128H-btl.ld.txt (32.30 KB) - downloaded 75 times
Memory Map.xls (36.00 KB) - downloaded 49 times

我将在Bootloader和应用程序链接器脚本中创建/分配适当大小的FrkSe0xBootmim，然后从KSK1Y-BootSmim到KSt00BootthMeMe的MOVE。ReSET启动。一旦这样做，引导程序和应用程序都只共享重置向量。如果没有引导加载程序，则重置向量将指向应用程序的启动代码。如果有引导加载程序，那么重置向量将指向引导加载程序的启动代码。去掉那个滑稽的硬编码跳转指令。在你的Bootloader链接器脚本中，你认为你想要9D3000。



      以下为原文

    I would create/allocate proper sizes for kseg0_boot_mem in both the bootloader and application linker script, then move .reset.startup out of kseg1_boot_mem to kseg0_boot_mem. Once you do that, both the bootloader and the application share only the reset vector. If there is no bootloader, the reset vector will point to the applicaiton's startup code. If there is bootloader, then the reset vector will point to bootloader's start-up code. Get rid of that funny looking hard-coded jump instruction.
 
Also, in  your bootloader linker script, you have

exception_mem               : ORIGIN = 0x9D001F00, LENGTH = 0x1000

I think you want 9D003000.

我想有不止一种方法可以做到这一点。我对你先前的建议很有兴趣，不想冒险进入条件汇编。由于优先级的原因，这个引导程序退出后，我有压力完成它。此时，如果它没有错（特别是引导加载程序），我必须保留它。我的0x3000字节引导程序不例外吗？我非常感谢你的帮助。在这个问题上，我觉得很难。



      以下为原文

    I guess there is more than one way to do this.
Iooked at you earlier suggestion and did not want to venture into conditional compiles. After dropping this bootloader due to priorities, I was under pressure to finish it.
At this point if it is not wrong (Especially the boot loader) I have to keep it.
Doesn’t exception_mem have to be written my 0x3000 byte bootloader?

And I really appreciate your help. On this subject I find quite difficult.