PRoC Bootloader EMI不适用于222014-01

PSoC Creator确实使用了您选择的设备的条件编译。
如果你可以把你正在使用的图像的存档项目和你想上传的图片发布出来，这将有助于我们弄清楚到底出了什么问题。
否则，代码看起来像是运行FRAM代码并导致失败…



     以下为原文
  The PSoC Creator does indeed use conditional compiling for which device you have selected.
If you can post your archived project for the image you are using on the device, and the image you are trying to upload, that would help us all to figure out what is going wrong.
Otherwise, it looks like code is running the FRAM code and causing failures...

是的，确实没有任何代码要上载，我只是想从PSoC Creator中运行示例代码。我确实启动了一个新的项目，然后选择了一个代码示例，然后选择了OTAYEYMIB BooToLoad项目，然后导入了OTAYHYMILE BooTooDeject项目，编译并运行，它在CyBLY-042 BLE工具包（10563-56芯片）的Proc模块上运行良好，然后我进入设备选择器，并更改为222014模块并运行同一程序。程序在第一次访问I2C接口FRAM时锁定。我把逻辑分析仪放在公共汽车上，一个故障就出来了。因此，程序的ImithFRAM部分以某种方式锁定。我的猜测是有一些系统级的事情发生像上述条件编译的事当你开关硅，某处有一个表的查找信息，表示一定的I/O硬件上存在一定的硅，并兼容或不兼容的无线Th x，y，z
我猜这是发生了什么事情，因为硬件板是好的，我可以将触发10563板后，FRAM的作品就好，FRAM是绑在p5_1和p5_0对每一个模块，它不是一个I/O映射，除非有一个错误在这个硅映射表为222014米奥德勒？当我做bootloader的例子，我只是启动相同的文件，已经在运行的模块。它有一个闪烁的LED，并按下SW2和切换到bootloader模式



     以下为原文
  yes there really isn't any code to upload,  I am just trying to run the example code from PSoC Creator.   I did start new project, then selected a code example, then selected the OTA_EMI_Bootloader project,  then imported the OTA_EMI_Bootloadable project,  compile and run,  it works just fine on the PRoC module that came with the CYBLE-042 BLE kit (10563-56 chip),   then I just go into the device selector, and change to 222014 module and run the same program.   the program locks up when first accessing the I2C interface FRAM.  I put logic analyzer on the bus, and one glitch comes out and nothing else. so the EMI_FRAM part of the program is somehow locking out.  my Guess is there is some kind of system level thing happening like the mentioned conditional compile thing that happens when you switch silicon, somewhere there is a table of lookup information that says certain I/O and hardware exist on certain silicon, and is compatible with or not compatible with X,Y,Z  
I am guessing this is what is happening,  because the Hardware board is GOOD,  I can plug the PRoC 10563 board back on and the FRAM works just fine,   FRAM is tied to P5_1 and P5_0 on each of the module so it is not an I/O mapping, unless there is an error in this silicon mapping table for the 222014 module?  and when I do the bootloader example,  i am just bootloading the same file that is already running on the module.   all it does is has a flashing LED,  and you press SW2 and it switches into bootloader mode

你能附上一张“毛刺”的照片吗？
硬件都是一样的，只是不同的PROC芯片？或者支持DEV工具箱板也不一样？
比如，你把DROPIN测试模块/板转换成两个不同芯片的开发包吗？



     以下为原文
  Can you attache a picture of the "glitch"?
And the hardware is all the same, just different PRoC chips? Or is the supporting dev kit board different as well?
Like, are you switching a dropin test module/board into the dev kit for the two different chips?

我稍后会发布一系列的东西，比如设备查看器和项目。而是回答你的问题。是的，我使用相同的代码，在同一块板上运行，只需切换插入到板中的BLE模块。因此，在CYBLY-042上，它有2个模块插入到基板上。然后我买了额外的模块，上面有222014个模块。因此，我运行Bootloader示例，它运行在主板上，称为先锋板，连同BLE模块在黑板上与芯片10563-56一起运行。（这是一个带有演示工具包的PROC模块）。与I2C连接到P5Y0和P5Y1，并且在基板上使用FRAM进行空中引导引导。然后，我用相同的源代码将新模块222014插入到同一个先锋基站板上，222014个模块用I2C连接到同一个P5Y0和P5Y1。（显然，我做了一个设备开关并重新编译），所有的端口都是一样的，除了黑板上的SW2绑定到了PYS7，在新的模块上没有PYS7，所以你必须在新模块上跳过SW2到P1Y5。（例如输入Bootloader的代码）和新的模块运行Bootloader应用程序，我按下SW2，它开始在空中传输代码，但是当它试图将代码复制到FRAM中时。它呕吐了。



     以下为原文
  I will post a bunch of stuff later on today, like the device viewer and the project.  but to answer your questions.  Yes I am using the same code, running on the same board,  just switching the BLE modules that plug into the board..   so on CYBLE-042 it comes with 2 modules that plug into the base board.  I then also bought the extra module that has the 222014 on it.   so I run the bootloader example that runs on the base board,  called Pioneer board, along with BLE module on the black board with chip 10563-56. ( this is a PRoC module that comes with the demo kit).   with I2C connected to P5_0 and P5_1, and it does a bootloader over the air using the FRAM on the base board.   I then plug the new module 222014 onto the same pioneer base board using the same source code, with 222014 module with I2C connected to the same P5_0 and P5_1.  (obviously I did a device switch and recompiled)  and everything is the same port except SW2 on black board is tied to P2_7 and on the new module there is no P2_7 so you have to jumper SW2 to P1_5 on the new module. (for example code to enter bootloader) and the new module runs the bootloader application and I press SW2 and it starts to transfer code Over the air,  but when it tries to copy the code into FRAM. it barfs. 

嗯，我记得看到一个线程讨论问题或者在DEV板上使用FRAM，但我必须看看是否能找到更具体信息的线索。
我知道，我的插件模块，其中一些引脚在不同的IO之间切换，所以您可能需要检查没有一个引脚对于相同的位置是不同的（听起来像你所做的那样），但是如果这些引脚被切换到错误的映射，这样的问题会导致FRAM失效。地点）。



     以下为原文
  Hmmmm; I remember seeing a thread discussing issues or use of the FRAM on the dev board, but I'll have to see if I can find the thread for more concrete info.
I know for the plugin modules I have, some of them have pins switched between different IO, so you might have to check that none of the pins are different for the same locations (Sounds like you did, but an issue of this sort would cause the FRAM to fail if the pins are switched to the wrong mapped locations).

是的，谢谢你的帮助。我只是在一个不同的模块上运行同一个程序（同一个基础板，同样的FRAM），它是这样工作的，或者我买了一个坏的模块，或者一路上发生了一些事情，或者模块不喜欢我最后的应用程序PIN配置。
所以我用这个设置成功运行了222014个模块上的Bootloader OTA演示。
所以，当我把它设置为匹配我的具有这个PIN配置的最终应用程序时，该工具没有告诉我任何错误。
P04和P0E5上的UART
P5Y0和P5Y1上的I2C
P3O7，P3Y6，P3Y5
P4O1，P4Y1，P1Y4
开关P1Y5，P1Y6，P1Y7，P3Y4
所以这要么是某种非法配置，我有一个坏模块，还是PIN映射不正确？我现在必须做一些硬件调查，我必须做一些切割和跳线，使模块匹配我的最终申请。它也可以是操作员错误。



     以下为原文
  Yes thank you for trying to help.   I just ran the same program on a different module (same base board, same FRAM) and it works so Either i bought a bad module, or something happened to it along the way, or the module does not like my final application pin configuration.
 
So I ran the bootloader OTA demo on a 222014 module successfully with this set up.
 

 
so the tool does not tell me anything bad when I set it up to match my end application which has this pin config
UART on P0_4 and P0_5
I2C on P5_0 and P5_1
A2D on P3_7, P3_6, P3_5
LED on P4_0, P4_1, P1_4
Switch on P1_5, P1_6, P1_7, P3_4
 
so either this is some kind of illegal configuration, I have a bad module, or the pin mapping is not correct?  I will have to do some hardware investigation now,  I had to do some cuts and jumpers to get the module to match my end application.  it can be operator error now as well.

我发现了引脚差异的文档：
引脚映射之间的差异EZ-BLE ToC PROC评价板（CyBLY-222014-EVE）和BLE先锋套件（CY8CITK-042-BLE）-KBA212312
本质上，您将需要仔细检查模块之间的引脚变化，因为板针开关插座位置由于一些未知的魔术…
但是，事实上，你得到它的工作意味着硬件应该是所有好的谢天谢地。



     以下为原文
  I found the documentation of the differences in pinout:
Pin Mapping Differences Between the EZ-BLE™ PRoC™ Evaluation Board (CYBLE-222014-EVAL) and the BLE Pioneer Kit (CY8CKIT-042-BLE) - KBA212312
Essentially, you will need to double check the pins change between the modules, as the board pins switch socket positions due to some unknown magic....
But, the fact you got it working means that the hardware should be all good thankfully

是的，谢谢。引脚说明正确。所以我建立了第二个模块（重新设计了一个标准模块），这个模块工作了吗？运行正常。和FRAM工作。因此，经验教训是调试101。建立2，这样你就有了可重复的结果。！！！！
将工作模块的返工与不工作模块进行比较。现在我是$$！@
你猜怎么着？抓住一些磁通并回流芯片的一侧，其中P5Y0和P5E1在（I2C和FRAM）上清洗电路板，现在它工作了！所以我很高兴找到并解决了这个问题，但是现在我关心的是生产，所以故事的寓意不相信柏树吗？？？？或者我应该在中国某家工厂拍一张照片吗？LOL这是一个QFN包，下面的垫子，我希望有一些垫子至少跑到外面的板边缘，就像我在使用代码空间之前先使用的022001个一样。这222014个在包装下面有垫子。



     以下为原文
  yep thanks did the pinout confirm.  pinout correct.   so I built up a second module (reworked a standard module) and this one works?  runs as normal.  and FRAM works.  so lesson learned is Debugging 101.  Build 2 so you have repeatable results.  !!! 
 
compare rework on working module to not working module = SAME.   now  I'm #$!@  #*&%!
 
Guess what?   grabbed some flux and reflowed the side of the chip where P5_0 and P5_1 are on (I2C and FRAM)  cleaned the board and now it works!  So I am happy to have found and solved the problem, however now I am concerned about production,  so is the moral of the story don't trust Cypress???   or should I take a shot at the manufacturer over in china somewhere? LOL      This is a QFN package with the pads underneath,  I was hoping for something that has the pads at least run to the outside board edge like there was on the 022001 i was using first before running out of code space.  these 222014 have the pads underneath the package

听起来像是1/100000芯片在测试过程中失败了。



     以下为原文
  LOL; Sounds like it is the 1/100000 chip failing the testing procedures