Update 2079 -> 2081, XMEGA, I2C on twie problem

MDuprau · Joined: 13 Oct 2012 Posts: 30

Hello,

i update from 2079 to 2081, compile the project, start the firmware and get a problem on the second I2C bus.
One of the chip's from second I2C bus will not found anymore.

[first I2C]
open "twic" for binary as #5
config twic = 100000
i2cinit #5

[second I2C]
open "twie" for binary as #6
config twie = 100000
i2cinit #6

[2079]
<.1 i2c.1.scan=[&H68,&H98,&HA0,&HA8,&HE0]
<.1 i2c.2.scan=[&H20,&H30,&H68,&HA0]

[2081]
<.1 i2c.1.scan=[&H68,&H98,&HA0,&HA8,&HE0]
<.1 i2c.2.scan=[&H20,&H30,&HA0]

The "&H68" on the secod bus will not found

crosscheck with the firmware compiled with 2079 after the update, works, so the hardware is fine.

p.s. is this necessary on >= 2.0.7.9
$lib "xmega.lib"
$external _xmegafix_clear
$external _xmegafix_rol_r1014

BASCOM AVR 2.0.8.1 -> back to 2.0.7.9

Best Regards Mark

(BASCOM-AVR version : 2.0.8.1 )

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

I really hate these kind of postings.
Some problem is reported and then there is some sort of proof, but the code is just a fragment. it can not be checked since it can not be compiled as is. There is no info about the processor.
There is also a question missing about the problem. So what is this kind of post?

When you have a problem and want help you need to post an example that will demo the problem. And we need to be able to compiler without assumptions.

Then, you should not put other unrelated questions inside the post.
Just take some time for your posting.

And the BASCOM AVR 2.0.8.1 > back to 2.0.7.9 : What good is that information? does this mean you dont not care about the problem? So you post a problem but do not care since you installed an old version?
If you dont care we dont either.

MDuprau · Joined: 13 Oct 2012 Posts: 30

Hello,

sorry, but i cant post here a project that goes over more then 35.000 codelines.

The MCU is a XMEGA defined in "xm256a3udef.dat".

[code to open the I2C on "twic"]

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

- when posting code, please use code tags.
- I do not ask for complete code : i ask for the smallest possible code that will demo the problem. I do not ask for fragments which do not mean a thing without context.
- this forum is for older compilers which we do not support and for cases like this where i do not want to spend my time on because the lack of info. it is a good idea to rename this forum.

MDuprau · Joined: 13 Oct 2012 Posts: 30

Hello,

i make an update to highlight the code, but in this case it makes no different, without the hardware you cant check anything with my code.

All i can do is, to check this here and give you all information i have.

Firmware and Hardware runs without any problems on 2.0.7.9.
After the update to 2.0.8.1 a device on TWIE will not found, his "brother" on TWIC will be found.
A release compiled with 2.0.7.9, after the update with 2.0.8.1 and back to 2.0.7.9, same codebase, runs without problems.

Results from scan:
[2079]
<.1 i2c.1.scan=[&H68,&H98,&HA0,&HA8,&HE0]
<.1 i2c.2.scan=[&H20,&H30,&H68,&HA0]

[2081]
<.1 i2c.1.scan=[&H68,&H98,&HA0,&HA8,&HE0]
<.1 i2c.2.scan=[&H20,&H30,&HA0] ???

The Hexfile from 2.0.7.9 is 566181 bytes, from 2.0.8.1 is 566434 bytes

I doublecheck this now with both version on the same codebase, the 2.0.8.1 dint found the device.

Compare over the [_I2C] code segment in inside "xmega.lib" show your document changes for the "i2cstop" versions, but also changes on "_i2c_bus_state".
Next i will try it with the code segments from 2.0.7.9 inside the 2.0.8.1 "xmega.lib", "_i2c_bus_state" and/or "_i2c_stop".

Best Regards Mark

EDC · Joined: 26 Mar 2014 Posts: 971

Please do some tests Wink

Attach &H20 and &H30 device on the first line too.
Are &H68 visible on the first line then?
NO-> Try to configure I2cStop like Help provide. Maybe it will help.

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

the i2cstop command in 2079 is the same as in 2081 when none of the constants are defined.
The problem is that the internal xmega twi logic does not respond properly to a stop command in some cases. so in 2079 the stop command is done in a loop.
But this gave problems with some new xmega chips. So in 2080 a constant was added to control the behavior. The problem was that it broke compatibility with the previous version so in 2081 the behavior was like in 2079 and the 2 modes were made optional. if you check the 2079 and the 2081 you will see that.

while you can make all kind of experiments, it is best if you create a short sample program that will have the problem. there can be multitude of reasons why it will work different.

MDuprau · Joined: 13 Oct 2012 Posts: 30

first checks done
background information : the device scan on "twic" and "twie" is part of the initialisation, so for me each test takes some minutes.

BASCOM 2.0.8.1 GUI (restart and compile after each change, before change all files are origin) :
- with "xmega.lib" from 2.0.7.9 stuck on "twie" device scan, non of the devices will shown here, "twic" work fine
- with "xmega.lib" and "xm256A3Udef.dat" from 2.0.7.9 stuck on "twie" device scan, non of the devices will shown here, "twic" work fine
- with "xm256A3Udef.dat" from 2.0.7.9 "twie" device scan show all devices, except &H68, "twic" work fine
- with the complete [_I2C] section from 2.0.7.9 "xmega.lib" stuck on "twie" device scan, non of the devices will shown here, "twic" work fine
- with the [_I2C]_i2c_bus_state: section from 2.0.7.9 "xmega.lib" stuck on "twie" device scan, non of the devices will shown here, "twic" work fine
- with the [_I2C]_i2c_stop: section from 2.0.7.9 "xmega.lib" "twie" device scan show all devices, except &H68, "twic" work fine
- with "Const _TWI_STOP_1 = 1" "twie" device scan show all devices, except &H68, "twic" work fine
- with "Const _TWI_STOP_2 = 1" "twie" device scan show all devices, except &H68, "twic" work fine, stuck on the first access on the EEPROM on "twic"
- with non "Const _TWI_STOP_X = 1" "twie" device scan show all devices, except &H68, "twic" work fine

if i remove the incompatibilities from "_TWI_STOP_2", all the test cases points to a handling problem on "twie", non of the errors will shown on "twic".
Stuck on "twie" device scan or device not found on "twie" points to "twie" and its not inside the "xmega.lib" or "xm256A3Udef.dat".

Is there any other "code" that can "change" the handling from "twie" ?

@EDC its not possible to change the I2C devices from one I2C bus to an other, thats a finsh PCB layout, sorry

Best Regards Mark

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

these are nice tests but not needed. i still see no short sample we can test. so here is another question : the xmega i2c scanner from the help, will that show the problem for TWIE ?

MDuprau · Joined: 13 Oct 2012 Posts: 30

Hello,

the code is near the same, but split over some files :

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

do not bother with twic since that is working. can you confirm that this code has a problem ?

MDuprau · Joined: 13 Oct 2012 Posts: 30

Hello,

sorry, "debugtext" is in one of the other 700 files of this project.

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

I had a look at the output and the cause is a BUG in i2cstop : it loads the TWIC address instead of the (in this case) TWIE address.
I do not know yet how that is possible but that is next. At first glance no change was made to the code.

To workaround this add a sub to your code :

albertsm · Joined: 09 Apr 2004 Posts: 5921 Location: Holland

I am glad that you took time to supply the test code. Without it i could not have found the problem.
And apologies to you and all for the bug. I have many conditional code switches and one was wrong. This caused i2cstop to always take the i2cstop path, which results in the default i2cstop for xmega : twic.
This also means that i2cstop for twid,twie and twif will not work and need a similar workaround as posted earlier.

MDuprau · Joined: 13 Oct 2012 Posts: 30

Hello,

i can wait with the update to 2.0.8.1, to find out whats going on cant take so long.

Maybe a old crossfix from "xm256A3U.def" :

[2.0.7.9, CONFIG-TWIE:OPTION1 points to TWIC]