You could always tell the program to start with big bit counts (i.e. 1000) until it overshoots, then step back and divide by two (i.e. 500) and proceed like that to have a faster cal
yeah update firmware 1st, va hardware flashing method... then 2 check datasheets for things like cpld and mcu, see where to hook up oscilloscope, if there is any detectable power glitches that is then disrupting or crashing the mcu execution but really its like the other guy already said: the 5v usb power rail must hold the clue, to finding if it is in fact power glitching on that specific rail, or on some co-driven adjacent power rail, that is near to those 5v usb circuit. would seem to be the sorts of places to speculatively hook up your oscilloscope channels onto. and trigger so on, the fact that its reliably reproducable issue, always by inserting or removing a usb key is great ! although admittedly annoying to have to keep rebooting the thing. ok then best wishes & am certain you will be finding it, because you always do! some great problem solving fault finding skills. always learning from this channel
Thanks Ian! Just waiting to receive my HP34401A which is used (in a working condition) but not calibrated. Do you have any video showing how to calibrate this unit using a PVDS?
4:00, there is a slight graphical glitch on the screen in the lower right corner. Where it says "Clear", the pixels look misaligned. It is subtle but it's there.
If possible disconnect the measure parts from ucontroller, and disconnet the LCD and see how it behave. -The AC filter board and secondary DC-DC psu is seem close to the data lines the data may gets corrupted by EMP. - the grounding points on the screen case, or shield on a flat cable, sometimes it charged up slowly and the controller or lvds lines had a esd strike from that issue. - the oscillator output can contain the second harmonics of the main frequency, it can cause lost or jittering clocks. Or simply the txco overdrives the clock input, or have current modulated grounding. -See the USB interface ESD protection diodes, or metal shild. The usb to board cable seem not shielded, it can cause problem when the protocol is work only on a shielded cable.
29:00 Another easy way to get such chips (of any size) of a board, is just cut the legs. Have to be careful that you dont slip and cut the PCB, but its a good way of removing destroyed tqfp packages of any size without needing specialty tools. After the chip is cut, you can use a regular soldering iron + wick to clean up the remains of the legs and the pads.
I had a similar problem with a board that would fail after 5-10 minutes for no apparent reason. Turned out to be a bad crystal. When I probed it, the signals were quite weak compared to a working board. Replaced it and it ran solidly for a 12 hour burnin and no problems since.
Nice bug :D I'm wondering why you are always waiting when you are able to simulate the problem by plugin USB stick. You can even log the power line behavior or any other line by plugin USB. You are lucky to have this possibility. Check if there is no intermittent problem with pullups (on flash or any other). Hot / cold spray could help. X-tal could be also a culprit.
that 5V regulator is screaming at me. .. i would apply a known 3.3v and 5v and isolate that PS board. else, check the oscillator. really interesting issue. keep me posted.
Most oscilloscopes has a trigger function on window instead of edge, allows you to set a say +/- 0.3 V window around 3.3 V and trigger if signal "goes out the window"
Hi Ian, I am really disappointed. (Not really, I love all your videos) I was anxiously awaiting another video on the Tektronix 2430, because I have one on the workbench right now and I was hoping to get some insights into your troubleshooting process on this way too complicated machine. Will you make another video and if so when can I expect it? Thanks!
I will make another video, but not sure when......it looks like I need to put in a lot of research into the issue and maybe acquire some spare parts first. Looking for a cheap working unit, or parts.
I would double check the USB port for any rubbish or shorts. The previous buyer might have broken something, could also e.g. not completed a firmware update. and make it corrupt. I would check the osccilator circuit and check the reset line with a trigger. Also not wait but just put a usb stick in to see if it crashes. Capacitors around the CPU? Hard one this little meter.
always use a really small (256Mb) usb stick, formatted FAT32 to update the firmwares. it has a firmware made in 2017, it might not recognize bigger usb sticks.
I've had systems lock up when the 5v was too low or getting dragged down, only needed to get down to 4.85 ish to be an issue. Maybe checking at 4.7v is too much?
Clock circuit working properly? Is it overclocking, underclocking or even stalling the CPU or other peripherals? Maybe the keypad (on the front) is sending rogue signals and the software isn't monkey-proof and locks up on bad inputs i.e. jumps into some infinite random loop.
That’s a nice problem 🤪. I’ve seen Jerry Walker fixing a Siglent digital power supply with similar random froze up. He add some capacitor on power rails due spurious that were triggering the rails watchdogs. In your case, plugging the stick and loading +5v, fails immediately. It might be a clue. At 15:47 your 5v is already 4.7v and a small deviation can stop the instrument to run without triggering the scope. Very interesting fail, I hope to see a winning continuation. 👍
My guess is courrupted firmware. The LPC2478F doesn't appear to have a boot loader in ROM! It appears from a quick look at the data sheet that in system programming programming is via UART0. If the initial programming was defective or it has been bricked by a failed software update or possibly the flash memory has lost data due to a semiconductor fault then I guess there is no easy recovery without the code and access to UART0.
Check the core voltage of that MCU, plus also check the voltage, using another probe, to check the return current path from the MCU to the power supply. Easy to have a poor connection in a through plated hole, that is high resistance, or goes intermittently open. So one probe on the MCU itself power pin, likely a 1V8 or so rail, and anoyther on MCU ground, both referenced to the ground connection of the 7805 regulator. Then possibly a third on the 5V supply to the USB port as well, and a fourth on the output of that clock oscillator. Set the triggers on each of the 3 to 200mV below standard voltage, and then trigger off one at a time, and not off the clock, so that when one triggers you can see clock still present at trigger, or the clock has gone. 4 channel scope, use all 4 channels.
I have no knowledge about the controller in your device, but some have a voltage supervisor build in witch can be activated via software or programming of a fuse. Those controllers therefore have a special supply voltage input for analog purposes, mostly used for the A/D converters but also used for the voltage supervisor. The power connection to this pin mostly is done via an inductor and a capacitor to ground for noise minimization. The internal resistance of this inductor reduces the voltage on this pin, also affecting the voltage supervisor. While software controlled usage of the A/D converters this voltage drops even more and may come below the voltage level of the supervisor. So if the supervisor level is set to high, with this scenario it can come to randomly software holds or restarts, depending on controller settings.
There could be a problem with the voltage supervisor, if there is any. You could feed one power line after the other with an external supply. For example starting with the 5V rail: set the external powersupply to apx. 5.2 V and watch the behavior.
Hi Ian, here a few tips you can try out. 9:14 disconnect the external interface on the backside, a faulty component there can be the issue. 10:45 the SPI header is usually (as you probably know) connected 1 to 1 to the 8 pin IC, where the first 2 pins of the header are not used. If this is the case, then you can do a complete dump of that 8pin IC , wipe the IC and flash the dumpfile back. This dump is usually double in size compared to the firmware file, otherwise you could update the firmware via this option. Regarding to this, extracting the contents of this 8pin IC and replace this IC is also an option. Another trick that others also suggested, is to use cold spray or heat to isolate a component that is "living on the edge of working", a little bit of cold or heat can cause the component to stop work properly. i don't think it's a pure overheating issue, because the crashes are randomly, useally a overheating issue occurs after a specific time, but if you have Thermal imaging camera, you can use that to rule this out. And last, disconnect the powersupply and feed the required voltage rails from a external powersupply.
I'd think about leaving a scope on the power rails, triggering on runt negative edges. Inexplicable behavious in my experience is frequently down to rail glitches.
try to heat up or cool down some ICs on the board. It could be a thermal issue somewhere. As some others decided, load the 5V supply and try to replicate the issue when powering the USB. The unit can freeze due to a 5V issue, or communication.
Defective decoupling I'd say, just trips over too much draw. Could be the display itself if it has any smarts in it. Plugging the USB in takes the micro over the edge.
My experience as firmware developer about update is that problem is in size and formatiing of USB drive. It freezes because of some int32 variable in file system stack. Check if drive needs to be fat16 formatted or something similar. As firmware is from 2017 I am sure that at that time noone wrote firmware that is compatible with drives >4GB ( probably they have used some open source library). Maybe crashes will diasppear after update. Check if there is some uart tx line . Most of the time there is crash handler that prints on serial even if logging is not enabled in firmware.
Wrong type of electrons, you are using northern supplied ones. Maybe sending it down south might be the answer. I hear that the northern ones are prone to sticking in component leads due to their cold and clammy nature. 🙂 I could charge a battery up with some good southern one and post it up if that helps. ;-)
@@IanScottJohnston Make sure you filter out the damp ones and those that have too many wee small dram's 🙂 looks to be a nice bit of kit once you get it working. But then it does seem to work as long as I do before needing a wee cup of tea. maybe unplugging it and swapping the socket for a kettle we would just never notice it.
Sounds like a PSU issue in the 5v rail. Specifically since plugging a USB drive triggers the issue consistently. You could try connecting a small load to the USB port to see if that triggers the issue.
I think I would use a FLIR or other to see if anything is getting a bit too warm. It seems as though something is on the edge. If you find something questionable, you could put a heatsink on it to see if that's all that is needed. Also, since the USB demonstrates a repeatable issue, I would disable it and see if the unit still crashes. Plugging in the stick draws power ... which could be leading to something getting grounded or voltage pulled down. I would also check to see what the USB power voltage is. If it's a bit low (e.g.~4.7, 4.8 ...), that could be a problem when plugging in the stick. I would monitor USB voltage before adding the stick, and after to see what happens. I would also disconnect the output pcb and any other non-essentials to get as bare as possible ... then if that works, add back until the problem returns. Good Luck! Cheers.
Another option is to use a different USB drive, or a USB test load that doesn't connect to data lines. If it doesn't crash anymore, then it's not the 5V supply. There's always the chance of issues with the signal lines that aren't due to the actual USB connection, but just noise or injection of noise as well!
Can you put a logic analyzer on the address/data lines? Are you hitting a watchdog timer? Can you program the firmware directly or do you need to go through the UI to do it? ? If you have to use the UI to program it, you could get someone with newer firmware to just read their chip directly and you could write that image onto your chip. Can you reset it to factory defaults It's like it's trying to access a block of data, but the address line is not getting set or is stuck low. Have you double-checked the filename (sometimes they are case sensitive). Maybe that lockup is just a different bug entirely. Or caused by the device trying to reach a memory address but it's address bit is stuck low. Is there any serial output you could trace?
Did you watch and understand the video? The RAM has been replaced and not fixed the problem. He can't upgrade because it crashes when a USB Flash drive (with new firmware) is inserted.
@@Brian_Of_Melbourne I commented before I watched the complete video, obviously yes something more complicated. Perhaps related to the usb controller chip?
Can you plug in the USB drive before you power on the unit? Wondering if it hangs the unit or you can proceed with a firmware update? Also wondering if you can determine what line is the hardware IRQ line to the microcontroller. Check and see if it always asserted when it hangs. If it is traceback to the device triggering it. It may be one of the 74 series chips you pointed out.
About screen is missing model number. Corrupt nvram/flash? Maybe why the update crashes as the model number is missing and causing problems. Doesn't help with the random hang though. Just a thought.
Cold spray parts one at a time, to see if the freezing makes it better or worse? The reset circuitry of the MCU? No floating pins due to bad solder of pull-up or filter caps? May create interrupt on change that are not serviced in the firmware? It could be so many other things, but this is what I would try next. Good luck.
