[问答]

怎么使用MPLAB X IDE进行调试

问答对人有帮助，内容完整，我也想知道答案 0 在MPLAB X IDE中调试时，有些事情让我发疯。这个线程与DSPIC33主题中的ZAK949线程有关。我有一些问题，我不喜欢占用他的线程。最初的任务相当简单：擦除Flash中的一个页面，从Flash中读取，以显示成功。指令闪存-从闪存读回显示成功的DSPIC33 E…GM设备有不同的方式写入闪存比其他EP设备。代码的工作是：我用MPLAB X V3.45，XC16 V1.31，ICD3，DSSPICEV32 GM102（真实硬件），然后-作为一个笑话-我添加了一些代码R擦除前的闪光灯和编程闪光灯。我在编程后第一次运行代码：已经有了我想稍后编程的值0x11223和0x445 566的指令！这让我疯狂的思考，程序员没有抹掉Flash缓存吗？为什么初始值0x000和0x00？002从MFLASH缓冲器[512 ]＝{1，2，3，4}，我花了很多时间尝试以另一种方式读取（MPLAB IPE或MPLAIDID/Read设备存储器）。结果总是：值0x11223和0x445 566真的存在于存储器0x1000和0x2000上。他们是怎么到达那里的？甚至更疯狂：我把代码从编程指令0x11223改为指令0xaaaaa，编译和运行，然后在编程之前，这些新值0xaaaaa已经在闪存中。我的下一步是在汇编函数中设置断点，用于擦除和编程。只是想看看他们在我读闪光灯之前有没有被打过电话。没有一个断点被击中。在一些其他动作之后，我在程序集编程函数中添加了一个返回值，因此该函数不做任何事情。而令人惊讶的是，我现在没有得到0x11223和0x456566，而是得到了0xFFFFFF和0xFFFFFF，并在擦除函数中添加了一个返回。得到了0x000和0x090002总是在闪光灯。那么什么？改变函数——根据调试会话-从来没有被称为改变读取闪存的结果？作为一个附加的测试，我将擦除和编程功能恢复到初始状态，并在主C中添加了（…）：当Bease= 0和BPATH＝0时，Flash的初始读数返回0x00 000 01/0x00 00 02，当Bease= 1和BPATH＝1时，它返回0xAAAAAA和0x445 566。我的结论是：调试会话类似于预执行代码，从而忽略汇编函数中设置的断点。请告诉我，我不是疯了！以上来自于百度翻译以下为原文 Something makes me crazy while debugging within MPLAB X IDE. This thread is related to a thread from ZAK94 in dsPIC33 Topics. I have some questions and I dislike to occupy his thread for this. The initial task was quite easy: - erase a page in Flash, - read back from flash to show the success - store to instructions to flash - read back from flash to show success The dspic33E...GM devices have a different way to write to flash than other EP devices. The code which did the job was like : #include "xc.h" #include "FlashUtilities.h" // // one Flash Row is 64 Instructions // one Flash Page is 8 Rows = 512 Instructions // for test use fixed address 0x1000 in Flash // still must be checked for devices with more than 64k Instructions (...address(0x010000) ) __prog__ unsigned int __attribute__((space(prog), address(0x001000), aligned(1024), section("myFlashBufferSpace"))) mFlashBuffer[512]={1,2,3,4}; // RAM: // Data in Flash is organized as 24 bits, // use different buffer for high byte and low word of instructions unsigned int __attribute__((section("myRAMBufferSpace"))) InstructionsLow[64]; unsigned char __attribute__((section("myRAMBufferSpace")))InstructionsHigh[64]; // maybe use 'uncompressed' buffer to read all 24 bits of instructions unsigned long __attribute__((section("myRAMBufferSpace")))InstructionsUncompressed[64]; int main(void) { flashPageErase(&mFlashBuffer); // read back FLASH , expected 0xFFFFFF flashReadUncompressed(&mFlashBuffer,64,&InstructionsUncompressed); // write two instructions to FLASH flashDoubleInstructionWrite(&mFlashBuffer,0x00112233,0x00445568); // read back , expected: // InstructionsUncompressed[0]=0x00112233 // InstructionsUncompressed[1]=0x00445566 flashReadUncompressed(&mFlashBuffer,64,&InstructionsUncompressed); while(1) { Nop(); } return 0; } I used MPLAB X v3.45, XC16 V1.31, ICD3, dsPIC33EV32GM102 (real hardware) Then -just as a joke- I added some to code read the flash BEFORE erasing and programming the flash. I run the code first time after programming and: The instructions already hat the values 0x112233 and 0x445566 that I wanted to program later! And that was making me crazy and thinking about - did the programmer fail to erase the flash buffer? - why aren't the initial values 0x000001 and 0x000002 as expected from mFlashBuffer[512]={1,2,3,4}; I spent a lot of time trying to read the in another way (MPLAB IPE or MPLAB IDE / read device memory. The result was always: values 0x112233 and 0x445566 were really present on memory 0x1000 and 0x2000 How did they get there? And even more crazy: I changed the code from programming instruction 0x112233 to instruction 0xAAAAAA, compiled and run and, -before programming anything- these new value 0xAAAAAA was already in flash. One of my next steps was to set breakpoints in the assembly functions for erasing and programming - just to see whether they were called in any way before I read the flash. None of the breakpoints were hit. After some other actions I added a RETURN early in the assembly programming function, so the function does just nothing. And what a surprise, instead of getting 0x112233 and 0x445566 I now got 0xFFFFFF and 0xFFFFFF, and -adding a RETURN in the erase-function- finally got 0x000001 and 0x000002 as always expected to be at the flash. So what? Changing functions which -according to the debug session- never are were called is changing the result of reading flash? As an additional test i restored my erase and program functions to their initial state and added if(...) in the main.c: int main(void) { unsigned long nInstruction=0xAAAAAA; int bErase=0; int bProgram=0; flashReadUncompressed(&mFlashBuffer,64,&InstructionsUncompressed); Nop(); Nop(); if (bErase!=0) { // erase flash flashPageErase(&mFlashBuffer); } // read back FLASH , expected 0xFFFFFF flashReadUncompressed(&mFlashBuffer,64,&InstructionsUncompressed); Nop(); Nop(); Nop(); // write two instructions to FLASH if (bProgram!=0) { flashDoubleInstructionWrite(&mFlashBuffer,nInstruction,0x00445568); // read back , expected: // InstructionsUncompressed[0]=0x00112233 // InstructionsUncompressed[1]=0x00445566 flashReadUncompressed(&mFlashBuffer,64,&InstructionsUncompressed); flashDoubleInstructionWrite(&mFlashBuffer[2],0x00778899,0x00AABBCC); flashReadUncompressed(&mFlashBuffer,64,&InstructionsUncompressed); } while(1) { Nop(); } return 0; } When bErase=0 and bProgram=0, the initial read of flash returns 0x000001/0x000002 and when bErase=1 and bProgram=1 it returns 0xAAAAAA and 0x445566. (reproducable) My conclusion: The debugging session does something like pre-executing code and thereby ignoring breakpoints set in assembly functions. Please tell me that I'm not crazy! Attached Image(s) Attachment(s) main_V2.c (2.02 KB) - downloaded 0 times 0
2019-3-29 10:44:56　　评论淘帖0 邀请回答您可以邀请以下用户，快速回答问题 × qun333 该类别下有 57 个回答。邀请回答技术发广告该类别下有 56 个回答。邀请回答 caoguiqun 该类别下有 56 个回答。邀请回答 psw30 该类别下有 44 个回答。邀请回答伊丹姿子该类别下有 41 个回答。邀请回答 uwufwjrw 该类别下有 39 个回答。邀请回答 hetao1111 该类别下有 38 个回答。邀请回答 lc123617 该类别下有 35 个回答。邀请回答欧阳大大该类别下有 32 个回答。邀请回答作死不止该类别下有 31 个回答。邀请回答 asd010 该类别下有 31 个回答。邀请回答 wy8719 该类别下有 29 个回答。邀请回答 60user92 该类别下有 29 个回答。邀请回答 haikitty 该类别下有 28 个回答。邀请回答 ju978779 该类别下有 28 个回答。邀请回答嘻嘻爱哈哈该类别下有 28 个回答。邀请回答 xiuzhen122 该类别下有 27 个回答。邀请回答 pol666 该类别下有 27 个回答。邀请回答 ueywyrsdfs 该类别下有 26 个回答。邀请回答 lhly23 该类别下有 25 个回答。邀请回答举报杨晓静相关推荐 • MPLAB X IDE在调试时错过了绿色突出显示 3126 • 如何卸载MPLAB X IDE 5025 • 如果使用MPLAB X IDE进行调试，则会无意中强行停止 3635 • Windows XP上的MPLAB X IDE 4.00并且与MPLAB 8共存 3235 • MPLAB X IDE和MPLAB X IPE自动安装是正确的吗？ 3476 • 教你怎样去安装MPLAB X IDE软件？ 3880 • mplab x ide在编译时，发现没有starter kits,怎么解决 1697 • 请问如何使用MPLAB X IDE 和Proteus联合仿真 4887 • 求MPLAB X IDE教程 3929 • MPLAB X IDE 4.05没有AVR设备？ 2176 1个回答

答案对人有帮助，有参考价值 0 嗨，每一个PIC/DSPIC都有一个编程规范。在一个家庭中，它们并不总是相同的。FordDSPICEV32 GM102查看此文档：HTTP:/WW1.MICCHIP.COM/DeLoSs/En/DeVICECD/7000 05137F.PDFRGAGARD 以上来自于百度翻译以下为原文 Hi, Each PIC / dsPIC has a programming specification. They are not always the same within one family. For dsPIC33EV32GM102 look at this document : http://ww1.microchip.com/downloads/en/DeviceDoc/70005137f.pdf Regards

2019-3-29 11:04:05 评论举报杨叶