完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
你好!所以我有一个外部EEPROM,512k通过I2C连接到我的PIC32MX。现在,我想建立一个引导加载程序,它读取EEPROM并闪烁PIC的程序内存。简单!在和谐1.081中,您可以选择I2C作为协议,但这根本不起作用。不包括为I2C生成的,包含在Bootloader中。C完全错误。没有例子,没有描述和谐PDF。但是Bootloader库是生产的!如果我在玩了半天之后得到一个版本,它就不适合12 K了,这太荒谬了!谢谢你的微芯片!看来我必须完全写我自己的…Nick
以上来自于百度翻译 以下为原文 Hi! So I do have an external EEPROM with 512k connected over I2C to my PIC32MX. And now, I'd like to build a bootloader that does read the EEPROM and flashes the PIC's program memory. Easy! In hARMony 1.08.1, you can select I2C as the protocol. But that simply doesn't work at all. No includes generated for I2C, includes in bootloader.c completely wrong. No example, no description in the Harmony PDF. But the bootloader library is production! And IF I get a version after fiddling half a day, it doesn't fit into the 12 k. That is ridiculous! Thank you Microchip! Seems I do have to write it completely by my own ... Nick |
|
相关推荐
8个回答
|
|
不完全。您可以将代码从Bootloader .c拉到应用程序的任务中。这给了你基础和闪光功能。尝试从静态I2C开始,它允许你编辑能力。你可以保持它小。数据流模块是将I2C连接到Bootloader的地方。但你可能需要把它折叠起来,使它变小。注意有一个PIC16F1 I2C引导加载器。你可能会从中使用这个应用程序。
以上来自于百度翻译 以下为原文 Not completely. You can pull the code from bootloader.c. In to your app tasks. That gives you the base and the flash functions. Try to start with the static i2c it allows you edit ability. You may be able to keep it small. The data stream module is where you would connect the i2c to the bootloader. But you may need to collapse it to make it smaller. Note there is a pic16f1 i2c boot-loader. You might be about to use the app from that. |
|
|
|
您所要求的不是引导加载程序,而是文件复制实用程序。
以上来自于百度翻译 以下为原文 What you are asking for is not a bootloader, it's a file copy utility. |
|
|
|
Bootloader的I2C代码旨在将PIC32视为从属。但是没有很好的方法来演示它,因为主程序没有完全按照我们想要的方式设置。我建议将引导加载程序作为起点。查看DATASTRAM文件夹,以确定如何从所需的源获取数据,并相应地修改数据。
以上来自于百度翻译 以下为原文 The I2C code for the bootloader was intended to treat the PIC32 as a slave. But there wasn't a good way to give a demonstration of it, since the master wasn't completely set up the way we wanted. I'd suggest looking at the bootloader as a starting point. Look at the datastream folder as the way to identify how to get the data from the source you want, and modify it accordingly. |
|
|
|
MehSo是SDCard或USB Stick。它比较简单,因为它不需要解析十六进制文件。但是我不希望和声能够立即覆盖这一个。
以上来自于百度翻译 以下为原文 Meh So is an SDCard or USB Stick. It is simpler since it does not need to parse Hex files. But I would not expect harmony to cover this one, out of the box. |
|
|
|
好的,我将详细解释:我在SS卡上下载了一个二进制文件到SD卡上。我将文件闪存到外部EEPROM中。工作(我验证了我写的内容)。闪存有点奇怪,因为我在I2C总线上有一个RTCC,还有EEPROM。EEPROM有一个地址转换器(LTC4316),在后面,实际上有两个AT24CM02。因此,我不希望在程序内存中有任何引导加载程序相关的代码。所有引导加载程序代码必须驻留在引导闪存中。对于应用程序,我使用的是和声1.0602。因为我不打算共享代码,所以我看不出有什么问题。对于引导加载程序,我使用的是和谐1.0802(或者01?)就像,我唯一的问题就是把这两个程序都写到这两个内存区域。像往常一样,我闪存应用程序(没有调试代码)。我想,该代码的起始地址是0x990000(PIC32 MX795)。也许这是我的第一个错误?然后,我做(至少我尝试)Flash只是BooLoad(它是一个不同的项目)。我确信,正在执行装船程序,但是我不能从代码fptr=(void(*)(void))BOOTLOADER_RESET_ADDRESS;fptr()中启动应用程序本身,地址是0x9D0000000,我确实有这样的印象,即我的REAL ICE也在覆盖应用程序代码,尽管我没有检查所有flags在项目属性中,可以覆盖0x9D000000到0x9d07FFFF的范围。啊,我从我刚做的项目(设置了引导加载器选项)中选择了一个链接器脚本来获得链接器脚本。感谢您的任何输入!尼克
以上来自于百度翻译 以下为原文 OK; I'll explain in detail: I download a binary file over SSL onto my SD-card. Works. I flash the file into the external EEPROM. Works (and I verified what I have written). There is a bit of oddity with the flash, as I do have an RTCC on the I2C bus, together with the EEPROM. The EEPROM has an address-translator (LTC4316) and behind that, there are actually two AT24CM02. Works. So what I want: I do not want to have any boot-loader related code to be in the program memory. All boot loader code has to reside in boot flash. For the application, I'm using Harmony 1.06.02. As I do not intend to share code, I see no problem with that. For the boot loader, I'm using Harmony 1.08.02 (or 01?). It lloks like, my only problem is to write both programs into both memory regions. As usual, I do flash the application (no debug code). I suppose, the start address of that code is at 0x9D000000 (PIC32MX795). Maybe that is my first error? Then, I do (at least I try) flash JUST the boatloader (it is a different project). I am sure, the boatloader is being executed, but I just can't start the app itself from within that code fptr = (void (*)(void))BOOTLOADER_RESET_ADDRESS; fptr(); with the address being 0x9D000000 I do have the impression, that my REAL ICE is overwriting the app-code too, despite me unchecking all flags in project properties that would overwrite the range of 0x9D000000 to 0x9d07FFFF. Ah, I picked a linker script from a project I just made (with bootloader option set) to get the linker script. It is: /* Default linker script, for normal executables */ OUTPUT_FORMAT("elf32-tradlittlemips") OUTPUT_ARCH(pic32mx) ENTRY(_reset) /* * Provide for a minimum stack and heap size * - _min_stack_size - represents the minimum space that must be made * available for the stack. Can be overridden from * the command line using the linker's --defsym option. * - _min_heap_size - represents the minimum space that must be made * available for the heap. Can be overridden from * the command line using the linker's --defsym option. */ EXTERN (_min_stack_size _min_heap_size) /************************************************************************* * Processor-specific object file. Contains SFR definitions. *************************************************************************/ INPUT("processor.o") /************************************************************************* * Processor-specific peripheral libraries are optional *************************************************************************/ OPTIONAL("libmchp_peripheral.a") /************************************************************************* * For interrupt vector handling *************************************************************************/ PROVIDE(_vector_spacing = 0x00000001); _ebase_address = 0x9FC00300; /************************************************************************* * Memory Address Equates * _RESET_ADDR -- Reset Vector * _BEV_EXCPT_ADDR -- Boot exception Vector * _DBG_EXCPT_ADDR -- In-circuit Debugging Exception Vector * _DBG_CODE_ADDR -- In-circuit Debug Executive address * _DBG_CODE_SIZE -- In-circuit Debug Executive size * _GEN_EXCPT_ADDR -- General Exception Vector *************************************************************************/ _RESET_ADDR = 0xBFC00000; _BEV_EXCPT_ADDR = (0xBFC00000 + 0x380); _DBG_EXCPT_ADDR = (0xBFC00000 + 0x480); _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 = 0x9FC00500, LENGTH = 0x2AF0 /* All C Files will be located here */ kseg0_boot_mem : ORIGIN = 0x9FC00020, LENGTH = 0x0 /* This memory region is dummy */ exception_mem : ORIGIN = 0x9FC01000, LENGTH = 0x1000 /* Interrupt vector table */ config3 : ORIGIN = 0xBFC02FF0, LENGTH = 0x4 config2 : ORIGIN = 0xBFC02FF4, LENGTH = 0x4 config1 : ORIGIN = 0xBFC02FF8, LENGTH = 0x4 config0 : ORIGIN = 0xBFC02FFC, LENGTH = 0x4 kseg1_boot_mem : ORIGIN = 0xBFC00000, LENGTH = 0x300 /* C Startup code */ 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 } /************************************************************************* * Configuration-word sections *************************************************************************/ 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 } PROVIDE(_DBG_CODE_ADDR = 0xBFC02000) ; PROVIDE(_DBG_CODE_SIZE = 0xFF0) ; SECTIONS { /* Boot Sections */ .reset _RESET_ADDR : { KEEP(*(.reset)) KEEP(*(.reset.startup)) } > kseg1_boot_mem .bev_excpt _BEV_EXCPT_ADDR : { KEEP(*(.bev_handler)) } > kseg1_boot_mem .dbg_excpt _DBG_EXCPT_ADDR (NOLOAD) : { . += (DEFINED (_DEBUGGER) ? 0x8 : 0x0); } > kseg1_boot_mem .dbg_code _DBG_CODE_ADDR (NOLOAD) : { . += (DEFINED (_DEBUGGER) ? _DBG_CODE_SIZE : 0x0); } > debug_exec_mem .app_excpt _GEN_EXCPT_ADDR : { KEEP(*(.gen_handler)) } > exception_mem /* Starting with C32 v2.00, the startup code is in the .reset.startup section. * Keep this here for backwards compatibility. */ .startup ORIGIN(kseg0_boot_mem) : { KEEP(*(.startup)) } > kseg0_boot_mem /* Code Sections - Note that input sections *(.text) and *(.text.*) ** are not mapped here. Starting in C32 v2.00, the best-fit allocator ** locates them, so that .text may flow around absolute sections ** as needed. */ .text : { *(.stub .gnu.linkonce.t.*) KEEP (*(.text.*personality*)) *(.mips16.fn.*) *(.mips16.call.*) *(.gnu.warning) . = ALIGN(4) ; } >kseg0_program_mem /* Global-namespace object initialization */ .init : { KEEP (*crti.o(.init)) KEEP (*crtbegin.o(.init)) KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o *crtn.o ).init)) KEEP (*crtend.o(.init)) KEEP (*crtn.o(.init)) . = ALIGN(4) ; } >kseg0_program_mem .fini : { KEEP (*(.fini)) . = ALIGN(4) ; } >kseg0_program_mem .preinit_array : { PROVIDE_HIDDEN (__preinit_array_start = .); KEEP (*(.preinit_array)) PROVIDE_HIDDEN (__preinit_array_end = .); . = ALIGN(4) ; } >kseg0_program_mem .init_array : { PROVIDE_HIDDEN (__init_array_start = .); KEEP (*(SORT(.init_array.*))) KEEP (*(.init_array)) PROVIDE_HIDDEN (__init_array_end = .); . = ALIGN(4) ; } >kseg0_program_mem .fini_array : { PROVIDE_HIDDEN (__fini_array_start = .); KEEP (*(SORT(.fini_array.*))) KEEP (*(.fini_array)) PROVIDE_HIDDEN (__fini_array_end = .); . = ALIGN(4) ; } >kseg0_program_mem .ctors : { /* XC32 uses crtbegin.o to find the start of the constructors, so we make sure it is first. Because this is a wildcard, it doesn't matter if the user does not actually link against crtbegin.o; the linker won't look for a file to match a wildcard. The wildcard also means that it doesn't matter which directory crtbegin.o is in. */ KEEP (*crtbegin.o(.ctors)) KEEP (*crtbegin?.o(.ctors)) /* We don't want to include the .ctor section from the crtend.o file until after the sorted ctors. The .ctor section from the crtend file contains the end of ctors marker and it must be last */ KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors)) KEEP (*(SORT(.ctors.*))) KEEP (*(.ctors)) . = ALIGN(4) ; } >kseg0_program_mem .dtors : { KEEP (*crtbegin.o(.dtors)) KEEP (*crtbegin?.o(.dtors)) KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors)) KEEP (*(SORT(.dtors.*))) KEEP (*(.dtors)) . = ALIGN(4) ; } >kseg0_program_mem /* Read-only sections */ .rodata : { *( .gnu.linkonce.r.*) *(.rodata1) . = ALIGN(4) ; } >kseg0_program_mem /* * Small initialized constant global and static data can be placed in the * .sdata2 section. This is different from .sdata, which contains small * initialized non-constant global and static data. */ .sdata2 ALIGN(4) : { *(.sdata2 .sdata2.* .gnu.linkonce.s2.*) . = ALIGN(4) ; } >kseg0_program_mem /* * Uninitialized constant global and static data (i.e., variables which will * always be zero). Again, this is different from .***ss, which contains * small non-initialized, non-constant global and static data. */ .***ss2 ALIGN(4) : { *(.***ss2 .***ss2.* .gnu.linkonce.***2.*) . = ALIGN(4) ; } >kseg0_program_mem .eh_frame_hdr : { *(.eh_frame_hdr) } >kseg0_program_mem . = ALIGN(4) ; .eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) } >kseg0_program_mem . = ALIGN(4) ; .gcc_except_table : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) } >kseg0_program_mem . = ALIGN(4) ; .dbg_data (NOLOAD) : { . += (DEFINED (_DEBUGGER) ? 0x200 : 0x0); } >kseg1_data_mem .jcr : { KEEP (*(.jcr)) . = ALIGN(4) ; } >kseg1_data_mem .eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) } >kseg1_data_mem . = ALIGN(4) ; .gcc_except_table : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) } >kseg1_data_mem . = ALIGN(4) ; /* Persistent data - Use the new C 'persistent' attribute instead. */ .persist : { _persist_begin = .; *(.persist .persist.*) *(.pbss .pbss.*) . = ALIGN(4) ; _persist_end = .; } >kseg1_data_mem /* * Note that input sections named .data* are no longer mapped here. * Starting in C32 v2.00, the best-fit allocator locates them, so * that they may flow around absolute sections as needed. */ .data : { *( .gnu.linkonce.d.*) SORT(CONSTRUCTORS) *(.data1) . = ALIGN(4) ; } >kseg1_data_mem . = .; _gp = ALIGN(16) + 0x7ff0; .got ALIGN(4) : { *(.got.plt) *(.got) . = ALIGN(4) ; } >kseg1_data_mem /* AT>kseg0_program_mem */ /* * Note that "small" data sections are still mapped in the linker * script. This ensures that they are grouped together for * gp-relative addressing. Absolute sections are allocated after * the "small" data sections so small data cannot flow around them. */ /* * We want the small data sections together, so single-instruction offsets * can access them all, and initialized data all before uninitialized, so * we can shorten the on-disk segment size. */ .sdata ALIGN(4) : { _sdata_begin = . ; *(.sdata .sdata.* .gnu.linkonce.s.*) . = ALIGN(4) ; _sdata_end = . ; } >kseg1_data_mem .lit8 : { *(.lit8) } >kseg1_data_mem .lit4 : { *(.lit4) } >kseg1_data_mem . = ALIGN (4) ; _data_end = . ; _bss_begin = . ; .***ss ALIGN(4) : { _***ss_begin = . ; *(.dyn***ss) *(.***ss .***ss.* .gnu.linkonce.***.*) *(.scommon) _***ss_end = . ; . = ALIGN(4) ; } >kseg1_data_mem /* * Align here to ensure that the .bss section occupies space up to * _end. Align after .bss to ensure correct alignment even if the * .bss section disappears because there are no input sections. * * Note that input sections named .bss* are no longer mapped here. * Starting in C32 v2.00, the best-fit allocator locates them, so * that they may flow around absolute sections as needed. * */ .bss : { *(.dynbss) *(COMMON) /* Align here to ensure that the .bss section occupies space up to _end. Align after .bss to ensure correct alignment even if the .bss section disappears because there are no input sections. */ . = ALIGN(. != 0 ? 4 : 1); } >kseg1_data_mem . = ALIGN(4) ; _end = . ; _bss_end = . ; /* Starting with C32 v2.00, the heap and stack are dynamically * allocated by the linker. */ /* * RAM functions go at the end of our stack and heap allocation. * Alignment of 2K required by the boundary register (BMXDKPBA). * * RAM functions are now allocated by the linker. The linker generates * _ramfunc_begin and _bmxdkpba_address symbols depending on the * location of RAM functions. */ _bmxdudba_address = LENGTH(kseg1_data_mem) ; _bmxdupba_address = LENGTH(kseg1_data_mem) ; /* The .pdr section belongs in the absolute section */ /DISCARD/ : { *(.pdr) } .gptab.sdata : { *(.gptab.data) *(.gptab.sdata) } .gptab.***ss : { *(.gptab.bss) *(.gptab.***ss) } .mdebug.abi32 : { KEEP(*(.mdebug.abi32)) } .mdebug.abiN32 : { KEEP(*(.mdebug.abiN32)) } .mdebug.abi64 : { KEEP(*(.mdebug.abi64)) } .mdebug.abiO64 : { KEEP(*(.mdebug.abiO64)) } .mdebug.eabi32 : { KEEP(*(.mdebug.eabi32)) } .mdebug.eabi64 : { KEEP(*(.mdebug.eabi64)) } .gcc_compiled_long32 : { KEEP(*(.gcc_compiled_long32)) } .gcc_compiled_long64 : { KEEP(*(.gcc_compiled_long64)) } /* Stabs debugging sections. */ .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } .stab.excl 0 : { *(.stab.excl) } .stab.exclstr 0 : { *(.stab.exclstr) } .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .comment 0 : { *(.comment) } /* DWARF debug sections. Symbols in the DWARF debugging sections are relative to the beginning of the section so we begin them at 0. */ /* DWARF 1 */ .debug 0 : { *(.debug) } .line 0 : { *(.line) } /* GNU DWARF 1 extensions */ .debug_srcinfo 0 : { *(.debug_srcinfo) } .debug_sfnames 0 : { *(.debug_sfnames) } /* DWARF 1.1 and DWARF 2 */ .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } /* DWARF 2 */ .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } /* SGI/MIPS DWARF 2 extensions */ .debug_weaknames 0 : { *(.debug_weaknames) } .debug_funcnames 0 : { *(.debug_funcnames) } .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) } .debug_pubtypes 0 : { *(.debug_pubtypes) } .debug_ranges 0 : { *(.debug_ranges) } /DISCARD/ : { *(.rel.dyn) } .gnu.attributes 0 : { KEEP (*(.gnu.attributes)) } /DISCARD/ : { *(.note.GNU-stack) } /DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) *(.discard) } /DISCARD/ : { *(._debug_exception) } } So what the heck am I doing wrong here? Thanks for any input! Nick |
|
|
|
从任何Bootloader开始。一旦您能够按所示引导加载程序剥离Bootloader应用程序。您的应用程序需要使用Linker脚本构建,您可以在Harmony中从引导加载程序选择中作为单独的步骤。(有点笨拙)您需要将它添加到应用程序项目中,并在链接器选项中选择使用外部链接器脚本。
以上来自于百度翻译 以下为原文 Start with any of the Bootloaders. Once you can Bootload strip the Bootloader app as indicated. Your App needs to be built with the Linker script the you can make from the bootloader selection in Harmony as a separate step. (It is kind of kludgy) You need to add it to the application project and select use external linker script in the linker options. |
|
|
|
谢谢你,NKurzmann!我离得越来越近了,现在我可以正确地连接引导加载程序了。通过查看地图文件验证,并且我可以闪动这两个程序。我必须用MPLAB IPE来做这件事,它需要一系列不同设置的秘密序列。休克:[8d]仍然,它不起作用。但我想我知道原因!但是我需要知道一个正常程序的启动顺序……1。)我认为**执行从0x9d000000.2开始。)从那里,它跳到引导加载程序,Harmony每次闪烁都会闪烁。那个地址应该是0x9fc000。到目前为止是这样吗?3)Bootloader判定没有什么可做的,它跳到哪里?到0x9D000?04????或者程序的入口点(在程序Flash)本身是什么?谢谢,Nick
以上来自于百度翻译 以下为原文 Thank you NKurzmann! I'm getting closer ... So I can now properly link the bootloader. Verified that with looking at the map file. And I can flash both programs. I have to do that with MPLAB IPE and it requires a secret sequence of steps with different settings. shock: [8D] Still, it doesn't work. But I think I know the cause! But I'd need to know the boot sequence of a normal program... 1.) I **think** execution starts at 0x9d000000. 2.) From there, it jumps to the bootloader that Harmony flashes with every flashing. That address should be 0x9fc0000. Is that right so far? 3.) After the bootloader decides that there is nothing to do, where does it jump to? To 0x9d000004??? Or what's the entry point of the program (in program flash) itself? Thanks, Nick |
|
|
|
它跳转到必须在引导加载程序(它是一个定义)和应用程序链接器脚本中是相同的。
以上来自于百度翻译 以下为原文 Where it jumps to must be the same in the bootloader ( it is a define there) and the application linker script. |
|
|
|
只有小组成员才能发言,加入小组>>
5160 浏览 9 评论
1998 浏览 8 评论
1927 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3170 浏览 3 评论
请问电源和晶体值之间有什么关系吗?PIC在正常条件下运行4MHz需要多少电压?
2225 浏览 5 评论
729浏览 1评论
613浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
503浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
628浏览 0评论
526浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-11-22 09:40 , Processed in 1.422692 second(s), Total 93, Slave 76 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号