[HN Gopher] Debugging hardware is hard
       ___________________________________________________________________
        
       Debugging hardware is hard
        
       Author : jkestner
       Score  : 26 points
       Date   : 2024-06-27 23:35 UTC (2 days ago)
        
 (HTM) web link (blog.supermechanical.com)
 (TXT) w3m dump (blog.supermechanical.com)
        
       | tonetegeatinst wrote:
       | As someone who is interested In hardware engineering and reverse
       | engineering....this truly is an understatement.
       | 
       | I have an old router I wanted to dump the firmware from as a
       | learning experience to see if I could go from firmware dumping to
       | finding a bug.
       | 
       | You got to constantly question if its your hardware or the device
       | that's faulty....you got to double check and make sure everything
       | is connected.
       | 
       | Want to do low level silicon reverse engineering? Yeah that's not
       | cheap as the tool, chemicals, and PPE is very expensive.
       | 
       | But I'd argure I shouldn't treat the hardware world as magic. And
       | with how expensive these devices are, some of it being justified,
       | other times a company just sets insane markup on items like
       | nvidia, its reasonable to want to learn how this stuff works and
       | how one could do it themselves.
       | 
       | This hardware reverse engineering is also how we find/look for
       | potential security issues or backdoors.
        
       | barbegal wrote:
       | Someone 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.
        
       | russdill wrote:
       | It would be incredibly useful to output the user clock and
       | monitor it with a logic analyzer.
        
       | lemonlime0x3C33 wrote:
       | I enjoyed reading through your debugging process and as someone
       | who has been trying to debug a custom board for a few weeks now I
       | feel your pain. I still cannot say that my issue is hardware,
       | firmware, or software -_-
       | 
       | I do have some UART devices that really seem to like when I just
       | disconnect and reconnect the GND wire when they start to act up.
        
       | mattegan wrote:
       | Great writeup! You show things are difficult to debug even when
       | you have a board where all of your signals of interest are easily
       | accessible.
       | 
       | It's a bad week when you have a bug that only is reproducible on
       | form-factor hardware. Imagine something like a tiny earbud where
       | the only pin accessible while the device is assembled is a single
       | UART (bidirectional) pin? Ouch. Then, if you can manage to
       | disassemble the earbud - the PCBs are usually so small most
       | signals never appear on the outer layers - so you can't probe
       | them even if you want to! Oh, and the issue is only appearing on
       | one out of every few thousand earbuds? Better not break your
       | failing unit while taking it apart! Good luck!
       | 
       | Just watched the Kickstarter video too -- looks like a great
       | product y'all! Best of luck :)
        
       | ChrisMarshallNY wrote:
       | True, 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 processor, and plugged in the ICE, and it
       | replaced the processor. You could view everything going on,
       | inside the processor, registers, accumulators, the whole kitchen
       | sink.
       | 
       | These days, it would be impossible to make an ICE for current
       | processors (although AI-assisted design might give us some
       | surprises).
       | 
       | A lot of issues came about, at the intersection of analog and
       | digital. Ringing could wreak havoc on digital buses, and, in
       | those days, we weren't as good at handling GHz frequencies, as we
       | are now. Every solder burr would become a microwave broadcast
       | antenna.
        
         | jagraff wrote:
         | 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?
        
           | ChrisMarshallNY wrote:
           | They run at GHz frequencies, and are orders of magnitude more
           | complex than the 8-bit processors of yore. ICEs were big
           | suckers, and they cost a great deal.
           | 
           | That was for linear-socket, MHz-clocked, 8-bit processors,
           | like the 8085.
        
       ___________________________________________________________________
       (page generated 2024-06-30 23:03 UTC)