完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
您好,我有一个PIC16F1829,用XC8V2.0编译器编写C。我使用MCC生成的Bootloader,它遵循8位Bootloader通信协议(http://www. McCyc.com /PROVO/8位Bootloader)。我自己的Bootloader主机程序在UART上闪动Bootloader。我现在做的是:*将所有从0x0擦除到Bootloader固件(0x1BA0)*将Bootloader复位向量写入0x0(4个指令)*在Bootloader固件(0x1B9C)之前写应用程序复位向量。应用程序从0x4到0x1b9c.*在每次写入之后计算校验和。*写EEPROM和CHECK.*Read设备。在MPLAIDE内部,我为我的应用程序设置以下限制:ROM范围:默认,-1B9C-1FFFand用于引导加载程序:ROM范围:1BA0- FFFAll似乎工作得很好。应用程序按预期启动和工作,我也可以重新启动到Bootloader和Flash。应用程序的程序内存闪存,ICD 3与引导加载的应用程序几乎相同。唯一不同的是,在ADDR 0x0上,引导装载器复位向量被定位,应用程序复位向量在0x1B9C上。正如预期的那样,配置位对于引导加载程序和应用固件是相同的。现在问题是如果我使用引导加载程序:-& gt;应用程序u。ART发送或接收错误的字节,但只针对特定的命令。如果应用程序在程序中闪烁,这不会发生。如果使用Bootloader并将应用程序重置向量放置在0x0(覆盖Bootloader复位向量),问题就消失了。为什么????我首先想到的问题是,引导加载程序固件在启动时设置了一些PIN /配置,这不是我的应用程序处理的,但是我的引导加载程序的启动代码开始于:任何时钟/GPIO/USAT配置都会发生(如果需要引导程序)。如果应用程序启动Bootloader,RXCHECK()检查0x78中的持久值。有人知道问题是什么,或者我的下一步可能是什么?
以上来自于百度翻译 以下为原文 Hello, I have a PIC16F1829 and write in C with the XC8 v2.0 compiler. I use the bootloader generated by mcc which follows the 8-bit bootloader communication protocol (http://www.microchip.com/promo/8-bit-bootloader). And I modified the bootloader to perform the following memory structure: I also write my own bootloader host program which flashes the bootloader over UART. What I currently do: * Erase all from 0x0 to bootloader firmware (0x1BA0) * Write bootloader reset vector back to 0x0 (4 instructions) * Write application reset vector just before the bootloader firmware (0x1B9C) * Write the rest of the application from 0x4 to 0x1B9C. * Calculate checksum after every write. * Write EEPROM and check. * Restart device. Inside MPLAB IDE I set for my application project the following restriction: ROM ranges: default,-1B9C-1FFF And for the Bootloader: ROM ranges: 1BA0- FFF All seems to work great. The application starts and works as expected and I can also restart into the bootloader and flash again. The program memory of the application flashed with an ICD 3 is nearly identical to the bootloaded application. The only different is that on addr 0x0 the bootloader reset vector is located and the application reset vector is at 0x1B9C. Just as expected. The configuration bits are the same for the bootloader and application firmware. Now the problem what happens if I use the bootloader: -> The applications UART sends or receives wrong bytes but only for specific commands This does not happen if the application is flashed over the programmer. And if I use the bootloader and place the application reset vector at 0x0 (overwrite bootloaders reset vector) the problem is gone. WHY??? I first thought the problem is, that the bootloader firmware sets some PIN/configurations at startup which is not handled by my application, but my startup code of the bootloader begins with: void bootloder_init(void) { if (!bootloader_required()) { STKPTR = 0x1F; // Reset stack. asm("movlp " str(APPLICATION_RESET_VECTOR >> 8)); asm("goto " str(APPLICATION_RESET_VECTOR & 0x7FF)); } } bool bootloader_required(void) { if (bootloader_indicator_check()) { bootloader_indicator_clear(); return true; } // ****************************************************************** // Check the reset vector for code to initiate bootloader // ****************************************************************** // This section reads the application start // vector to see if the location is blank // (0x3FFF) or not. If blank, it runs the // bootloader. Otherwise, it assumes the // application is loaded and instead runs the // application. EEADRL = APPLICATION_RESET_VECTOR & 0xFF; EEADRH = (APPLICATION_RESET_VECTOR & 0xFF00UL) >> 8; EECON1 = 0x80; EECON1bits.RD = 1; NOP(); NOP(); if ((EEDATH == 0x3F) && (EEDATL == 0xFF)) { return(true); } return(false); } Any CLOCK/GPIO/USART configuration happens afterward (if the bootloader is required). The bootloader_indicator_check() checks a persistent value at 0x73 if the application started the bootloader. Does anyone have an idea what the problem could be or what my next step could be? |
|
相关推荐
2个回答
|
|
在较低的优化级别中有一个内存损坏的bug。建议改变在BooToLoad中定义的框架缓冲区。在Wrad中定义一个“2 *”到写在FraseFuffer-Buff.WruteFlash缓冲区前面的数据和缓冲区。降下来的单位是字节单位。所以我们需要从一个到另一个,以保留足够的空间。
以上来自于百度翻译 以下为原文 There is a memory corruption bug that occurs in the lower optimization levels. Recommend changing the frame_t buffer defined in bootload.h to add a "2*" to the data and buffer fields in front of WRITE_FLASH_BUFFER. WRITE_FLASH_BUFFER is defined in memory.h. For PIC16F1 devices it is in word units while the size coming down is in byte units. So we need to convert from on to the other to reserve enough space. HTH. |
|
|
|
谢谢你,丹诺,谢谢你的回复。请你解释一下内存损坏的问题。WTF!如果我像你解释的那样增加缓冲区,输出在一开始就更差了,但是看起来“工作”的是复制引导程序帧缓冲区和APP输入缓冲区。但是为什么应用程序的输入缓冲区呢?它在没有引导程序的情况下是完美无瑕的。我必须分析这个问题,但是如何确保没有贪污bug呢?
以上来自于百度翻译 以下为原文 Thank you, Danno, for your reply. Please, can you explain me more about the MEMORY CORRUPTION BUG?! WTF? If I increase the buffer like you explained, the output is even worse at first... But what seemed to "work" was duplicate the bootloader frame buffer and app input buffer. But why the input buffer of the application? It works without a bootloader flawless. I have to analyze this problem but how to be sure there is no corruption bug? |
|
|
|
只有小组成员才能发言,加入小组>>
5208 浏览 9 评论
2017 浏览 8 评论
1943 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3189 浏览 3 评论
请问电源和晶体值之间有什么关系吗?PIC在正常条件下运行4MHz需要多少电压?
2244 浏览 5 评论
758浏览 1评论
646浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
563浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
657浏览 0评论
556浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-9 19:23 , Processed in 1.317965 second(s), Total 78, Slave 61 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号