MRRA / PIN23 problem with on Explorerboard non 3.10 kernel

[PieterGit]

With recent 4.8 and 4.10+ kernels I get problems with accessing the TI-chip on an Explorer board

# reset_spi_serial.py
Traceback (most recent call last):
  File "/usr/local/bin/reset_spi_serial.py", line 6, in <module>
    exec(compile(open(__file__).read(), __file__, 'exec'))
  File "/root/src/915MHzEdisonExplorer_SW/spi_serial/scripts/reset_spi_serial.py", line 3, in <module>
    s = spi_serial.SpiSerial()
  File "/root/src/915MHzEdisonExplorer_SW/spi_serial/spi_serial/spi_serial.py", line 7, in __init__
    self.cs0 = m.Gpio(23)
  File "/usr/local/lib/python2.7/dist-packages/mraa.py", line 995, in __init__
    this = _mraa.new_Gpio(pin, owner, raw)
ValueError: Invalid GPIO pin specified

I thought it might be a kernel issue, but according to Andy Shev (kernel developper) it's a LibMRAA or Intel breakout/baseboard problem, see https://github.com/andy-shev/linux/issues/8

Questions: 1) Can you explain why pin 23 is used? The python source does not give me a clue. 2) Is there technical information available about how the Explorer board accesses the serial line of the TI CC1111 chip? 3) Will the newer version of the explorer board have support for linux 4.x kernels?

Because of this issue and because of issue https://github.com/EnhancedRadioDevices/915MHzEdisonExplorer/issues/16 I cannot use my Dexcom G4 (connected to USB OTG, with power via UART) and communicatie with the TI CC1111 on the Explorer board to a WW insulin pump.

[PieterGit]

I tested it with this distribution: https://github.com/atlury/Intel-Edison-OS-Images/releases and also manually upgraded to Linux 4.10rc's kernels. Both give the same errors accessing the TI-chip.

[mogar]

The explorer board uses a CC1110, not a CC1111. There are a few differences to be aware of there; mainly that the CC1110 doesn't have USB.

Pin 23 is the mraa equivalent for the reset pin. Take a look at the schematic and you'll see that the reset pin of the CC1110 is connected to the GP14 on the Edison. Edison pin-numbering is a bit arcane, but the upshot is that mraa addresses that pin as number 23.

For technical information of the CC1110 connections on the explorer board, take a look at the schematic: https://github.com/EnhancedRadioDevices/915MHzEdisonExplorer/blob/master/EdisonBlock_915MHz_fab/EdisonBlock_915MHz.pdf

That will show you what pins are connected where.

I'd say that the problems you're experiencing don't have anything to do with the hardware, and are instead software problems (potentially with mraa). Are you logging in as root? Mraa has some issues with non-root permissions.

[PieterGit]

I thougth it was a CC1111. I'm running mraa as root. I'll look at the schematic docs and will try to communicate with a newer kernel using GPIO without mraa and using https://pypi.python.org/pypi/gpio/0.2.0 this library to see if that works.

[PieterGit]

First attempt at https://github.com/scottleibrand/spi_serial/pull/1 I seem to be able to communicate with the CC1110 chip afacit (I get Version: subg_rfspy 0.8 back from mmtune).

I can't get pump model or mmtune to work yet. Any help would be appreciated so that libmraa can be ditched on 4.10+ kernels. Trying with 4.10rc4 kernel (64 bits).

[mogar]

Awesome stuff! It looks like you've managed to get your pump model back already, too.

It would be great to move away from libmraa in general. I'm pretty busy now, but I'm going to carve some time out early next month to look into that more.

[andy-shev]

@mogar I'm wondering if there is any place where I can find pre-soldered Explorer board. I can enable and test the latest U-Boot and Linux kernel on it.

[mogar]

Unfortunately, we're sold out. We haven't been keeping them in stock since the Edison went end-of-life.

[scottleibrand]

Since you posted, the Pi Zero 2 has come out, which is much faster and more power-efficient, removing most of the downsides of building an Explorer HAT based rig. There is still some testing to be done to figure out which images are needed etc., which someone is working on...

[andy-shev]

There is still some testing to be done to figure out which images are needed etc., which someone is working on...

Yeah, right... Meanwhile I am not looking for that solution.