指向Flash的指针怎么将闪存复制到RAM

确保你有一个虚拟地址，而不是一个物理地址，然后只使用MeMCPY（或者简单的循环）。



      以下为原文

    Make sure that you have a virtual address, not a physical address, then just use memcpy (or a simple loop).

如果你已经剪切和粘贴，而不是重新键入你的实际代码，GyWayPosits是一个Stutt，那么行应该是



      以下为原文

    If you have cut&paste and not re-typed your actual code, and g_waypoints is a struct, then the line
const uint8_t *rom=(const uint8_t *)g_waypoints;
should be
const uint8_t *rom=(const uint8_t *) &g_waypoints;

      以下为原文

   

// if sizeof rambuf >= sizeof g_waypoints
memcpy(rambuf, g_waypoints, sizeof g_waypoints);

我要感谢大家的意见和帮助。我一直在做更多的调查，我遇到了如下问题：从常住地点阅读没有问题。看起来很好。然而，在下面的函数中从数据表中得到：静态无符号int NVMUnlock（未签名int NVMOP）{un签署int状态；//暂停或禁用所有中断ASM易失性（“DI% 0”：“＝R”（状态））；/ /允许闪存写入/擦除操作和选择/ /闪存操作来执行NVMCON＝NVMOP；//写键NVMKEY＝0xAA9699；N/MKIMKEY＝0x556999 AA；/使用SET寄存器/NVMCONBIT启动操作。WREN＝1；NVMCONBITS。WR＝1；//NVMCONSESET＝0x8000；/ /等待操作完成（NVMCON和0x8000）；/ /恢复中断（状态和0x000）。否则，{ ASM易失性（“DI”）；} / /禁用NVM写使能//NVMCONCLRR＝0x000 04000；NVMCONBITE。WREEN＝0；//返回WRRR和LVDRR错误状态位返回（NVMCON和0x3000）；}如果行NVMCONBITES.WR＝1被注释掉，指针和FLASH被正确读取。如果没有，任何读取都返回为0xFF或空白Flash。奇怪的是，当我试图阅读Flash内容时，这个代码还没有被调用。简单地说，这条线的存在阻止了闪存被读取。有人让一个物理学家站在这条线上，因为因果关系被打破了。我不明白在调用这个代码之前，在代码的另一段中如何获得不同的行为。我已经证实了这不是通过设置断点来调用的。读取Flash内容的代码在这个代码之前先断开。优化设置为0。



      以下为原文

    I'd like to thank everyone for their comments and help.  I've been doing more investigation, and I've run into the following:
 
There isn't an issue with reading from the const location.  It seems to work fine.  However, in the following function taken from the datasheet:
 
static unsigned int NVMUnlock (unsigned int nvmop)
{
unsigned int status;
// Suspend or Disable all Interrupts
asm volatile ("di %0" : "=r" (status));
// Enable Flash Write/Erase Operations and Select
// Flash operation to perform
NVMCON = nvmop;

// Write Keys
NVMKEY = 0xAA996655;
NVMKEY = 0x556699AA;

// Start the operation using the Set Register
//NVMCONbits.WREN=1;
NVMCONbits.WR=1;
//NVMCONSET = 0x8000;

// Wait for operation to complete
while (NVMCON & 0x8000);
// Restore Interrupts

if (status & 0x00000001)
{
asm volatile ("ei");
}
else
{
asm volatile ("di");
}

// Disable NVM write enable
//NVMCONCLR = 0x0004000;
NVMCONbits.WREN=0;


// Return WRERR and LVDERR Error Status Bits
return (NVMCON & 0x3000);
}
 
If the line NVMCONbits.WR=1 is commented out, the pointer and flash are read correctly.  If not, any reads are returned as 0xff, or blank flash.  What is strange is that this code hasn't been called yet when I am trying to read the flash contents.  Simply the existence of that line prevents flash from being read.  Somebody get a physicist on the line because causality is being broken.  I don't understand how I can get different behavior in another section of code before this code is called.  I've verified that this hasn't been called by setting breakpoints.  The code to read the flash contents breaks first before this code.  Optimization is set to 0.  

你为什么要和NVMCON打交道？这只用于写Flash。这与你原来的问题无关。



      以下为原文

    Why are you messing with NVMCON? This is only used for writing to flash. This has nothing to do with your original question.

为了扩展这一点，我有以下测试代码：bVal= GyWooPosits（0）。度量；FVAL= GyWooPosits（0）。纬度；如果LeNEVMCONBITS。WR＝1；存在于代码库中，调试器报告BVAL和FVAL为0xFF。如果我注释NVMCONBITS。WR＝1，则调试器将值作为0x01和45.234，这是正确的值，因为GyWayPosits定义为：const WooPositTyt*AtAtditTyx（（地址（0x9D03F000））GyWayPosits [StSyWayPosik]＝//const WooPositt Gy WooPosits [StSyWayPosie]＝{{true，45.234，100.25，5，真的，真的，1，“你的任务开始了！”“祝贺你！”，0，0，false }，{true，1000.01000.05.0，true，true，1，“你完成了你的任务！”“，”，0，0，false }；



      以下为原文

    To expand on this a little, I have the following test code:
 
bval=g_waypoints[0].metric;
fval=g_waypoints[0].latitude;
 
If the line
NVMCONbits.WR=1;
 
exists in the codebase, the debugger reports that bval and fval are 0xff.  If I comment out NVMCONbits.WR=1, then the debugger reports the values as 0x01 and 45.234, which are the correct values as g_waypoints are defined:
 
const Waypoint_T __attribute__((address(0x9D03F000))) g_waypoints[SET_WAYPOINTS]=
//const Waypoint_T g_waypoints[SET_WAYPOINTS]=
{
{
true, 45.234, 100.25, 5.0, true, true, 1, "Your quest begins!", "Congratulations!",0,0,false
},
{
true,1000.0,1000.0,5.0,true,true,1,"You have completed your quest!","",0,0,false
}
};

我需要修改Flash。所以我需要读RAM，修改，然后写。



      以下为原文

    I need to modify flash.  So I need to read into RAM, modify, then write.
 
 

看来，你不是在等待重写之前试图重读。



      以下为原文

    It would appear you are not waiting for the write to finish before trying to read again.
 

更多数据：如果在main：int main（空隙）{StaseRealAlgLimeIZE（）；StulySudialIsByStEnter（StultStaseSubBSUnter）中设置第一个断点；……当它在StaseIn初始化时中断，我做一个读设备存储器。如果NVMCONBITIEW.WR＝1还没有注释，0x1D03F000（物理地址的虚拟ADDR）GyWayPoess的ESS为空白（0xFF）。如果已经注释掉，0x1D03F000具有正确的数据。



      以下为原文

    More data:
If I set a breakpoint on the first line in main:
 
int main(void)
{
SYSTEM_Initialize();
SYSTEM_Initialize2(SYSTEM_STATE_USB_START);
...
 
When it breaks on SYSTEM_Initialize, I do a Read Device Memory.
 
If NVMCONbits.WR=1 hasn't been commented out, 0x1D03F000 (physical location of the virtual address of g_waypoints) is blank (0xff).
 
If it has been commented out, 0x1D03F000 has the correct data.
 
 
 

无关你的问题，但你多久计划更新闪存单元？你不会说你使用的是哪一个PIC32设备，但我随机查看的一个PIC32设备（PIC32 MKGP/MC家族数据表）只显示20000个（最小）擦除/写入周期。除非你正在计划一个非常罕见的更新（比如说一天一次，寿命不到55年），那么这可能是错误的应用程序。蟑螂。如果您的设备具有数据EEPROM（min 160000擦除/写入周期），那么这可能是一个更好的方法。我不知道XC32编译器，但我会检查是否有内置宏来执行汇编程序中的解锁序列。C编译器将不必创建所需的汇编程序序列，而不会导致解锁失败的中间指令。如果它现在工作，那么你是幸运的。如果你正在读0xFF，那么你在读取它的内存之后，它已经被擦除，但是在任何值（当然不是0xFF）已经被写入到单元格中。也不要忘记你需要在擦除之前读一个完整的页面（*）到RAM中（我想PAG）。E是一次可以擦除的最小区域，更新所需的单元格，然后写回该页。你可以写到单独的单词和四个单词，但是只把“1”位设置成“0”，一旦一个单元格包含了“0”，唯一的一种方法是通过擦除/写循环来设置“1”。苏珊（*）你的设备可能允许行擦除。



      以下为原文

    Unrelated you you problem, but how often are you planning on updating the Flash memory cells?
You don't say which PIC32 device you are using but one that I looked up at random (PIC32MK GP/MC family datasheet) shows only 20,000(minimum) erase/write cycles.
Unless you are planning for a very infrequent update (say once a day for a lifespan of just under 55 years) then this may be the wrong approach. If your device has a data EEPROM  (min 160,000 erase/write cycles) then that may be a much better way to go.
I don't know about the XC32 compiler, but I'd check to see if there are built-in macros to perform the unlock sequence in assembler. The C compiler will not necessarily create the required assembler sequence without intervening instructions which will cause the unlock to fail. If it works now then you are lucky.
If you are reading 0xff then you are reading the memory after it has been erased but before any value (other than 0xff of course) has been written to the cell.
Also don't forget that you will need to read a complete page(*) into RAM before an erase (I think the page is the smallest region that you can erase at a time), update the cells that you want and then write the page back. You can write to individual words and quad-words but only to set the '1' bits to '0' - once a cell contains a '0', the only way to set a bit back to '1' is through an erase/write cycle.
Susan
(*) Your device might allow row erases

我想，我也遇到过类似的问题。我有一个Flash，实际上是我的代码修改过的。但是每当我读到变化的数据时，我就得到了初始值。我的黑客是把闪存中的数据声明为常量波动。这迫使编译器从FLASH中读取。如果你把它叫做黑客攻击，那就没问题了。我没有找到更好的办法。我也很抱歉，如果我的回答没有帮助。Nick。



      以下为原文

    I think, I had a similar problem.
 
I had a const that was in flash that was actually modified by my code. But whenever I read the changed data, I got the initial value.
My hack was to declare the data in flash as const volatile. That forced the compiler to read from flash.
It's OK if you call that a hack. I didn't find a better way.
I'm also sorry, if my answer was not helpful.
 
Nick

这个设备在它的生命中会有少于1000个FLASH写，所以它应该是好的。我也尝试了挥发性const，但那是在我把问题归结到这个之前：IFNVMCONBITES。WR＝1是在代码中，那么存储器0x1D03F000将不会在ICD3编程期间写入。E链接文件的一部分，其中2页的Flash（该芯片上的4K）被保留为航点数据：存储器{KSG00SudithMeX（RX）：Orthe= 0x9D900M，长度＝0x3f000路点（R）！X）：Oracle＝0x9D03F000，长度＝0x1000 Debug gExpReMeM:原点＝0x760KSG00BoToMeMe:原点＝0x0kSex1BoToMeMe:原点＝0xbfc000，长度＝0x490组态bfc01744：原点＝0xbfc01744，长度＝0x4组态bfc01748：原点＝0xbfc01748，长度＝长度＝0xbfc01744。0x4 CONTIONBFC0174C：ORACE＝0xBFC0174C，长度＝0x4 CONTIONBFC01750：ORACE＝0xBFC01750，长度＝0x4 CONTIONBFC01754：ORACE＝0XBFC01754，长度＝0x4 CONTIONBFC01758：ORACE＝0XBFC01758，长度＝0x4 CONTIONBFC01760：ORACE＝0XBFC01760，长度＝0x4 CONTIONBFC017C4：ORACE＝0XBFC01长度＝0x4组态bfc017c8：原点＝0xbfc017c8，长度＝0x4组态bfc017CC：原点＝0xbfc017CC，长度＝0x4组态bfc017d0：原点＝0xbfc017d0，长度＝0x4组态bfc017d4：原点＝0xbfc017d4，长度＝0x4组态bfc017d8：原点＝0xbfc017d8，长度＝0x4组态bfc017e0:梧里：7C4GIN＝0xBFC017E0，长度＝0x4kSe00DATAYMEM（W）！X）：Oracle＝0x8000，长度＝0x8000 SFRS：原点＝0xBF8000，长度＝0x100000组态FrsSfBFC01740：Orthe= 0xBFC01740，长度＝0x1C配置FrsSfBFC017C0:Orth= 0xBFC017C0，长度＝0x1C}，我完全被绊倒了。微芯片？？



      以下为原文

    The device will have fewer than 1000 flash writes over its life, so that should hopefully be ok.
 
I also tried the volatile const, but that was before I distilled the problem to this:
 
If NVMCONbits.WR=1 is in the code, then memory 0x1D03F000 will not get written during programming by the ICD3.  
 
Here's the part of the linker file where 2 pages of flash (4k on this chip) are reserved for the waypoint data:
 
MEMORY
{
kseg0_program_mem (rx) : ORIGIN = 0x9D000000, LENGTH = 0x3F000
waypoints (r!x) : ORIGIN = 0x9D03F000, LENGTH = 0x1000
debug_exec_mem : ORIGIN = 0x9FC00490, LENGTH = 0x760
kseg0_boot_mem : ORIGIN = 0x9FC00490, LENGTH = 0x0
kseg1_boot_mem : ORIGIN = 0xBFC00000, LENGTH = 0x490
config_BFC01744 : ORIGIN = 0xBFC01744, LENGTH = 0x4
config_BFC01748 : ORIGIN = 0xBFC01748, LENGTH = 0x4
config_BFC0174C : ORIGIN = 0xBFC0174C, LENGTH = 0x4
config_BFC01750 : ORIGIN = 0xBFC01750, LENGTH = 0x4
config_BFC01754 : ORIGIN = 0xBFC01754, LENGTH = 0x4
config_BFC01758 : ORIGIN = 0xBFC01758, LENGTH = 0x4
config_BFC01760 : ORIGIN = 0xBFC01760, LENGTH = 0x4
config_BFC017C4 : ORIGIN = 0xBFC017C4, LENGTH = 0x4
config_BFC017C8 : ORIGIN = 0xBFC017C8, LENGTH = 0x4
config_BFC017CC : ORIGIN = 0xBFC017CC, LENGTH = 0x4
config_BFC017D0 : ORIGIN = 0xBFC017D0, LENGTH = 0x4
config_BFC017D4 : ORIGIN = 0xBFC017D4, LENGTH = 0x4
config_BFC017D8 : ORIGIN = 0xBFC017D8, LENGTH = 0x4
config_BFC017E0 : ORIGIN = 0xBFC017E0, LENGTH = 0x4
kseg0_data_mem (w!x) : ORIGIN = 0x80000000, LENGTH = 0x8000
sfrs : ORIGIN = 0xBF800000, LENGTH = 0x100000
configsfrs_BFC01740 : ORIGIN = 0xBFC01740, LENGTH = 0x1C
configsfrs_BFC017C0 : ORIGIN = 0xBFC017C0, LENGTH = 0x1C
}
 
I'm completely stumped.  Microchip??
 

您好，您的阅读程序现在可能是按计划工作的。当调试时，程序可能已经运行。当设备被编程用于调试时，在调试程序启动之前，在程序被允许运行之前，在调试程序之前有一些间隔。采取控制，复位微控制器，并从一开始就启动程序。如果你有一个手动复位开关板，你可以尝试在编程过程中保持整个时间，直到调试器到达第一个断点。或者在Flash写代码部分之前插入一个长延时（1秒）。迈西尔



      以下为原文

    Hi,
Your Reading procedure is now probably working as intended.
 
When trying to Debug, the program have probably been Run already.
 
When device is programmed for debugging,
there are some intervals between Programming steps and before starting Debugger,
when program is allowed to run wild,
before Debugger take control, reset the microcontroller and start program from beginning.
 
If you have a Board with manual Reset switch, you may try holding this the entire time during programming, until debugger reach the first breakpoint.
 
Or insert a long delay (1 second) before the Flash Write part of code.
 
   Mysil

Mysil，这完全有道理。我来测试一下，让你知道。



      以下为原文

    Mysil,
 
That makes complete sense.  I will test it and let you know.
 

Mysil，这正是正在发生的事情。启动后添加延迟防止擦除代码运行。谢谢。我现在有一个问题写Flash，但我会张贴到PIC32论坛。



      以下为原文

    Mysil,
 
That was exactly what was going on.  Adding a delay after startup prevented the erase code from running.  Thank you.
 
I now have an issue with writing to flash, but I'll post that to the PIC32 forum.