What are those PCB holders he is using?
Those are Hakko Omnivise PCB Holders. I have one and it's a joy to use. Super heavy and stable.
Debugging hardware is hard
11–20 of 32 posts
Re: Debugging hardware is hard
#12True, dat. My first job, was as a bench tech for an RF/microwave manufacturer (defense). I think that experience made me a much better debugger, when I switched to software. A lot of my work was analog (Spectrum Analyzers, Oscilloscopes, Signal Generators, etc.), but we also did a lot of digital debugging. One of the coolest tools we had, was what was called an "ICE" (In-Circuit Emulator). You yanked out the processo…
Why is it impossible to make an ICE for current processors? Just because they're too complex and/or data exfiltration at speed is too hard?
The umbilical cord for a 500-700 pad BGA would be...impressive.
Re: Debugging hardware is hard
#13True, dat. My first job, was as a bench tech for an RF/microwave manufacturer (defense). I think that experience made me a much better debugger, when I switched to software. A lot of my work was analog (Spectrum Analyzers, Oscilloscopes, Signal Generators, etc.), but we also did a lot of digital debugging. One of the coolest tools we had, was what was called an "ICE" (In-Circuit Emulator). You yanked out the processo…
I do some retro work, and in order to debug a system (this was at a time when I knew less about this type of system) I once plugged in a Raspberry Pi Pico into a Z80 socket (not directly of course) and ran commands to read/write from/to memory/IO/ROM to see if I could find the problem. Makes you feel quite omnipotent :)
Course, my setup didn't really emulate the Z80 to run code, it just emulated its signals for a handful of instructions, which I instructed the Pico to do on demand via its UART. (Pictures and some code: https://blog.qiqitori.com/2023/02/two-raspberry-pi-picos-pre...)
Re: Debugging hardware is hard
#14Someone else had a similar issue 6 years ago https://electronics.stackexchange.com/questions/334012/hsi-a... It sounds like the sampling clock frequency is not what is expected (but that's quite easy to check based on the transmitted signal so I'm quite confused) UARTs are nice if you are constrained on pins but SPI is always a safer bet where you don't have the necessary high accuracy clocks.
It's been forever since I used UARTs but I remember them being fairly resilient creatures. They center on the start bit and so as long as the clocks are close enough so you can sample the rest of the bits you should be good. Often the problem is configuration and not clock accuracy, e.g. how many stop bits or parity.
Re: Debugging hardware is hard
#15True, dat. My first job, was as a bench tech for an RF/microwave manufacturer (defense). I think that experience made me a much better debugger, when I switched to software. A lot of my work was analog (Spectrum Analyzers, Oscilloscopes, Signal Generators, etc.), but we also did a lot of digital debugging. One of the coolest tools we had, was what was called an "ICE" (In-Circuit Emulator). You yanked out the processo…
Many chips come with on-board debugging accessible via JTAG that lets you do most of what you'd do with ICE in the good old days.
Another option I've seen is to simulate/emulate at lower speeds with FPGAs.
I also had a lot of fun debugging electronics. My favorite story is spending more than a month debugging a TI DSP based board that I designed that wouldn't boot properly. It turned out that some of the ground pins (it had many) were left unconnected because the guy that did the PCB layout (not me, I did do layout for many of my designs but not this one), didn't notice a tiny segment that needed to be wired from the pin to the ground plane.
An important lesson I learned from debugging hardware is that you have to persevere, I learnt this from a very experienced EE I worked with, all problems can be found with enough perseverance. Kids these days (lol) give up too soon...
Re: Debugging hardware is hard
#16Someone else had a similar issue 6 years ago https://electronics.stackexchange.com/questions/334012/hsi-a... It sounds like the sampling clock frequency is not what is expected (but that's quite easy to check based on the transmitted signal so I'm quite confused) UARTs are nice if you are constrained on pins but SPI is always a safer bet where you don't have the necessary high accuracy clocks.
I had something like that 30 years ago on a Motorolla 68332 processor.
It could generate the high speed CPU clock using the 32khz clock as a reference. What I found was the layout guy ran a digital trace through the pins of the 32khz xtal. There was enough coupling that digital transitions on that line would cause the high speed clock to swing wildly. Which showed up as garbage on the UARTs. Joyous thing is most of the time that line was idle.
I cut and rerouted the trace and the problem went away.
Re: Debugging hardware is hard
#17I couldn’t find anything in the docs or on the Internet about why this might happen with the autocal, and there’s nothing that details exactly how it works either.
A quick search found this document on the internal RC oscillator calibration, which explains all you need to know: http://nic.vajn.icu/PDF/STMicro/ARM/STM32F0/STM32F0xx_intern...
It is recommended to stop all application activities before the calibration process, and to restart them after calling the calibration functions. Therefore, the application has to stop the communications, the ADC measurements and any other processes (except when using the ADC for the calibration, refer to Step 5. below). These processes normally use clock configurations that are different from those used in the calibration process. Otherwise, errors might be introduced in the application: errors while reading/sending frames, ADC reading errors since the sampling time has changed, and so on.
Re: Debugging hardware is hard
#18True, dat. My first job, was as a bench tech for an RF/microwave manufacturer (defense). I think that experience made me a much better debugger, when I switched to software. A lot of my work was analog (Spectrum Analyzers, Oscilloscopes, Signal Generators, etc.), but we also did a lot of digital debugging. One of the coolest tools we had, was what was called an "ICE" (In-Circuit Emulator). You yanked out the processo…
Intel processors have DP/XDP/ITP which does much the same thing as an ICE, except it's integrated on the chip.
Re: Debugging hardware is hard
#19Is it possible that the autocal is in the process of shifting the phase the clock it controls to match the reference clock, and that the user is supposed to wait until that's done before running phase-sensitive operations? I'm unfamiliar with the chip in question, just making guesses or shots in the dark.
Re: Debugging hardware is hard
#20What are those PCB holders he is using?
Google Image search?
Btw, for through hole soldering and rework, Idea-Tek PCSA is on a completely different level of efficiency.