完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
德赢Vwin官网
论坛|
我有一个应用程序，它将USB堆栈作为主机，将日志数据写入闪存驱动器。当我构建并运行没有特殊链接器文件的应用程序时，运行良好。当我试图通过Bootloader加载应用程序（这也需要优化1来适应）时，它运行良好，直到插入USB驱动器，此时我开始得到一堆地址、堆栈和一个偶然的数学错误。我可以告诉他们，它们来自于UbjHoalthMsdScsi.c，因为这是我在其中放置断点以调试和退出陷阱处理程序后返回的文件。是否有人提供一些可能的东西来寻找或调试步骤来找出原因？我试着把堆大小从256增加到512，但这没什么区别（尽管它为什么，所需的堆应该是相同的，不管程序是由程序员加载还是引导加载程序是正确的？）Bootloader从USB主机加载，所以我认为有些东西不会从Bootloader中返回，或者链接器文件不好。两者都来自有USB主机引导加载程序的老MLE，但我手头没有版本。PIC24FJ128GB108OS：Ubuntu MyLo.16.04LTSPLPABX版本：3.61xC16版本：1.31 i还实现了GETReLebug（），以试图捕获引起该问题的地址，但它似乎包含不在程序本身内的地址（即Nopr或FFFF反汇编指令在我的外部）应用程序代码（仅在读取设备内存后查看反汇编窗口）。
以上来自于百度翻译 以下为原文 I have an application that incorporates the u*** stack as a host for writing log data to a flash drive. When I build and run the application with no special linker file, it runs fine. When I attempt to run the application after loading via the bootloader (which also requires optimization 1 to fit), it runs fine until Insert the u*** drive at which point I start getting a bunch of address, stack and an occasional math error. Best i can tell they are coming from u***_host_msd_scsi.c, as that is the file the return to after I have placed a breakpoint in there to debug and stepped out of the trap handlers. Can someone provide some possible things to look for or debugging steps to take to figure out why? I tried increasing the heap size from 256 to 512 but that made no difference (although why would it, the required heap should be the same whether the program is loaded by the programmer or the bootloader right?). The bootloader loads from u*** host, so i'm thinking something is not being set back the way it should from the bootloader or that the linker file is no good. Both come from the older MAL that had the u*** host bootloader, but I don't have the version on-hand. pic24fj128gb108 OS: Ubuntu-Mate 16.04LTS mplabx versions: 3.61 xc16 versions: 1.31 I have also implemented getErrLoc() to attempt to catch the address that caused the issue, but it seems to contain addresses that are not within the program itself (ie nopr or FFFF disassembly instructions outside of my application code (just looking at the disassembly window after reading the device memory). 
0
|
|
相关推荐
4个回答
|
|
|
我首先要检查的是：1）引导加载程序和应用程序的配置字是否相同？如果它们没有加载到另一个上面，那么第一个加载的配置和固件中的某个地方就会出现故障。2）如果在引导加载程序和应用程序中使用一些PPS PIN映射，那么最好确保它们以相同的方式映射。激活多个PIN配置通道的PPS标志，否则第二个加载的应用程序将无法按照它想要的方式设置它的PIN。通常这个PPS锁是默认的…如果你需要像我一样的不同设置，那么你可以像我一样做：在引导加载程序中检查它是否被使用（PIN输入，RAM标记或类似）-如果它继续运行引导加载器，否则跳转到应用程序-当引导加载器是然后使用它在RAM中设置一个标记，它一直在执行，并进行软复位。在重置时，引导加载程序找到标记并跳转到应用程序，该应用程序可以任意设置它的PIN。
以上来自于百度翻译 以下为原文 The first things I would check are: 1) Are the config words the same for the boot loader and the application? If they are not then loading one on top of the other destroys the config for the first loaded and somewhere in the firmware there will be a failure. 2) If you are using some PPS pin mappings both in the boot loader and the application then you better make sure they are mapping the same way and also that the PPS flag for multiple pin configuration passes is activated. Otherwise the second loaded application will not be able to set its pins the way it wants to. Normally this PPS lock is the default... If you need different settings like I did then you may to do as I did: - in the boot loader check if it is to be used (pin input, RAM marker or similar) - if it is then continue to run the boot loader, otherwise jump to the application - when the boot loader is used then at the end set a marker in RAM that it has been executing and make a soft reset. On reset the boot loader finds the marker and jumps to the application, which can set its pins any way it likes. |
|
|
|
|
|
你好，鲍伯，谢谢你的回复。1）我把配置信息（所有的PrimaMac东西）放在一个共享的头文件中，应用程序和Bootloader首先包含在它们的主文件中，所以两者应该是相同的。2）这有点棘手，PPS可能是问题所在。我首先检查了在Bootloader中是否执行了PPS映射。我认为没有，除非它在USB库中有些模糊。我运行了RPor和RPIN的搜索，只在应用程序中找到它们。我注意到，我已经改变了它，尽管在引导加载程序中没有使用任何PPS，但我看不出它有什么不同。在这样做之后，我在没有链接器的情况下通过了我的应用程序，注意到OSCCONbits.IOLOCK在运行锁序列之后没有被设置：OLOCK位总是零。如果我将IOL1WORE重置为ON，则锁定序列将OsCONBIT.IOLoCK设置为1，但我注意到它在0启动，并且解锁序列不做任何事情。我在参考资料的印象中，IOL1WORD只是封锁了第二个解锁序列，但是它似乎只是把iOLoCK保持到0，所以永远不需要解锁。无论如何，我认为测试IOL1WORE = OFF是最好的设置，在这个设置中，我仍然有同样的问题。我只想把它搁置，直到我能找到解决陷阱的方法。
以上来自于百度翻译 以下为原文 Hi Bob, Thanks for replying. 1) I put the config info (all the pragma stuff) in a shared header file that both application and bootloader include first in their main files, so both should be identical. 2) This is a bit trickier and maybe PPS is the issue. I first checked if i did any PPS mapping in the bootloader. I don't think there is, unless it's obfuscated some how in the USB libraries. I ran a search for RPOR and RPIN and only found them in the application. I did notice that I had #pragma config IOL1WAY = ON and have changed it to #pragma config IOL1WAY = OFF , although without using any PPS in the bootloader, i can't see it making a difference. After doing that, i stepped through my application built without the linker and noticed that OSCCONbits.IOLOCK is not being set after running the lock sequence: __builtin_write_OSCCONL(OSCCON & ~(1<<6)); //Unlock Registers RPOR4bits.RP9R = 8;; /*set rp9 as sck1 (output)*/ RPOR7bits.RP14R = 7; /*set rp14 as sdo1 (output)*/ RPINR20bits.SDI1R = 6; /*set rp6 as sdi1 (input)*/ RPINR19bits.U2RXR = 25; //U2RX on pin 66 RD4 RP25 RPOR10bits.RP20R = 5;//U2TX on pin 67 RD5 RP20 __builtin_write_OSCCONL(OSCCON | (1<<6)); // Lock Registers The IOLOCK bit is always zero. If i reset IOL1WAY to ON, the lock sequence sets OSCCONbits.IOLOCK to 1, but i notice it boots at 0, and the unlock sequence doesn't do anything. I was under the impression from the reference materials that IOL1WAY just blocked a second unlock sequence, but it appears that it just holds IOLOCK to 0 always so no unlock is ever required. Anyway, I think for testing IOL1WAY = OFF is the best setting, and in this setup, I am still getting the same problem. I'm just going to leave it off until I can find a solution to my trap issues. |
|
|
|
|
|
你的IVT是否正确处理？其他ISRS工作吗？Bootloader是否留下任何中断启用标志集？
以上来自于百度翻译 以下为原文 Is your IVT correctly handled? are other ISRs working? does the Bootloader leave any Interrupt enable flags set? |
|
|
|
|
|
我不能说链接器文件中的IVT设置是100%，因为我刚刚从旧的MAL中取得了主机引导加载程序，但是，我可以说，我确实使用T1、T3、T45和RTCC中断而没有问题。下面是引导加载程序结束时使用的代码。USB有自己的中断设置有点奇怪，包括写“1”清除U1IR，但纠正我如果我错了：我只是检查，当我插入一个USB闪存驱动器，中断是由应用程序ISR，USb1中断在UBSHOST主机。C，也检查CN，RTCC，T1中断实际上是红色。根据我对IVT和重新映射的理解，如果它不正确，中断将无法向应用程序ISR进行矢量化。我认为这是正确的，只要链接器是一致的，但我不知道什么我不知道。
以上来自于百度翻译 以下为原文 I cannot say the IVT setup in the linker files is 100% as I just took it from the old MAL that had the host bootloader, however, I can say that I do use T1, T3, T45 and RTCC interrupts without issue. Here is the code used at the end of the bootloader. USB having it's own interrupt set is a bit weird, including the write '1' to clear on U1IR, but correct me if I'm wrong: USBHostShutdown(); //Disable USB interrupts U1IE = 0; U1IR = 0xFF; //write '1' to clear these (DS39897C-page 234) //Disable other interrupts IEC0 = 0; IEC1 = 0; IEC2 = 0; IEC3 = 0; IEC4 = 0; IEC5 = 0; IFS0 = 0; IFS1 = 0; IFS2 = 0; IFS3 = 0; IFS4 = 0; IFS5 = 0; _ALTIVT = 0; //switch to std interrupt vectors BootApplication(); //Launch App, there will be no code from BL run after this I just checked that when I insert a u*** flash drive, the interrupt is handled by the apps ISR, _USB1Interrupt in u***_host.c. also checked CN, RTCC, T1 interrupts are actually entered. From my understanding of the IVT and the remapping, if it were incorrect, the interrupt would not be able to vector to the apps ISR. I think it's correct as far as the linker is concered, but I don't know what I don't know. |
|
|
|
|
只有小组成员才能发言，加入小组>>
5238 浏览 9 评论
2028 浏览 8 评论
1950 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比？
3204 浏览 3 评论
请问电源和晶体值之间有什么关系吗？PIC在正常条件下运行4MHz需要多少电压？
2253 浏览 5 评论
778浏览 1评论
666浏览 1评论
有偿咨询，关于MPLAB X IPE烧录PIC32MX所遇到的问题
595浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
677浏览 0评论
576浏览 0评论
/6 
关注我们的微信
下载发烧友APP
德赢Vwin官网 观察
版权所有 © 湖南华秋数字科技有限公司
德赢Vwin官网 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
1032
评论
淘帖
2994
