.jpg?table=block&id=3043664f-39b0-81a6-bbb6-cd602600b946&cache=v2)
Intermittent issues
are one of the hardest to get to the bottom of. Most of the effort in these
cases is put into creating a reproducer that is reproducible. Getting to this stage requires
instrumenting up the device and running/repeating various test scenarios until the issue is
caught.
.jpg%3Ftable%3Dblock%26id%3D3043664f-39b0-816c-a11e-e83e14406da7%26cache%3Dv2)
868 MHz ISM band design
One of these cases, a 868 MHz ISM band design intermittently produced a lock-up by
entering into an not defined high current consumption stage with no communication to the
host controller. The device had a relatively high output power stage. The investigation led to
the observation that lock-up only occurred – albeit still intermittently – at maximum output
power configurations. Theory was that some radiated power coupled back to digital lines on
the PCB and got rectified on the IC input pins making the radio IC go into lock up. Sure
enough cutting off the lines made the issue disappear. From this point on the final
manufacturable solution was to revamp the PCB layout to prevent sensitive lines being
directly exposed. While the PCB could not be salvaged, the next iteration made it
manufacturing ready.
sub GHz ISM band design
Another case, again a sub GHz ISM band design produced intermittent hang-ups on some of
the devices. Current consumption indicated a definite state during start-up the radio IC
stack at. The key to solving the issue was instrumenting the device with DC current and
clock signal monitoring in various domains and placing the device in an infinite start-up
execution loop until the issue showed. The issue occurrence then could be correlated to the
phase relationship between two clock signals that were meant to do a handover between
startup states. Consulting the silicon vendor it turned out that there was an extra (not
published) timing parameter involved in the startup process that was only marginally
adhered to in the application. Start-up commands followed each other too slowly which
from the programming guide seemed a perfectly legitimate solution. Adjusting the start-up
sequence commands accordingly finally made the issue go away.
.jpg%3Ftable%3Dblock%26id%3D3043664f-39b0-81da-b082-c091a0c665e1%26cache%3Dv2)
.jpg?table=block&id=3043664f-39b0-81a0-9614-f6b01c7bceb3&cache=v2)
