Electronics > Beginners
Pulling my hair out. Circuit boards stop working once shipped to client and more
tggzzz:
--- Quote from: Jackster on June 07, 2019, 10:32:18 am ---
--- Quote from: mcinque on June 07, 2019, 10:13:54 am ---If I may, I will invest time in understanding WHAT is failed instead trying to fix something that you don't know exactly.
HantekDSO5102P is fine, you could choose also a Siglent SDS1052DL or a used classic Rigol DS1052E.
I know that you should learn how to use it properly but it's something mandatory and not so difficoult (if I can use it , anyone else can do). You can't live without it.
Once you have an oscilloscope, you can't (and you wouldn't) get back!
Imagine this: without that instrument you are blind.
--- End quote ---
IDK what I am looking for though with it.
--- End quote ---
I agree with your previous inference that you will be getting someone else to redesign it (viz. "Even so, would it even be worth it if I need to hire someone to remake the circuit anyway..."). That seems like a sensible course of action.
If the hardware is poorly designed/implemented, then any software you add would be building castles on sand.
AndyC_772:
If you think the FTDI chip might be involved, the next step is to work out possible ways in which it could cause the symptoms you're seeing.
Are there any physical pins on the FTDI chip that are also shared with pins which are needed to burn your boot loader?
Without knowing the details of your design, I'd suggest two possibilities - either:
a) there's a logic signal (or signals) in common. Are your programming (SPI / reset) pins connected to the FTDI, or are they separate? If they're completely separate, then it really shouldn't be able to interfere with boot loading via that route.
b) they share a common power supply, and something bad is happening which is causing the voltage at the MCU to go out of spec during programming. Does anything get warm?
Another option (c) is that the FTDI chip is a complete red herring, and the difference is caused by heating, cooling and flux contamination of your PCB when you remove and replace components. Be sure to thoroughly clean the board after every rework operation, especially in and around the MCU crystal if it has one.
NivagSwerdna:
Be careful to not conflate problems... looks like the earlier revision boards have a reliability issue but that needs proper post-mortem analysis.
Rev3 boards...
--- Quote from: Jackster on June 01, 2019, 10:56:11 am ---And once the PCBs arrived, none of them would allow me to burn the boot loader onto the ATMEGA via the programming header.
--- End quote ---
This is a probably a different problem, consider your design/manufacturing to be flawed and work from first principles on one board. Does your PCB software have a rules check? Check the uP pins for things that are GND that shouldn't be.
Populate one board with the bare minimum to program the uP onboard and work backwards.
Good Luck!
ebastler:
--- Quote from: typematrix on June 01, 2019, 03:52:49 pm ---Have you gotten boards back from customer? i.e. customer returns.
If you get a customer return board back on your bench does it work?
--- End quote ---
I second that question, and don't think the OP has answered it (unless I overlooked some comment). This is an important step in finding the root cause of the failures in the field.
@Jackster: Do you actually know that the boards somehow "broke" in transit? Or are they still in the same shape they were in when you sent them out, but don't work at the customers while they still work when you (re-)test them at home?
Jackster:
I am not saying the FTDI chip is the cause btw. Just that when removed and replaced with a known working one, there is no boot loader issues.
I am pretty much on board with the issue being the board design. Probably just coincidence that the old FTDI is working and the new ones are not?
Only tested a handful.
--- Quote from: Ian.M on June 07, 2019, 10:34:44 am ---Possible fake FTDI chips? Hack a bad board to loop the FDTI's RX and TX pins, open the USB serial port with a terminal program and see if it responds
--- Code: ---NON GENUINE DEVICE FOUND!
--- End code ---
character by character as you type instead of the loopback echoing what you type. (see: https://www.eevblog.com/forum/microcontrollers/ftdi-gate-2-0/ )
--- End quote ---
I don't think so. They all have different serial numbers. They were cheap though at $2.78 per chip.
Doing as you said, it just echos back what I type.
--- Quote from: AndyC_772 on June 07, 2019, 10:58:20 am ---If you think the FTDI chip might be involved, the next step is to work out possible ways in which it could cause the symptoms you're seeing.
Are there any physical pins on the FTDI chip that are also shared with pins which are needed to burn your boot loader?
Without knowing the details of your design, I'd suggest two possibilities - either:
a) there's a logic signal (or signals) in common. Are your programming (SPI / reset) pins connected to the FTDI, or are they separate? If they're completely separate, then it really shouldn't be able to interfere with boot loading via that route.
b) they share a common power supply, and something bad is happening which is causing the voltage at the MCU to go out of spec during programming. Does anything get warm?
Another option (c) is that the FTDI chip is a complete red herring, and the difference is caused by heating, cooling and flux contamination of your PCB when you remove and replace components. Be sure to thoroughly clean the board after every rework operation, especially in and around the MCU crystal if it has one.
--- End quote ---
No shared pins for boot loading other than RESET.
Boards are pretty clean. Been using acetone as that is all I have :/
--- Quote from: NivagSwerdna on June 07, 2019, 11:08:22 am ---Be careful to not conflate problems... looks like the earlier revision boards have a reliability issue but that needs proper post-mortem analysis.
Rev3 boards...
--- Quote from: Jackster on June 01, 2019, 10:56:11 am ---And once the PCBs arrived, none of them would allow me to burn the boot loader onto the ATMEGA via the programming header.
--- End quote ---
This is a probably a different problem, consider your design/manufacturing to be flawed and work from first principles on one board. Does your PCB software have a rules check? Check the uP pins for things that are GND that shouldn't be.
Populate one board with the bare minimum to program the uP onboard and work backwards.
Good Luck!
--- End quote ---
I tried with just the ATMega328p, crystal and cap on the reset pin.
Pretty sure it burned the boot loader. Was a few days ago and forgot to write it down. Ill try again.
--- Quote from: ebastler on June 07, 2019, 11:10:05 am ---
--- Quote from: typematrix on June 01, 2019, 03:52:49 pm ---Have you gotten boards back from customer? i.e. customer returns.
If you get a customer return board back on your bench does it work?
--- End quote ---
I second that question, and don't think the OP has answered it (unless I overlooked some comment). This is an important step in finding the root cause of the failures in the field.
@Jackster: Do you actually know that the boards somehow "broke" in transit? Or are they still in the same shape they were in when you sent them out, but don't work at the customers while they still work when you (re-)test them at home?
--- End quote ---
The boards are sent out in an aluminium case.
They are physically fine. They just develop a fault where the software no longer cycles.
This can happen on new boards too. It will go through the code 3-6 times and then hang.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version