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...
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
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?
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.
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).
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.
I found the documentation of the differences in pinout:
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
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
LOL; Sounds like it is the 1/100000 chip failing the testing procedures