[GreatFET] I2C FRAM read/write issue
Jacob Graves
jacob at greatscottgadgets.com
Mon Feb 1 19:42:50 EST 2021
Looks like you're running a release version that doesn't include the bug
fix that should fix your issue.
Information on how to install host tools or firmware or both can be
found here:
https://github.com/greatscottgadgets/greatfet/wiki/Getting-Started-with-Firmware-Development
Note that you may have to run the python commands as *python3*.
On 2/1/21 5:36 PM, Chuck McManis wrote:
> I see this:
> Host tools info:
> host module version: 2020.1.2
> pygreat module version: 2020.1.2
> python version: 3.6.9 (default, Oct 8 2020, 12:12:24)
>
> module path:
> /home/cmcmanis/.local/lib/python3.6/site-packages/greatfet
> command path:
> /home/cmcmanis/.local/lib/python3.6/site-packages/greatfet
> /commands
> gnuradio-companion block path:
> /home/cmcmanis/.local/lib/python3.6/site-
> packages/greatfet/gnuradio
>
> Not a commit hash, hmmm.
> --Chuck
>
>
> On Mon, Feb 1, 2021 at 4:22 PM Jacob Graves
> <jacob at greatscottgadgets.com <mailto:jacob at greatscottgadgets.com>> wrote:
>
> Host tool information can be found by running *$gf info -H *or *gf
> info -a*
>
> When installing code from git, the output of the above will look
> something like - *host module version:
> <**.dev-git.**git-commit-hash-**>*
>
> Can you run that and verify that the commit-hash matches the end
> chunk of one of the latest commits to master?
>
> On 2/1/21 5:08 PM, Chuck McManis wrote:
>> Nope this is the current version:
>>
>> cmcmanis at quarterhorse:greatfet$ gf i2c -a 0x20 -w 5 5 -v
>> Trying to find a GreatFET device...
>> GreatFET One found. (Serial number: 000057cc67e630770657)
>> Writing to address 0x20
>> Traceback (most recent call last):
>> File "/home/cmcmanis/.local/bin/greatfet_i2c", line 11, in <module>
>> sys.exit(main())
>> File
>> "/home/cmcmanis/.local/lib/python3.6/site-packages/greatfet/commands/greatfet_i2c.py",
>> line 48, in main
>> write(device, args.address[0], args.write, log_function)
>> File
>> "/home/cmcmanis/.local/lib/python3.6/site-packages/greatfet/commands/greatfet_i2c.py",
>> line 73, in write
>> log_function("I2C write status: %s" % hex(i2c_status))
>> TypeError: 'tuple' object cannot be interpreted as an integer
>> cmcmanis at quarterhorse:greatfet$ gf i2c -z
>> Working I2C address(es): (Address, RW bit, frequency)
>> 0x20 W [100000]
>> 0x20 R [100000]
>>
>> ******** W/R bit set at each valid address ********
>> 0 1 2 3 4 5 6 7 8 9 a b c d e f
>> 00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 20: WR -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> cmcmanis at quarterhorse:greatfet$
>>
>> The target is an i2c display, writing 5 to register 5 should
>> change the color of the text.
>>
>>
>> On Mon, Feb 1, 2021 at 3:44 PM Jacob Graves
>> <jacob at greatscottgadgets.com
>> <mailto:jacob at greatscottgadgets.com>> wrote:
>>
>> No snarkiness taken! Version/error messaging aside, when
>> using your first example, "*$gf i2c -a 0x50 -w 0x01 -v*" I'm
>> not able to reproduce the tuple->integer TypeError using
>> latest on my system. However, the *not subscript-able
>> TypeError* in your second example occurs because it is
>> missing an address argument.
>>
>> Does the second issue persist when you include an address to
>> write to?
>>
>> On 2/1/21 3:18 PM, Chuck McManis wrote:
>>> Note: the goal here is not to be snarky, its to be illustrative.
>>>
>>> FWIW, this problem :
>>>
>>> *TypeError: 'tuple' object cannot be interpreted as an
>>> integer. *
>>>
>>> with the 'i2c' option of the gf command present with GF and
>>> the latest firmware. It is pretty trivially reproducible.
>>> What is less clear is how this interacts with what ever
>>> version of 'gf' is installed. That is due in part because it
>>> is difficult to ascertain versioning information about the
>>> command (gf --version, gf --help, gf version are all
>>> non-options/non-commands) even looking at the source doesn't
>>> give you much to work with since it imports from a python
>>> module. Further, 'gf shell' provides no banner or
>>> announcement of version information which would help someone
>>> understand whether or not their version is "current" or
>>> could be improved by installing a new version.
>>>
>>> Using what I believe the current version of the firmware
>>> from the greatfet repo (I did a make and it claimed it
>>> installed but again, I can't easily verify which is run) I
>>> get a new error from the tuple one like this:
>>>
>>> cmcmanis at quarterhorse:greatfet$ gf i2c -w 0x20 5 5 -v
>>> Trying to find a GreatFET device...
>>> GreatFET One found. (Serial number: 000057cc67e630770657)
>>> Traceback (most recent call last):
>>> File "/home/cmcmanis/.local/bin/greatfet_i2c", line 11, in
>>> <module>
>>> sys.exit(main())
>>> File
>>> "/home/cmcmanis/.local/lib/python3.6/site-packages/greatfet/commands/greatfet_i2c.py",
>>> line 48, in main
>>> write(device, args.address[0], args.write, log_function)
>>> TypeError: 'NoneType' object is not subscriptable
>>> cmcmanis at quarterhorse:greatfet$
>>>
>>> Not exactly helpful.
>>> --Chuck
>>>
>>>
>>> On Mon, Feb 1, 2021 at 11:11 AM Jacob Graves
>>> <jacob at greatscottgadgets.com
>>> <mailto:jacob at greatscottgadgets.com>> wrote:
>>>
>>> This looks like there's something wrong with your write
>>> tool, not the
>>> hardware. Have you installed latest host/firmware code
>>> from master? You
>>> should be able to read/write to an incorrect address
>>> without error, it
>>> just won't do anything useful.
>>>
>>> On 1/27/21 1:00 PM, Michael Messuri wrote:
>>> >
>>> > I'm having an issue trying to read/write an I2C FRAM
>>> (Adafruit I2C
>>> > FRAM Breakout) and was hoping someone with more
>>> experience could help
>>> > me solve it the problem:
>>> >
>>> > When I issue the cmd: "gf i2c -z -v" the results
>>> come back that
>>> > address 0x50 is both read/writable (there is a WR in
>>> column 0) and
>>> > address 0x70 (with a W in column C) is writable.
>>> However, when I then
>>> > issue the cmd: "gf i2c -a 0x50 -w 0x01 -v" I get a
>>> traceback in file
>>> > greatfet_i2c.py line 73 with a TypeError: 'tuple'
>>> object cannot be
>>> > interpreted as an integer. Now if I try the same type
>>> of thing inside
>>> > the shell I see that I am not receiving any status
>>> results from the
>>> > i2c read or i2c write results.
>>> >
>>> > at this point I am a little unclear why the scan
>>> result would come
>>> > back as r/w at address 0x50 (which is default for the
>>> i2c fram) and
>>> > then any r/w command would fail.
>>> >
>>> > Thanks.
>>> >
>>> > -- Michael --
>>> > mmessuri at 4rsons.com <mailto:mmessuri at 4rsons.com>
>>> > _______________________________________________
>>> > GreatFET mailing list
>>> > GreatFET at greatscottgadgets.com
>>> <mailto:GreatFET at greatscottgadgets.com>
>>> > https://pairlist3.pair.net/mailman/listinfo/greatfet
>>> _______________________________________________
>>> GreatFET mailing list
>>> GreatFET at greatscottgadgets.com
>>> <mailto:GreatFET at greatscottgadgets.com>
>>> https://pairlist3.pair.net/mailman/listinfo/greatfet
>>>
> _______________________________________________
> GreatFET mailing list
> GreatFET at greatscottgadgets.com <mailto:GreatFET at greatscottgadgets.com>
> https://pairlist3.pair.net/mailman/listinfo/greatfet
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist3.pair.net/pipermail/greatfet/attachments/20210201/648e174f/attachment.html>
More information about the GreatFET
mailing list