drivers/sx126x: improve hardware detection#21905
Conversation
maribu
added
Type: bug
github-actions
bot
added
Area: drivers
maribu
force-pushed
the
drivers/sx126x/fix-hardware-detection
branch
from
49a1ac5 to
aaaae2c
Compare
maribu
force-pushed
the
drivers/sx126x/fix-hardware-detection
branch
from
aaaae2c to
a8aaafc
Compare
|
I have one very cursed setup where setting the packet type (modulation type) to LoRa then reading it back looks like this: 
On the second attempt it looks like this: 
I updated this PR to do three attempts at the detection, as I believe this might make the cursed hardware work. Testing will have to wait until Monday. I'll keep this as a draft until it is tested. Some context: The expected transfer is:
At the first attempt the devices keeps MISO just high, as if it is completely unresponsive. The packet type is then read as |
- split out the detection logic into a static helper function
- replace a forgotten debug `printf()` with `DEBUG()`
- add a `LOG_ERROR()` to when no device is detect to ease diagnosis of
a failing SPI bus / incorrect wiring / broken chip
- use a bullet-proof test:
- First set the modulation type to LoRa
- Then get the modulation type and expect it to be LoRa
Even if the reset of the devices fails (e.g. because the reset signal
is not connected) and the modulation would be different from LoRa, this
now should reliably detect the chip.
maribu
force-pushed
the
drivers/sx126x/fix-hardware-detection
branch
from
a8aaafc to
fba614b
Compare
|
I updated the PR to no longer try three times. After the power sequencing code of the cursed board was fixed, the board was less cursed and the chips reliably come up on the first try. I don't have a reason to believe that there is a benefit in retrying the detection, hence I removed this. |
What was this? |
|
Thx ❤️ |
4 participants
Contribution description
printf()withDEBUG()LOG_ERROR()to when no device is detect to ease diagnosis of a failing SPI bus / incorrect wiring / broken chipEven if the reset of the devices fails (e.g. because the reset signal
is not connected) and the modulation would be different from LoRa, this
now should reliably detect the chip.
Testing procedure
This should 100% detect when hardware is present, and 99.99% detect when hardware is not present.
Issues/PRs references
None