I2c_start（）如何影响Flash？

默认的编程过程将清除所有Flash内容。也就是说，所有的Flash都写到0x00。你可以另外指定，但是我选择这样离开。CRCITIIT检查CRC位置。如果是0x000，系统CRC必须第一次计算和写入。



     以下为原文
  The programming process by default will clear all flash contents. That is, all flash is written to 0x00. You can specify otherwise, but I choose to leave it that way. CRC_Init checks the CRC location. If it is 0x0000, the system CRC must be calculated and written for the first time.

1。如果你不启动/启用I2C，CRC检查是正确的吗？2。你能设置它使I2C由输入引脚启用/禁用。IE高，使I2C和低禁用CRC运行程序的PIN高和低，看看是否仍然失败。三。如果它只是失败的每一次针是高。如果可能，设置和清除另一个输出引脚，当你调用写到Flash函数调用时。使用CRO查看是否有人在呼叫。



     以下为原文
          1. If you don't start/enable the I2C, the CRC check is correct? 2. Can you set it up so that the i2C is enable/disable by an input pin. ie high to enable i2C and low to disable CRC run the program with pin high and low and see if that still fail. 3. If it only fail every time the pin is high. If it is possible, set and clear another output pin when ever you call the write to flash function call. Use a CRO to see if it was being called.   

我又得到了小文本框：



     以下为原文
          I got the small text box again :-(   

以下是一些有趣的线索。我试着让CRC检查过程原子化。那没有解决任何问题。CRC仍然失败。CRC校验背后的最初想法是，如果程序CRC失败一次，它将永远失败。所以这次，如果CRC在后续运行中通过，我只允许将该标志重新设置为OK。这起作用了……但这只是解决问题的一个帮手。它确实给出了问题所在的线索。
所以还有其他的可能性。运行的CRC值可能会变得腐败，尽管它是一个在函数内声明的静态变量，并且在理论上是不可访问的。错误标志可能会损坏，但这也是静态变量。或者堆栈可能变得腐败。
证据似乎标志着国旗腐化了。但是，除了调用API函数之外，我并没有以任何方式处理堆栈。因此，某种东西可能会以某种方式成长。我试着在CYDWR增加堆栈，但也没用。
我的下一步是看装配，看看物体在哪里。尽管如此，我还是得跟你谈谈。
在任何情况下，只有在调用I2CYSTART（）时才会出现问题。



     以下为原文
   Here are a few more interesting clues. I tried making the CRC checking process atomic. That didn't fix anything. CRC still fails. The original idea behind the CRC check is that if the program CRC fails even once, it is forever failed. So this time I just allow that flag to be re-set to OK if the CRC passes in a subsequent run. That worked...but is only a bandaid to the problem. It does give some clues about where the problem lies.
    So there are a couple other possibilities. The running CRC value could become corrupt, though it is a static variable declared within a function and inaccessable (in theory) to the outside world. The error flag could become corrupt, but that is also a static variable. Or the stack could become corrupt.
    The evidence seems to point to the flag becoming corrupted. But I am not manipulating the stack in any way besides calling API functions. So something may be growing into it somehow. I tried growing the stack in CYDWR, but that didn't help either.
    My next step is to look into the assembly and see where things are located. I will have to get back to you on that though.
    In any case, the problem only occurs when I2C_Start() is called.

你指出的证据似乎表明ISR相关。
如果在CRC计算中使用下一个字节访问的指针，则
需要声明哪些波动以确保ISR的免疫性
相关腐败。
问候，Dana。



     以下为原文
  Evidence as you point out sure seems to indicate ISR related.
     
    If you use a pointer for next byte access in CRC computation, thats
    what needs to be declared volatile to insure immunity from ISR
    related corruption.
     
    Regards, Dana.

如果可以，I2CL启动例程使用相同的CRC生成器硬件吗？



     以下为原文
          If may, Does I2C_Start routine using same CRC generator hardware?   

1。你提到你让CRC检查原子，我假设你在CRC检查过程中有所有中断被禁止。
2、如果你只是启动，但在启动时禁用I2C一次，看看这有什么区别吗？



     以下为原文
  1. You mentioned that you make the CRC check atomic, I assume you have all interrupt disabled during the CRC check process.
    2. If you just start but disable the i2C at start up only once, see if that makes any difference?

我感激所有的想法。我会试着回答一些问题。
1。如果你不启动/启用I2C，CRC检查是正确的吗？2。你能设置它使I2C由输入引脚启用/禁用。IE高，使I2C和低禁用CRC运行程序的PIN高和低，看看是否仍然失败。三。如果它只是失败的每一次针是高。如果可能，设置和清除另一个输出引脚，当你调用写到Flash函数调用时。使用CRO查看是否有人在呼叫。
1。如果我不启动I2C外围设备，CRC校验总是有效的。我没有看到它失败，除非我故意破坏程序空间的验证和验证的目的。
2。我不能再使用别针了。芯片是在一个系统中，我不容易获得引脚。我可以把命令发送到芯片，以启用和禁用I2C在飞行中，这是我看到的问题。
三。在这个过程中，我不写Flash。我只看闪光灯。16位程序CRC在芯片的寿命期间只写一次。在芯片的第一次上电过程中，计算完整的系统CRC。这个值存储在程序Flash的末尾，不再写入。假设这个值表示一个有效的程序。运行时CRC计算简单地将计算结果与存储在Flash中的结果进行比较。
奇怪的是，在第一个CRC生成/存储周期之后，W/O启动I2C，您会通过另一个CRC校验吗？思想是你的扫描PTR是一个字节关闭（或类似的东西）和拾取闪存的变化，因为CRC写入最后2行闪存。如果在ISR中使用，则指针将被声明为易失性。
对。完整的程序CRC大约每2秒重复计算一次。在不启动I2C的情况下，它们总是正确的。CRC函数不在ISR中。它在空闲周期从主呼叫。我的程序是一个非阻塞超级循环。
简化的超级循环执行看起来是这样的：
（1）{
如果定期出现事件断言{
照料它
}
现在/在空闲时间
{
运行增量CRC校验
}
}
我尝试停止中断，而“运行增量CRC检查”代码通过使用“CyGalAcActuabess”和“CyGalAlultDelabelabelabelabl”命令来执行。那无济于事。
你指出的证据似乎表明ISR相关。如果在CRC计算中使用下一个字节访问的指针，则需要声明其易失性，以确保ISR相关的抗腐败能力。
我已经尝试将CRC变量声明为易失性（再次，这些不在ISR中）。这无济于事。
如果可以，I2CL启动例程使用相同的CRC生成器硬件吗？
我的CRC功能是软件，与I2C功能无关。
1。你提到你让CRC检查原子，我假设你在CRC检查过程中有所有中断被禁止。2。如果你只是启动，但在启动时禁用I2C，只看一次，看看这有什么区别吗？
1。是的，正如上面提到的，在CRC计算过程中，我曾尝试中断中断。但是，假定程序是如何编写的，假定ISRS执行并正确返回，这是不必要的。结果相同，CRC失败。
2。你建议如何取消I2C？当然没有I2CyDISABLE（）函数。



     以下为原文
   I appreciate all the thoughts. I will try answering some questions.
    1. If you don't start/enable the I2C, the CRC check is correct? 2. Can you set it up so that the i2C is enable/disable by an input pin. ie high to enable i2C and low to disable CRC run the program with pin high and low and see if that still fail. 3. If it only fail every time the pin is high. If it is possible, set and clear another output pin when ever you call the write to flash function call. Use a CRO to see if it was being called. 
    1. If I don't start the I2C peripheral, CRC checking always works. I've neve seen it fail unless I intentionally corrupt the program space for purposes of verification and validation. 
    2. I am unable to use another pin. The chip is in a system and I don't have easy access to pins. I can send commands to the chip to enable and disable I2C on the fly, which is where I see the problem.
    3. I'm not writing flash during this process. I only read the flash. The 16-bit program CRC is written only once during the life of the chip. During the very first power up of the chip, a complete system CRC is calculated. This value is stored at the end of the program flash and never written again. It is assumed that this value represents a valid program. Runtime CRC calculations simply compare a calculated result with that stored in flash.
     
    Curious, after the first CRC generate/store cycle, w/o starting I2C, you
do another CRC check that passes ? Thought is your scan ptr is one
byte off (or something like this) and picking up the change in flash due
to CRC write into last 2 rows of flash. The pointer of course would be
declared volatile if used in an ISR.
    Yes. Complete program CRCs are calculated repeatedly approximately every 2 seconds. They are always correct without starting I2C. The CRC function is not in an ISR. It is called from main during idle cycles. My program is a non-blocking super-loop.
    Simplified super loop execution looks like this:
    while(1)
{
    if regularly occuring event asserts
{
    take care of it
    }
    else // now in idle time
    {
    run incremental crc check
    }
    }
    I have tried halting interrupts while the "run incremental crc check" code executes by using "CyGlobalIntEnable" and "CyGlobalIntDisable" commands around it. That doesn't help.
     
    Evidence as you point out sure seems to indicate ISR related.

If you use a pointer for next byte access in CRC computation, thats
what needs to be declared volatile to insure immunity from ISR
related corruption.
    I have tried declaring the CRC variables as volatile (again, these are not within an ISR). It doesn't help.
    If may, Does I2C_Start routine using same CRC generator hardware?
    My CRC function is sofware and unrelated to I2C functionality.
    1. You mentioned that you make the CRC check atomic, I assume you have all interrupt disabled during the CRC check process.
2. If you just start but disable the i2C at start up only once, see if that makes any difference?
    1. Yes, as mentioned above, I have tried disabling interrupts during CRC computation. This, however, is unnecessary given how the program is written, assuming ISRs execute and return properly. The result was the same; CRC failed.
    2. How would you propose disableing the I2C? There is of course no I2C_Disable() function.

你可以考虑提交一个案子。
CyPress网站
“支持”
“技术支持”
“创造一个案例”
这应该照顾禁用。



     以下为原文
  You might consider posting a case at -
     
        
              
    www.cypress.com
    “Support”
    “Technical Support”
    “Create a Case”
     
    This should take care of disable -
     
     

你能发布计算CRC的代码吗？
如果有一个想法我需要验证：
根据PSOC4 TRM，可执行内存从0亿×0到0×1FFFFFF，在0x00亿到0x00，7FFF是闪存，但是一个“异常向量表”位于0x00亿，它也被用作中断表（见TRMPAGE 38），所以可能是启动I2C COM。PoNoT只是设置了一个新的中断向量，因此改变了这个位置，这样您就可以通过排除该区域来测试。或者通过检查异常处理程序26或27是否发生更改，这些是SCB块中的异常处理程序。如果您是有利的，您可以将I2CYSTART（）函数的调用序列向下追溯到它真正执行的过程，可能向下到汇编程序级别。



     以下为原文
  Can you post the code for calculating the CRC?
    If have an idea I would need to verify:
   

    

• according to the PSoC4 TRM the executable memory is from 0x00000000 up to 0x1fffffff    
  
• out of that range, 0x00000000 up to 0x00007fff is flash memory    
  
• but an "exception vector table" is located at 0x00000000
       
  
        
  
  • it is used as interrupt table too (see TRM page 38)     
    
      
  
• so it might be that starting the I2C component just sets a new interrupt vector, and therefore changes this location   
  

    So you can test this by just excluding that region. Or by checking whether the exception handlers 26 or 27 change - these are the ones for the SCB blocks. If you are advantageous, you can trace the call sequence for the I2C_Start() function down to what it really does, probably down to the assembler level...

这就是我如何停止I2C，这不是问题。
关于向量表，我检查了两个位置，并且找不到那些内存位置的任何更改。



     以下为原文
   That is exactly how I stop I2C. That's not the problem.
    With regard to the vector table, I checked both locations and could not find any changes to those memory locations.

你好，达纳奈特和HLI，
我想我误解了你的意见。我试了你的建议。我执行以下操作
I2CYSTART（）；I2CyStUTE（）；CRCYIN（）；/初始化程序CRC；
你猜怎么着？它起作用了。之后，我可以启动和停止I2C外围设备，并且系统计算CRC保持正确。
如果你交换它们：
CRCI In（）；//初始化程序CRC，如果它不是I2CYSTART（）；I2CYSTATE（）；
它失败了。你们两个都在做某事。不过我还不确定。根据HLI的建议，也许创建了一个新的中断向量。在内存监视调试会话期间，我看不到它。我试过跳过程序内存的最初几个字节，但是还没有成功。



     以下为原文
   Hi danaaknight and hli,
    I think I missunderstood your comments. I tried what you suggested. I executed the following 
   
I2C_Start();
I2C_Stop();
CRC_Init(); // initialize program CRC if it hasn't been
   
And guess what? It works. I can start and stop the I2C peripheral after that and the system calculation CRC remains correct.
   
If you swap them:
    CRC_Init(); // initialize program CRC if it hasn't been
I2C_Start();
I2C_Stop();
    it fails. So, you both are on to something. I'm not sure what yet though. Perhaps a new interrupt vector was created, as suggested by hli. I'm just not seeing it during the debugging session with memory watch. I've tried skipping the first few bytes of program memory, but haven't had success yet.

函数“CRCGIN（）”是否执行CRC运算并在第一次调用时将值写入闪存？
如果是，你如何确定它是否是第一次？将用于检查损坏的标志/字节，因此它没有写入CRC，下次当CRC值未写入时，它会失败。



     以下为原文
  Is the function  "[size=11.199999809265137px]CRC_Init()" perform the CRC calcution and write the value to the flash if it is the first time being called?
    if it is, how do you determine if it is the first time or not? Would that flag/byte used for checking corrupted so it didn't write the CRC and the next time it failed as the CRC value was not written

我需要一个编辑函数。
压杆过快
如果你第一次被调用，你有一个功能来完成CRC运算并把这个值写在Flash上吗？
如果是，你如何确定它是否是第一次？将用于检查损坏的标志/字节，因此它没有写入CRC，下次当CRC值未写入时，它会失败。



     以下为原文
  [size=11.199999809265137px]I need an edit function.
    [size=11.199999809265137px] 
    [size=11.199999809265137px]Press post too quickly
    [size=11.199999809265137px] 
    [size=11.199999809265137px]You have a function to perforn the CRC calcution and write the value to the flash if it is the first time being called?
    [size=11.199999809265137px]if it is, how do you determine if it is the first time or not? Would that flag/byte used for checking corrupted so it didn't write the CRC and the next time it failed as the CRC value was not written