[GreatFET] I2C FRAM read/write issue

Jacob Graves jacob at greatscottgadgets.com
Mon Feb 1 19:22:11 EST 2021


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
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist3.pair.net/pipermail/greatfet/attachments/20210201/12d919fa/attachment-0001.html>


More information about the GreatFET mailing list