PRoC Bootloader EMI doesn't work with 222014-01

Ask the Community
Close
Ask the Community
nav search Icon
Forums gray-arrow gray-arrow
Resources gray-arrow gray-arrow
About gray-arrow gray-arrow
Groups gray-arrow gray-arrow
nav-user Account

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.
Log in arrow right alert

PRoC Bootloader EMI doesn't work with 222014-01

JeSy_1305731
Level 4
Level 4
First like received
‎Mar 26, 2018 07:58 PM
‎Mar 26, 2018 07:58 PM
Jump to solution

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,

Labels
Preview file
184 KB
0 Likes
Subscribe
1 Solution

Re: PRoC Bootloader EMI doesn't work with 222014-01

JeSy_1305731
Level 4
Level 4
First like received
In response to Anonymous
‎Mar 30, 2018 04:20 PM
‎Mar 30, 2018 04:20 PM
Jump to 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