Pysense pinout / wake on pin
Also, is there any documentation for the 3V3_Sensors and 3V3_Pymodule pins? I would have expected the former to stay up during deep sleep and the latter to go down, but it seems to be exactly the opposite?
Quick update: the fact that the pin was connected to a LoPy pin was just causing too many headaches.
I ended up cutting pin P9 on the LoPy, and things are much better. No additional resistor needed, no funky voltages, no weird signals all over (especially while going to sleep or waking up). It probably also saves quite a bit of power. It does wake up correctly on changes on the pin.
Of course, that means that you have to read the pin via the PIC:
1 if py.peek_memory(0xE) & 0x02 else 0
And you can't have callback triggers on pin changes while the ESP32 is active, but in my case it's not a problem as the ESP32 is only up long enough to read the pin and send a LoRa packet before going back to sleep.
Victory! I managed wake on pin with a Pysense!
Adding a 1.2K resistor between 3V3_Sensor and the input pin resolved the situation, with the high/low voltages within range. Coupled with the PIC firmware change, and changes to the Pysense library, the PIC wakes up and the Pymodule as well!
As I am definitely not a hardware guy, I'm pretty sure this is not really the best solution, as it results in very high "low" voltages on the input pin (1.63V when the LoPy is powered, 1.23V when it's not), but at least it validates the fact that you can definitely wake on pin with Pysense.
So, here are the details:
- The firmware needs to be modified to (at least) clear
INTFwhen it occurs, otherwise the ISR will be called forever.
@bucknall or @daniel, can you please release a new version of the firmware that does this? Ideally it would also set/clear a flag somewhere else that could be checked via
peek_memory. In my case I don't need this as the sensor I use keeps the signal high for a few seconds at least, so I just check if the pin is up on boot, but others may need it (and it would be required for a correct "wake up reason").
Until such a firmware is released, you can start from the existing Pysense 0.0.4 firmware .dfu, and do the following:
- make a copy (let's call it
- strip the DFU header with
dfu-suffix -D pysense_0.0.4-patched.dfu
- change bytes
8B 10(that's a
BCF 0B, 01replacing an unnecessary
- changes bytes
C2 1B(that's the new application checksum for the bootloader)
- re-add a new DFU header with
dfu-suffix -p 0xF011 -v 0x04D8 -d 0xFFFF -a pysense_0.0.4-patched.dfu
- Flash the new firmware onto the Pysense:
- power-on the Pysense with the button pressed
- within a few seconds, run
dfu-util -D pysense_0.0.4-patched.dfu
If you don't get your timing right it may fail, just retry a couple of times and it should work.
Change the Pysense library so that the line just before sending the
py.poke_memory(ANSELC_ADDR, ~((1 << 7)|(1 << 1)))
This is to keep RC1 a digital input.
Either in the Pysense library, or between the calls to
py.poke_memory(0x0b, py.peek_memory(0x0b) | 0x10)
This is to enable interrupts on RC1. Register
Option: you can change the edge on which you want interrupts with bit 6 (
INTEDG) of 0x95 (
- Connect your sensor to:
GND(pin 1 on the External I/O header of the Pysense)
Also add a resistor between
EXT_IO1. I used a 1K2 resistor, but:
- this will probably vary based on the sensor
- there's probably a much better way to do this to achieve the right voltages in all cases!
Now you can:
- check the status of your sensor with pin
P9or via the Pysense:
py.peek_memory(0xE) & 0x02(bit
- go to deep sleep using the Pysense library
- see your Pysense and LoPy wake up when the sensor sets its output high!
Again, if someone has a better way of wiring this up so that the levels are really correct whether the ESP32 is powered or not, that would be most welcome!
- The firmware needs to be modified to (at least) clear
@jcaron Sure, making notes of those changes! Thanks!
Ah indeed, I hadn't seen the update. @bucknall, don't forget to update the PNGs as well, they're often out of sync.
I'm not sure removing the EXT_IOx names or their mention on the module pinout make much sense, they require additional cross-referencing. Keeping the name and having the list of all connections both on the module pinout and the external I/O header pinout would be more useful I think.
E.g. P8 would have P8 / SD_DAT/ G15 / EXT_IO5 and EXT_IO5 would be labelled EXT_IO5 / P8 / G15 (and possibly SD_DAT)
This lets you see at once all the uses of any of the pins.
While you're in there, I think many people would find it helpful if the 3V3 and 5V pins (both on the modules and boards) were labeled as inputs or outputs, with their accepted voltage range and max current requirements for inputs, and max current draw for outputs.
Apologies for the lack of communication; we've been super busy this month as well as the fact that it is holiday season for many European countries, meaning that a number of our engineers are out of office.
I'll double-check this with Daniel but I believe that this should now be the correct version of the pinout.
Thanks for your patience,
looks like @bucknall finally correct the pinouts after that topic was brought up several times:
Although it seems still incomplete:
I have EXT_IO2 (external I/O header pin 7) connected to RC3 (verified, as I get the same value reading through the ESP32 and the PIC).
OK, so still stuck with this, and the lack of any response from Pycom is a little bit frustrating...
There was another issue with the Pysense library setting ANSELC for most pins which I addressed, but that still isn't enough.
Now what is hope is the last remaining issue is that the pin is also connected to the ESP32, and with the ESP32 powered down, there's quite a change, as an high signal only results in half the voltage, which I suppose is not enough to be recognised as high by the PIC. Probably something related to the ESP32 no longer providing the internal pull-up when not powered, but I'm not quite sure. I'm also not sure if the PIC provides a pull-up on RC1 or not (there's no register for that for port C).
Being a software guy and not a hardware guy, I don't have at hand all the necessary stuff to test, but I'll try to find out later today.
Any hints from anyone more versed on the hardware side of things would of course be most welcome!
Still on my ongoing quest for wake-on-pin...
Finally found the bootloader that is used (https://github.com/majbthrd/PIC16F1-USB-DFU-Bootloader), and the checksum that goes with it, so I was able to upload a new firmware version which clears INTF in the ISR.
There's some progress, as now a change on EXT_IO1 doesn't crash the Pysense even with INTE set, but it's not waking up the board yet...
So the remaining question is: how does the board get out of sleep? Is there a test for some specific conditions in the ISR which triggers the wake-up, or simply resuming after the SLEEP should be enough? The investigation continues...
@dbrgn The issue is that I use the button to switch to "maintenance" mode (where I activate Wi-Fi and don't go back to sleep right away when the button is pressed).
As stated in my message from yesterday, one can actually use pin 6 on the External I/O header (EXT_IO1), which is connected to RC1, which has interrupts contrary to the rest of port C.
The issue is now (I think) just modifying the ISR so that the INTF flag is cleared when the interrupt is triggered.
I have disassembled the .DFU and found a place where I can put the required instruction, patched the .DFU and re-built the DFU suffix, but when I try to upload that to the Pysense it won't work (upload is accepted, but the Pysense never gets out of DFU mode).
I think there's an additional checksum (2 bytes at offset 0x3efe in the .DFU file), but I have to idea how to compute it (i.e. checksum or CRC, over what data, etc.), but so I'm a bit stuck here, as I don't have access to the bootloader code which is probably the one making this check.
in the ISR?
Alternatively, if you can let me know how that checksum is computed (or exactly what tools I used to generate the DFU file) I could update it myself.
One way to get deep sleep wakeup with an external interrupt would be pin P13 on the pysense (wired to the button). The Pysense wakes up if you press it.
I hope this is going to be supported officially soon, and ideally documented with schematics. Pycom doesn't gain anything from not publishing the schematics, except making life harder for developers that have to find out on their own how the hardware they bought works.
OK, so the good news is that I was wrong on one point, there is an exception for RC1 which does allow interrupts, they are just handled via a different set of registers.
I have confirmed that the interrupt actually works. Now the issue is that I don't know what the interrupt service routine does (yet), and how to modify it for my needs. Also don't know what code there is after the
SLEEPinstruction (i.e. if the wake from deep sleep relies on the ISR or the code after the
I have tried the following things:
- enable INTE with GIE still on: the PIC hangs on interrupt (at least the REPL over USB), probably because INTF is not cleared in the ISR?
- disable GIE: the PIC hangs right away (at least the REPL over USB), probably because it's actually needed for something?
Are the sources for the PIC firmware available? It would save tedious disassembly.
Alternatively, would it be possible to get an updated firmware version which clears INTF (bit 1 in INTCON 0x0b) in the ISR, and a quick overview of how wake up is handled (via the ISR or via code after the SLEEP? Does it check for any specific conditions?).
connected to RC3
ah, you are right. Cleary, there is a trace on RC3 on the pytrack as well, not sure where it leads to though..
@this.wiederkehr Seems consistent with what I found on the Pysense, except I have EXT_IO2 (external I/O header pin 7) connected to RC3 (verified, as I get the same value reading through the ESP32 and the PIC).
However, my hopes of using it as a wake-up source just vanished, as port C does not allow interrupts.
So there does not seem to be anything on the external I/O header which could be used for this purpose, and the documentation is quite incorrect.
Quite a shame RA4 is not connected to anything!
I'm just trying to figure this out for the pytrack here is how I think the PIC is connected, tough this is just a draft:
RA0 USB D+ #IOC # IO INPUT ONLY RA1 USB D- #IOC # IO INPUT ONLY RA3 Button / Programming Button #IOC # INPUT ONLY # Pull up enabled by init script RA4 NC #IOC RA5 Accelerometer INT1, 2 or both? #IOC RB4 I2C SDA #IOC RB5 UART RX #IOC RB6 I2C SCL RTC Calibration #IOC RB7 UART TX #IOC RC0 EXT_IO0 EXT PIN5 ??? RC1 EXT_IO1 EXT PIN6 # INT PIN RC2 Battery Volatage Analog in RC3 NC RC4 PWR EN??? RC5 Reset on Pyboard? # Is made an input in the init script RC6 Power to the sensor RC7 Power to the gps - IOC means this pin support interrupts - NC NOT connected
As you can see above I think only 2 pins from the external IO header are connected to the pic (5,6) the remaining pins 7,8,9,10 seem to be only connected to the pyboard.
Looks like for the pytrack the documentation is quite wrong as well!
Interestingly external pin 5 seems connected to RC0 on the pic, which does not support interrupts ...
Looks like the pinout described here https://docs.pycom.io/chapter/datasheets/downloads/pysense-pinout.pdf is quite wrong.
Still haven't found any connections from EXT_IO4/5 to the PIC.
So I decided to test all the pins on the External IO header against all the pins on the PIC...
- Pin 1/GND is connected to VSS as expected
- Pin 4/3V3_Pymodule is connected to VDD. So I guess that confirms that's actually the power source for the PIC and the sensors, rather than to the Pymodule (whose 3V3 pin is actually connected to Pin 3/3V3_Sensor)
- Surprise: Pins 5, 6 and 7 (EXT_IO0, 1 and 2) are actually connected to RC0, 1 and 3 on the PIC!
- Still no luck finding any connection between EXT_IO4 and 5 and the PIC.
Will try using using RC3 as an input and as a wake-up source...
It would be great if we could have an answer to this. It tried finding the contacts directly on the board, but couldn't find any, probably because the contacts on the PIC are so small and I don't have the right tools for this.
I just need something that says EXT_IO4 is connected to RA4 or something similar.
BTW, I'm surprised that EXT_IO4 and 5 are actually connected to the module socket (EXT_IO4 to G11/P4/SD_CMD and EXT_IO5 to P8/G15/SD_DAT) even though that doesn't appear on the published pinout?