PRoC Bootloader EMI doesn't work with 222014-01

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
JeSy_1305731
Level 4
Level 4
First like received

I have a pioneer board CYBLE-042  and it works just fine with the PRoC module that came with the demo kit, ( the black board)  and also with a 022001 PRoC,  but if I switch to a PRoC 222014-01 the FRAM or I2C stops working,  it is not the board or Ram as I can swap back the modules and FRAM works fine.  is there some kind of Symbol or some kind of conditional compile thing going on that looks to see what silicon is being used and then stops code generation?   I ask because the 22014-01 is a 256K module and the other ones mentioned are 128K and the FRAM is 128K. 

I had to switch to a larger module because I ran out of code space.  If I turn on optimization I can fit in 120K but in full debug it has 170K

I tried using that demo project,  OTA bootloader,  and the project compiles and runs fine. but fails the transfer file in cysmart dongle.

I know this is FRAM not working error,  I can run the my full embedded code if I comment out any access to FRAM,

0 Likes
1 Solution

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

View solution in original post

9 Replies
Anonymous
Not applicable

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...

0 Likes

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

0 Likes
Anonymous
Not applicable

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?

0 Likes

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. 

0 Likes
Anonymous
Not applicable

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).

0 Likes

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.

Working OTA I2C on 222014.jpg

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.

0 Likes
Anonymous
Not applicable

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 P...

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

0 Likes

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

Anonymous
Not applicable

LOL; Sounds like it is the 1/100000 chip failing the testing procedures

0 Likes