On 2019-11-21 01:46, Michael Balzer wrote:
Shame on me. Reminder: expect the unexpected.
The egpio monitor actually caused this. Or more precisely, the MAX7317 input query, which was broken in a remarkable way.
Explanation:
The MAX7317 needs a deselect between addressing a register for read and reading the value returned. On the second SPI command to read the value, no TX was requested, just the two bytes RX.
But on SPI, there is no "no TX". An SPI transaction always is TX and RX in parallel. Doing a 0 byte TX + 2 byte RX SPI command via our SPI API actually means you'll be doing a TX of two zero bytes to the device while reading two bytes from the device.
And if you send two zero bytes to the MAX7317, it will interpret that as "set output port 0 to level 0"…
While that's totally clear from the datasheet: in my humble opinion, requiring separate request & response transactions and then assigning a command to a sequence of all zero bytes is bad design.
NOP on the MAX7317 is 0x20, so I've changed the input query to send that while receiving the result.
Thanks, Mark.
Back to the original issue: Input monitoring is disabled by default. Craig, you reported not being able to power down the modem 2 hours after I pushed the egpio monitoring. Did you have the issue with input monitoring enabled? If not, the issue still needs to be resolved.
I don't think the egpio monitor code is involved with my issue. The specific module I had the simcom wedge is the first one I bought (March 2018) and my receipt shows it's v3.1. I've seen this problem a number of times and had meant to collect some info and report it. I started this thread on Nov 16th. Looking at my server logs I think I was running 3.2.005-105-g9af31240-dirty (downloaded by that module on Nov 7th). Later that day (probably while trying to clear the problem with actually removing power from the module) I also booted 3.2.005-107-g350f5f10-dirty. I don't think the MAX7317 stuff got added until Nov 17 so I don't think there's any way I was running it. As I understand it, there is no control over simcom power just control of an input to simcom that requests that it powers off (or on). So is the problem that it's possible to wedge the simcom in such a way that it ignores the control input? Craig