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?
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
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.
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.
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!
Thanks for updating us. Happy Designing !