I2C problems in SX/B 2.00.16 with use of the uM-FPU V2. But works in SX/B 1.51
Sens-a-Dat
Posts: 44
I am enclosing a SX48 program which simply uses two LEDs and the uM-FPU V2 math coprocessor. The LEDs are being used to help us determine where in the program we are having problems.
We have compiled the program in both the SX/B 2.00.16 and SX/B 1.51.03 compiler versions. And we are unable to have good I2C communications between the SX48 and the math coprocessor utilizing the 2.00.16 compiler.
In the programs we write, we check the returned acknak value from the I2C device to ensure communications is fine. This is where we are noticing wrong values under the new compiler.
To test the theory that the I2C compiled codes v2.00.16 may be the cause of the communication errors, we placed the assembly codes of the I2C commands which we compiled under v1.51.03 I2 into our larger program which was then compiled under 2.00.16. After doing this, the I2C communications with the uM-FPU v2 was fine once again.
Does anyone have any insight on how to remedy this under the newer compiler? Or is this a software issue for us?
Thank you,
Gary
We have compiled the program in both the SX/B 2.00.16 and SX/B 1.51.03 compiler versions. And we are unable to have good I2C communications between the SX48 and the math coprocessor utilizing the 2.00.16 compiler.
In the programs we write, we check the returned acknak value from the I2C device to ensure communications is fine. This is where we are noticing wrong values under the new compiler.
To test the theory that the I2C compiled codes v2.00.16 may be the cause of the communication errors, we placed the assembly codes of the I2C commands which we compiled under v1.51.03 I2 into our larger program which was then compiled under 2.00.16. After doing this, the I2C communications with the uM-FPU v2 was fine once again.
Does anyone have any insight on how to remedy this under the newer compiler? Or is this a software issue for us?
Thank you,
Gary
Comments
The I2C commands where changed to allow for clock-stretching, a rarely used feature in I2C. Maybe that is causing the problem.
I think I have a uM-FPU, but I'll have to find it.
P.S. You don't need to break your code into pages, the compiler handles that now (even 1.51.03).
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...
Post Edited (Bean (Hitt Consulting)) : 3/6/2009 7:27:53 PM GMT
Has this been resolved?
Also, according to this piece of compiled code:
1487 04BD 0CFE MOV FSR,#__TRISB ; I2CRecv SDA_Pin, i2cData, 1 04BE 0024 1488 04BF 005F MODE $0F 1489 04C0 0C08 MOV __PARAM2,#8 04C1 0029 1490 04C2 0440 CLRB IND.2 1491 04C3 0200 MOV !RB,IND ; clock low 04C4 0006 1492 04C5 0446 CLRB RB.2 1493 04C6 0C0A MOV __PARAM4,#10 04C7 002B 1494 04C8 02EB DJNZ __PARAM4,@$ 04C9 0012 0AC8 1495 04CB 0540 SETB IND.2 1496 04CC 0200 MOV !RB,IND ; clock high 04CD 0006 1497 04CE 0746 JNB RB.2,@$ ; wait for SCL input high 04CF 0012 0ACE 1498 04D1 0C0A MOV __PARAM4,#10 04D2 002B 1499 04D3 02EB DJNZ __PARAM4,@$ 04D4 0012 0AD3 1500 04D6 0368 RL __PARAM1 1501 04D7 0726 MOVB __PARAM1.0,RB.1 04D8 0408 0626 0508 1502 04DB 02E9 DJNZ __PARAM2,@$-25 04DC 0012 0AC2 1503 04DE 0440 CLRB IND.2 1504 04DF 0200 MOV !RB,IND 04E0 0006 1505 04E1 0446 CLRB RB.2 1506 04E2 0C0A MOV __PARAM4,#10 04E3 002B 1507 04E4 02EB DJNZ __PARAM4,@$ 04E5 0012 0AE4 1508 04E7 0520 SETB IND.1 1509 04E8 0200 MOV !RB,IND 04E9 0006 1510 04EA 0C0A MOV __PARAM4,#10 04EB 002B 1511 04EC 02EB DJNZ __PARAM4,@$ 04ED 0012 0AEC 1512 04EF 0540 SETB IND.2 1513 04F0 0200 MOV !RB,IND 04F1 0006 1514 04F2 0746 JNB RB.2,@$ 04F3 0012 0AF2 1515 04F5 0C0A MOV __PARAM4,#10 04F6 002B 1516 04F7 02EB DJNZ __PARAM4,@$ 04F8 0012 0AF7 1517 04FA 0440 CLRB IND.2 1518 04FB 0200 MOV !RB,IND 04FC 0006 1519 04FD 0446 CLRB RB.2 1520 04FE 0C0A MOV __PARAM4,#10 04FF 002B 1521 0500 02EB DJNZ __PARAM4,@$ 0501 0012 0B00 1522 0503 0520 SETB IND.1 1523 0504 0200 MOV !RB,IND 0505 0006 1524 0506 0C0A MOV __PARAM4,#10 0507 002B 1525 0508 02EB DJNZ __PARAM4,@$ 0509 0012 0B08 1526 050B 0018 BANK $00 1527 050C 0208 MOV i2cData,__PARAM1 050D 003Eit appears the SCL signal clocks at 200kHz (50 cycles low,·50 cycles high·@20MHz).
Is there an option to force 100kHz (or even slower)?
If a I2C device misses the clockpulse due to high speed,
maybe the line
· 1497· 04CE· 0746······· JNB RB.2,@$·················· ; wait for SCL·input high
blocks program execution (wait forever)
Edit: just remembered I2CSPEED directive.
I2CSPEED 0.5 forces 100kHz
regards peter
Post Edited (Peter Verkaik) : 6/17/2009 11:06:24 AM GMT
Do you have the uM-FPU chip ? Can you confirm that it doesn't work ?
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...
·
(I still wait to get the exact eeprom that is used) and most of
the time the program stalls. So I will try I2CSPEED first
once I hear what eeprom is used and checked its datasheet
regarding timing.
The code appears to use a 256byte eeprom. Not sure what happens
if it turns out the actual eeprom has higher capacity (2-byte address).
I do have a v3.1 umFPU, but that won't do as a test (different cpu).
regards peter
Be sure to let me know what the cause of the "stall" is, so I can address it.
Like I said earlier, the I2C code was changed. But if it is causing problems I will change it back. Clock stretching is not a commonly used feature.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...
·
I have had no problems with I2C in 2.x and that's with a wide variety of devices, some use clock-stretching, some do not. The only time I get stalls is when the peripheral "locks" up while the master is waiting for the clock to be released. In the case of the Stamp, there is a master "timeout" on I2C commands so the program moves on if the clock is not released. This would be a nice addition to SX/B, but the WDT can also be used in this context.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
JNB SCLPIN,$
It is easy to turn this into a loop:
MOV __PARAM4,#I2CTIMEOUT
:loop
· JB SCLPIN,@:loopend
· DJNZ [url=mailto:__PARAM4.@:loop]__PARAM4.@:loop[/url]
:loopend
Regarding my debugging: the I2C eeprom used is an Atmel AT24C01B
operating at 5 Volt. The datasheet specifies 1MHz clock maximum.
This eeprom is not likely to be the cause for my stalling program.
When I do find the cause I will report it here if there is an I2C issue.
regards peter
Deja vu. Had this exact same discussion w/Bean et al some months ago. I used a similar code example for timeout as what you posted. I pointed out that many, many peripherals are essentially micro based, and in my experience, I have yet to find a micro based peripheral with hardware I2C that does not use clock stretching.
However, there is not necessarily enough __PARAM registers to loop for timeout on clock stretching, so it may not be quite that simple. The reason is that depending on the I2CSPEED setting and the clock speed of the SX, more params get used for nested loops to delay time on the IC signals.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
The delayloops for I2CSPEED are all by themselves and so
the used __Param become free once a delayloop finishes.
For the clockstretching, assume 2 bytes, __Param4 and __Param5
CLR __PARAM4
CLR __PARAM5
:loop
JB SCLPIN,@:loopend······ '2cycles to stay in loop
DJNZ __PARAM5,@:loop··· '4cycles to stay in loop, 2 cycles to exit param5 loop
DJNZ __PARAM4,@:loop·· '4 cycles to stay in loop
:loopend
Waitloopcycles max = (256*6 + 2)*256 = 393728
@50MHz that equals 393728/50MHz sec = 7.87 msec
That really should be enough even for the slowest I2C device.
In reality the maximum waittime may even be longer due to a running isr.
regards peter