HI2CSETUP error on Address=0

Simmicht

Senior Member
Is there a bug or restriction in the HI2CSetup command that means address $00 cant be used? When I use $00 the code seems to reset.

I am trying to use I2C communication to the AS3935 Franklin Lightning module. In the code below, when I set the address=0 for the I2C communication, the code resets and produces the following

Code:
OK .
OK .
OK .
OK .
OK .
If I change the address in the HI2CSETUP to any other number but 0 then I get the following ...

Code:
OK .
ok
tco=255
tco=255
f=0
f=0
f=0

Code:
#picaxe 28x2
#terminal 19200
#SLOT 0
#no_data
#no_table


setfreq EM16


pause 1000
sertxd("OK .",cr,lf)
pause 100





hi2csetup i2cmaster, $00, i2cfast_16, i2cword 'address is zero

pause 100

sertxd("ok",cr,lf)


hi2cin $00, (B0) 'read tuning  cap value
sertxd("tco=",#b0,cr,lf)


hi2cout $3C, ($96) ; Sets all registers in default mode
hi2cout $3D, ($96) ; Calibrates automatically the internal RC Oscillators



hi2cout $03, (%00000000) ; set freq div to 16 for tuning
hi2cout $08, (%10000000) ; set LCO to out on INT

pause 100

hi2cin $00,(B0) 'read tuning  cap value
sertxd("tco=",#b0,cr,lf)




do
    count b.0 , 1000 ,w0

    sertxd("f=",#W0,cr,lf)
    pause 4000

loop
example Arduino code which i assume works.
Code:
#define ADDR 0x00                   //chip i2c address

From the datasheet for the AS3935 inthe section on the I2C addressing. The Break-out-board has the ADD0 and ADD1 to GND.
An I²C slave interface is implemented for read/write access to the internal registers and to send direct commands. To enable the I²C as interface,
the Select Interface pin has to be set to the positive voltage supply (SI=VDD). The I2CL is the clock bus, while the I2CD is the data bus. An
external pull-up resistor on the I2CL pin is needed.
The device addresses for the AS3935 in read or write mode are defined by:
0-0-0-0-0-a1-a0-0: write mode device address (DW)
0-0-0-0-0-a1-a0-1: read mode device address (DR)
Where a0 and a1 are defined by the pins 5 (ADD0) and 6 (ADD1).
 

Technical

Technical Support
Staff member
O is a reserved value under the i2c protocol (general address) and shouldn't be used.
So set a0 or a1 to 1 on your hardware.
 

Armp

Senior Member
Short version - as you're using the X2 parts just use any nonzero address in hi2csetup, then do your first read or write using the newslave option - with 0 for the new address.

so your code becomes:

Code:
........

hi2csetup i2cmaster, [COLOR="#0000FF"]$39[/COLOR], i2cfast_16, i2cword   ' any non zero address 

pause 100

sertxd("ok",cr,lf)

hi2cin [COLOR="#0000FF"][0],[/COLOR]$00, (B0) 'read tuning  cap value

........
 

Technical

Technical Support
Staff member
Armp - that works around the PIC silicon module issue described above by starting the i2c module with non-zero in SSPADD. However it is not reliable, as soon as the SSPADD goes to 0 then issues with the clocking can arise.
There quite simply is not any fix on the 14K22 (20X2) as Microchip have identified it as a silicon level issue. The PICAXE firmware does absolutely nothing different with address 0 than to any other slave address, the reason it doesn't work is due to the silicon issue.

The OP should simply tie A1 and A0 pins high and the whole problem then goes away.
 

Armp

Senior Member
Armp - that works around the PIC silicon module issue described above by starting the i2c module with non-zero in SSPADD. However it is not reliable, as soon as the SSPADD goes to 0 then issues with the clocking can arise.
All I can say is that there are many of us using Peter Anderson's code for IR thermometers have been using his 'work around' successfully for a long time. I would agree that the special addresses should not be used - if you have a choice.
 

westaust55

Moderator
Ideally and hopefully simmicht can trace the circuit on the breakout board and disconnect both ADD0 and ADD1 pins from ground and connect instead to Vcc.


An interesting chip - could have done with one on Thurs night here in Perth WA as we have a major lightning storm directly overhead at the "castle" for quite a while.
 
Last edited:

Buzby

Senior Member
...we have a major lightning storm directly overhead ...
I don't think the AS3935 is actually designed to accept the lightning strike directly on one of it's pins.

In these circumstances I think looking at the smoking remains of your TV antenna will give a fairly accurate estimate of the distance to the strike.

Cheers,

Tipsy
 

Simmicht

Senior Member
looking at the BoB, it is so tiny, and the circuit traces that tie A1 and A0 to GND go back under the tiny chip....

http://wiki.tautic.com/Category:AS3935_Lightning_Sensor_Dev_Board

the schematic for the BoB is here
https://s3.amazonaws.com/tautic1/public/Product+Documentation/AS3935/AS3935+Schematic+and+Mechanical.pdf
so short of drilling fron the back to cut the tracks, how esle can i disconnect A0 or A1 from the GND?

Maybe just use SPI .... bit banged on different pins of the 28X2.
I have other I2C devices in the project, a BMP085 barometeric pressure sensor, a MAG3110 magnetometer and the Lipo Fuel Cell chip.
 

Buzby

Senior Member
Although not a neat solution, you could write your own bit-banged I2C. This will let you communicate with slave address $00.
 

westaust55

Moderator
looking at the BoB, it is so tiny, and the circuit traces that tie A1 and A0 to GND go back under the tiny chip....

http://wiki.tautic.com/Category:AS3935_Lightning_Sensor_Dev_Board
Are you really sure? Try a magnifying glass top side before resorting to more drastic measures.
When I blow up the image on th Tautic website it appears the address pin signal lines and the Gnd pin line are all on the top running away perpendicular to the chip.
See attached blown up (ah, read magnified ;) ) image

EDIT: Looking again at the traces image, yes, they do go under the IC as well :-(


EDIT2: Think about it further I would contact Tautic and flag the error of their board design highlighting that it has given you grief and would give any PICAXE chip user and many Micro PIC microcontroller users grief as i2c slave address $00, $01 and $02 are not available (per the extract above by Technical).
Ask them for a solution/resolution that will enable you to overcome thier design limitation using the microcontroller as already available to you.
 

Attachments

Last edited:

hippy

Ex-Staff (retired)
so short of drilling fron the back to cut the tracks, how esle can i disconnect A0 or A1 from the GND?
It will take the right equipment and a steady hand but you might be able to unsolder the legs from the pads, lift them up, then use jumper wire to connect to +V.

It would be best to make both pins high as that at least gives the device a 'Reserved for future purposes' address or there may be problems on an I2C bus which has other I2C devices attached.

It is IMO quite ridiculous to design any I2C device with a device address that is contrary to the use of such an address in the official I2C specification. 7-bit address ranges, 0000xxx and 1111xxx, have specifically defined uses, particular expected behaviours, or are reserved use, so should not be used as normal 7-bit device addresses.
 

Armp

Senior Member
I have other I2C devices in the project, a BMP085 barometeric pressure sensor, a MAG3110 magnetometer and the Lipo Fuel Cell chip.
Have you TRIED the Pete Anderson workaround? It may work for you - it does for me.
The silicon errata referenced by Technical is for the 20X2, which I, and others, use without problem.
www.instructables.com/id/A-PICAXE-Infrared-logging-Thermometer/
You're using the 28X2 which does not have the I2C silicon problem anyway AFAIK.
http://ww1.microchip.com/downloads/en/DeviceDoc/80498B.pdf

Edit: Oops - as you're planning to use other I2C devices on the same net you can't use 0 anyway. The General Call address will probably cause them all to respond!
 
Last edited:

westaust55

Moderator
From the PCB track work image in the datasheet, it appears that the address lines only come out from the pins and are not connected to the ground plane under the chip.
http://www.embeddedadventures.com/datasheets/MOD-1016_hw_v2_doc_v1.pdf
That may provide a better option for some fine scalpel work to segregate the adress pins and re on e t to ground.

Really like the way they add i2c pull-up but no bridges to isolate so you have to remove the SMD resistors if you have i2c pl-up elsewhere in your project.
 

westaust55

Moderator
In short - Yes

I2c address is a global/general broadcast address and under the PICAXE i2c commands per the manual should be avoided.
There was a recent thread on the PICAXE forum where a particular module was locked to slave address 0 by the module designer and a way around this was identified.

In the first instance look to avoiding slave address $0

Refer PICAXE Manual 2 page 76

Under the HI2CSETUP command
Some special i2c address (0, %1111xxxx, %000xxxx) have special meanings under the i2c protocol and so are not recommended as they may cause unexpected behaviour on third party devices.

EDIT:

Ooops,, accessing via iPhone did not see all posts and page 2. (it earlier today looked like a new question.)

However good to see the module supplier is now going to provide a selectable addressing mechanism.
 
Last edited:
Top