怎么使用MPLAB X IDE进行调试

在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