Espruino Pico and accessing additional pins

Posted on
  • The Espruino Pico contains a significant number of pins not broken out to pins, but which are still potentially useful:

    C14/C15 - these go to pads that could be used for an RTC crystal. The pads are easy to access and hence re-purpose.

    A13-15 - These are used for JTAG debug. Debugging running code is beyond me (and probably 95+% of Espruino users), and the pins don't look too hard to solder to.

    B0 - As I understand, this is used to control the PFET to enable the Espruino to charge an externally connected battery from USB, if you close that jumper. Thus, if I don't want to do that, I should be able to just connect a little wire from that "jumper" (the appropriate side ofc) and just use it. But what gives me pause is that B0 is listed as a "USB" pin in the reference...

    Has anyone tried making use of these pins? Does anything have to be done in order to ensure that these pins can be used for GPIO?

    It definitely looks like something needs to be done for the jtag pins, based on jshardware.c:

    [#ifdef](­h/?q=%23ifdef) SWD_ONLY_NO_JTAG
      // reclaim A13 and A14
      GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGD­isable, ENABLE); // Disable JTAG so pins are available for LEDs
    [#ifdef](­h/?q=%23ifdef) STM32F1
    [#ifndef](­ch/?q=%23ifndef) DEBUG
      // reclaim B3, B4, A13 and A14
      // don't disable this when compiling with DEBUG=1, because we need SWD
      // for in-circuit debugging and we probably don't care about the LEDs
      // see
      GPIO_PinRemapConfig(GPIO_Remap_SWJ_Disab­le, ENABLE); // Disable JTAG/SWD so pins are available for LEDs

    What I don't understand is what this means for the pico - because the function GPIO_PinRemapConfig is defined in stm32f10x_gpio.c/h - that file name implies that the file won't even be used for the pico which uses an stm32f40x, not stm32f10x like original - but it must be, because espruino compiles for the pico...

    As for C14/C15 - On the original Espruino Board, C15 is broken out, and has no particular limitations on it, so I suspect the same is true here. But what about C14? Is it available without doing something to keep it from trying to drive a crystal that's not present?

  • But what gives me pause is that B0 is listed as a "USB" pin in the reference...

    That one's fine - I'll try and change the docs for it.


    I just tried this, and they seem to 'just work' without any extra code.

    The reason GPIO_PinRemapConfig is needed for the STM32F1 in the original Espruino board is that the F1 has a totally crazy way of deciding what function each pin has (there's a global set of bits). The F4 is way more sane, and has 'pin function' bits per pin. The second you use digitalRead/Write/pinMode/etc, Espruino sets those bits and automatically disables JTAG.


    That's a little more tricky - at bootup, Espruino tries to start a crystal oscillating using it. If it fails it disables it, so you can then use it for whatever you want (as long as whatever you want doesn't get upset by being prodded a bit at bootup).

    If you actually need to use it without the prodding, you'd have to make your own build. I believe the code that attempts to start the crystal is at the start of jshInit in jshardware.c. It's a bit convoluted because the crystal can take a few seconds to start, so it enables it and then checks what's happening a few seconds later in the SysTick timer.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

Espruino Pico and accessing additional pins

Posted by Avatar for DrAzzy @DrAzzy