P14 signal is on P13 ! Sipy Pin map is wrong

  • Hi,
    I had the sipy-pinout.pdf from https://docs.pycom.io/datasheets/development/sipy

    I wrote a code to read temperature on SPI on P14 (on my expansion board, I consider, despite the mess of its numbering method, that it is facing the P14 of the Sipy Module, so the second pin starting bottom right, led on top):

    # this uses the SPI default pins for CLK, MISO (``P10``, ``P14``)
    spi = SPI(0, mode=SPI.MASTER, baudrate=10000, polarity=0, phase=1, bits=16, firstbit=SPI.MSB,pins=('P10','P11','P14'))

    and I read the P14 :

     data = spi.read(2)

    As in the console I had "0 0" as answers, I put an oscilloscope on the P14 (and on the others also) and I get the following signal :

    0_1535436828948_IMG_011.jpg that is similar to a good data signal.
    And after some tests , I decide to change the input from the second position to the first (so from "P14" to the pin named "P13") (count from bottom right) ,and surprised to get on my console some data !!!!!
    6 96
    6 112
    6 96
    6 112

    So I deduce that there is a problem in the documentation : SPI read P14 on P13 pin , and not buy default because I told him explicitly in initialisation, or the map is not correct , or ... there is a big problem somewhere else !!!

  • @prx I submitted a Pull Request to Pycom, and they may include it in the next release. This is not a drastic change: just two lines in a configuration file.
    Mint Xfce is under the hood identical to Xubuntu. It is more a look & feel issue. Before Mint, I had also Xubuntu installed.

  • @robert-hh
    I "recycle" also old windows machine with Xubuntu: lighter that Ubuntu;
    What is the advantage of Mint ? lighter again ?

    Didi you propagate the upgrade we tested for P13/14 pins on the normal branch for next upgrades of Sipy?

  • @prx I use that version or Mint19 on old laptops, giving them a second life.

  • @robert-hh
    sorry for the delay : my machine is a 386 in Xubuntu 14-04 kernel 3.13.0-98-generic #145-Ubuntu / runs well.
    I loaded (link of the online doc) & installed with Gdebi: pycom-fwtool-1.15.1-trusty-i386.deb the 1st time. The version 1.15.2b by the dev link provided in the pycom-fwtool 1.15.1
    best regards

  • @prx Glad you succeeded. I tried the updater 1.15.1 on a mint 19, 32 bit, boot CD version, using the generic Linux package of the updater, and it shows the file name.

    OK. So I'll make a PR for that change. I'm not in Pycom, so I have to ask for changes too.
    Which version of the updater and version of the OS did you choose? It might be an option to raise an issue.
    Edit: the command line version is anyhow interesting because of it's rich set of functions for device management.

  • @robert-hh thanks !
    I start in a terminal :
    $ pycom-fwtool-cli -p /dev/ttyACM0 -s 115200 flash -t Sipy-1.18.1.r1.tar.gz
    Running in PIC mode

    runs well ! (why ?) Flash operation successful.

    --- test of pins for SPI command :

    • P18 : ok
    • P17: ok
    • P16: ok
    • P15 : ok
    • P14: ok
    • P13: ok
      Good job my dear ! I let you publish this new release !
      thanks a lot!

  • @prx When I open it here, it works fine, and I see the file. A 32bit/64bit problem would only affect the relation between the updater too and the PC's OS. The file itself should not be different.I have no 32 bit linux here at the moment, otherwise I would test it. Did you try using the command line version:
    pycom-fwtool-cli -p /dev/ttyUSB0 -s 115200 flash -t <tar_file_name>

  • @robert-hh
    of course on your new 64b machine, you crossed-compiled for a 32b microcontroller as Sipy ;-) ?
    I think of that because I have as I say a 32b Linux , so if you can read and i cann't at this stage of the flash, it is because your bin files are in 64b, and I think the suggestion to the pycom-fwtool developper to integrate a 32b format check in bin files is to be made, .. am I wrong ?

  • @robert-hh
    Hi, In a terminal , I can do a extract and repack with tar zxvf or zcvf. this is not that. The size is 1659477 bytes, same.
    I installed the dev version (pycom-fwtool-1.15.2.b1-trusty-i386) and I can "continue , I selected FatFS and after LittleFS FS option and the immediate answer is "the upgrade failed because the firmware file cannot be read" "unknown error", you can "continue" but nothing appends , only restarts come to the beginning.

    See the screen copy AFTER I select the Sipy-1.18.1.r1.tar.gz file : nothing is written in the "file field". normal ?
    0_1536091091339_Screenshot - 04092018 - 21:57:51.png


  • @prx said in P14 signal is on P13 ! Sipy Pin map is wrong:

    not prefer to block my SiPy.

    Using OTA will not block the device. Just another OTA will fix it.

    Where that is coming from ?

    No clue. As said, I can run the update here on my debian 8 system. You could try to unpack the files and pack them again using you tar and gzip tools. And you could try to move to pyupgrade 1.15.2. The downloaded file should be 1659477 bytes long.

  • @robert-hh
    Yes the "continue" button is greyed out - yes of course I have tar and gzip available.
    For the other solution, I do no not master that and not prefer to block my SiPy.
    Where that is coming from ? The soft pack missing one file ? or the fact that I have already the same version number installed and you should upgrade the version number ?

  • @prx How does "cannot continue" look like. is the continue button greyed out?
    If it is linux, ensure that tar and gzip are available.
    If the tool tells you, that the upload is going, but not further action, then the device might not be in boot mode. You can enforce that by connecting P2 to GND and push reset.

    Last not least you can still do an OTA update by ftp. Unpack the tar.gz file, store appimg.bin into /flash/sys using ftp and reboot. There's a hiccup in the firmware when mixing USB and OTA updates about which image to boot, but that might catch you on the next USB update, which then will not get active.

  • @robert-hh
    I do select the .tar.gz file but once I do that I cannot continue.

  • @prx You do not have to upack the tar.gz file. The pycom-fwtool will do that itself. Just specify the .tar.gz file as filename. I tried that with using pyupdate 1.15.2 on Linux.
    Since I uploaded that to a fipy, the image would not run, but the upload worked.

  • @robert-hh I am on firmware upgrade tool 1.15.1 (stable) , the one with which I upgraded my Sipy to v1.18.1.r1.
    I have got your file Sipy-1.18.1.r1.tar.gz from your site, I extracted. The problem is that the firmware upgrade tool seems to expect a different file format ("flash from local file" option ) from .tar.gz or extracted files (appimg.bin, bootloader.bin, etc..), he does not select the file : I cannot got further. How should I pack the file to be selected as a "firmware file"? sorry, this is may be a basic question.

  • @prx I have uploaded a Build with the change pin mapping at https://github.com/robert-hh/Shared-Stuff
    You can simply download the file, and using the Linux firmware upgrade tool, use the option: "flash from local file"

  • @robert-hh
    I think the problem is in "spi" function. Yes send me a change pack and tell me how to implement it ; I am on Linux and use "Pycom Firmware tool" - I will test.

  • @prx The latest release did not change the PIN configuration file. That is unchanged since May 2017. Since I do not have a SiPy, i cannot verify whether a change to the configuration file cures the problem. I only could try to replicate the issue with one of my other devices. Or I could build a changed package to be tested by you.

  • @robert-hh
    I upgraded in firmware to v1.18.1.r1.
    I retest by spi command all the pins up to P18 :

    initial # of the map | name in program

    • P13 | P14 : error in firmware probably
    • P14 | not found !!
    • P15 | P15
    • P16 | P16
    • P17 | P17
    • P18 | P18


Log in to reply

Pycom on Twitter