Issues with CM programming and psoc's correct operation

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

cross mob
JiKe_1344871
Level 1
Level 1

Has anyone run across a similar situation.  We have a part that is programmed by our cm, and then soldered onto the board.  We are seeing some of them fail, and can be fixed by reprogramming the code into the part.  When I say fail, they are actually really operating, but the temp sensing that the sigma-delta is supposed to be doing doesn't appear to detect the RTDs, and says they are not present.  I can't understand how reprogramming fixes the issue.

Now I know you may have questions on if the code is the same code as the CM's given hex file, they appear to be based on the following tests I did today.

1)  I used the psoc programmer app + miniprog 3 to verify the .hex file given to the CM matches the part on the board

2)  I then checked the Psoc creator build to see if it matches the file given to the CM using a binary diff tool - and they also match

3)  I then reprogram through the programmer + miniprog 3 with the same exact file

4)  Now the boards are reading the temps

Unfortunately I need to wait for another failed board from our assembly line, but this has happened to several before.  My next board I will try to jump into a running part with the debug and see if I can set up breakpoints.  It is still very confusing, because the overall operation of the digital serial interfaces appear to work fine, it is just the RTD module and the sigma delta section doesn't appear to be working.

Does anyone have any insight on what may be happening? 

Thanks,

Jim

0 Likes
1 Solution

Sorry, I finally got back to this code to look into it.  And it is was an internal coding issue.  We use the EEPROM to hold the products identity, and it was incorrectly storing the value.  It was thinking it was a different product, and would not reply back with the correct temperatures.

Please close this ticket - and thank you for your quick responses, bar mine were not!

View solution in original post

0 Likes
6 Replies
Vasanth
Moderator
Moderator
Moderator
250 sign-ins 500 solutions authored First question asked

Hello Jim,

As you have said "they are actually really operating, but the temp sensing that the sigma-delta is supposed to be doing doesn't appear to detect the RTDs, and says they are not present." could you please shed more light into it ? Could you please let us know how this is implemented at your end?

Best Regards,
Vasanth

0 Likes

I know, it doesn't sound believable or even possible.  That is why I'm posting it here, maybe I'm doing something wrong.  I will try to explain it, I have a program that runs a simple task scheduler that uses the analog sigma-delta and RTD block for converting RTD's into temps., and several digital blocks uart,.......

We received boards made from our CM with all the parts pre programmed.  Lately we have had a few boards that are placed into units that are failing on getting valid temps out.  We flag the parts not present based on open circuit "Missing RTDs".  So the part is working as expected, it responds to our comm protocol through multiple ports, but the analog just doesn't seem to be reading through the ADC.  So when I say they are "not present" that is our s/w code detecting open circuits by ADC results out of range.  Now the real funny thing, if I don't take the units, boards, chips,....out of the system, and we use our Android board that is connected through the UART to do a firmware (.cyacd) update through the cypress boot loader, it comes up working fine.  It reads the same RTD's that were connected prior with the non working original .hex flash, but after a simple boot loader update, WOW, we get temps.  It just doesn't make sense.

I had a board that I pulled out, and used the cypress standalone programmer on a PC.  I did a compare check of the .hex file we sent the CM to place on the part.  It confirmed what was programmed on the part.  Then I just did a reflash of the same program, and now it works.  This was on a board that I pulled out of production failure.

Any ideas on things to try?  Or what I'm doing wrong?  I'm going to take the next failure and see if I can debug into it, but right now, I don't have a failure, because reprogramming them, they appear to work just fine, and don't fail again (at least haven't been seen at this time) - We actually hvae a few boards that have been out in the field for several months with no issues detecting the RTDs.  We actually have 3 RTD's going through the PSoC's muxes, and none of them are giving a temperature value.  Even when we use 0C resistors, which are right in the middle of the RTD range.

We are using the PSoC3 CY8C3866AXI-040

Thanks,

Jim

0 Likes
Vasanth
Moderator
Moderator
Moderator
250 sign-ins 500 solutions authored First question asked

Hello Jim,

This looks really confusing.

Re-programming/bootloading solving the issue reduces of the chance of it being a hardware issue.

The boards out for several months kind of eliminate failure due to time. As you have said you checked both the programmed hex on the chip also, flash corruption during product development is also out of question.


We have to also make sure that is there anything you do while programming solves issue. Could you please tell me know what are the GPIOs involved in RTD measurement?

One more suggestion is to do a chip swapping with working board and a non-working board(without reprogramming the non-working board. This can also help in identifying whether the issue is hardware related.

Best Regards,
Vasanth

0 Likes

Hi Vasanth,

I agree, it is confusing, I just haven't seen anything like this before.  I would not eliminate it being software related, but the way I'm troubleshooting is bringing doubts to it being software, but possibly programming electrical properties.

Here's a little more about the programming.  Our boards with their displays are in the product.  The final test station we connect in all the temp sensors and run a 12-24 hour test on the system.  We get a report from production that the temps are showing --- which is an indication that the sensor circuits are open circuit (And possibly temp out of range (100C to -100C in our programmatically calculation) to indicate bad rtd).  For one reason or another, we have them reflash the program.  Nothing is disconnected from the system, we have an ethernet cable that loads our Android app with a cyacd bootloader file.  The app resets the psoc and pushes the update through the Cypress written bootloader.  The chip resets, and voila, we are now seeing temps.

Our lab is not the best for SMD rework, but we will give it a try.  I have a hot air tool at home to bring to work, and will "Carefully" swap some parts - luckily this SMD package shouldn't be bad with the flux.

I have another question though, Do you know if when I do a program verify on the miniprog 3 and cypress programming app if it just checks the "Program" code only, or does it also include the bytes that do the configuration of the part's digital and analog blocks (I am comparing the .hex file)?  If it is checking the configuration bits to the part, it would lean more to some issue with the code or maybe a reprogram of the part has changes to some electrical characteristic (I doubt it, but don't know how else to explain this).

I'm a little deep right now with a refactoring of our Android code, so my response may be in a week or so on the component switch.  I don't have a count, but it looks like the failure rate may be 40%.  We are only seeing them in our production, do you think the CM programming equipment may have issues - But remember, we are getting a .hex file verify confirming that the program matches.

In further troubleshooting, I would also like to get the miniprog up and running on this failing part and get a glimpse of the registers inside the part during a debug.  This will probably be the most enlightening on new data.

0 Likes

Sorry, I finally got back to this code to look into it.  And it is was an internal coding issue.  We use the EEPROM to hold the products identity, and it was incorrectly storing the value.  It was thinking it was a different product, and would not reply back with the correct temperatures.

Please close this ticket - and thank you for your quick responses, bar mine were not!

0 Likes
Vasanth
Moderator
Moderator
Moderator
250 sign-ins 500 solutions authored First question asked

Hi Jim,

Thanks for updating us. Happy Designing !

Best Regards,
Vasanth

0 Likes