Coming Soon: Teensy-LC (low cost Teensy)

Status
Not open for further replies.
Is there any code available I could run on a Teensy 2.0, so when I connect it to a Teensy-LC running this code, I can reproduce the lockup?

Actually, before that... have you tried 1.23-beta1 yet?

https://forum.pjrc.com/threads/28499-Teensyduino-1-23-Beta-1-Available

Quite a bit of work was done to the Wire library to prevent lockups with using the Lidar Lite, which does all sorts of wrong I2C stuff. Maybe 1.23-beta1 will solve the problems you're seeing? It's easy to try.

I do not have the Beta, I will try it. Should I switch to the i2c_t3 library?

Matt
 
That'd be worth a try too.

If the lockups still happen with 1.23-beta1, please try to give me some way to reproduce the problem.
 
That'd be worth a try too.

If the lockups still happen with 1.23-beta1, please try to give me some way to reproduce the problem.

I loaded up the new Beta, and there is no difference. I took a snapshot of the display of the o-scope, maybe that will help?

I will try to create a transmitter with the Teensy2.0 to see if I can make it repeatable for you, but that will take a day or so.

Matt TeensyLC.jpg
 
I loaded up the new Beta, and there is no difference. I took a snapshot of the display of the o-scope, maybe that will help?

I will try to create a transmitter with the Teensy2.0 to see if I can make it repeatable for you, but that will take a day or so.

MattView attachment 4177

You are trying to setup a Slave device to respond to a General Call request? Is that right?

GC requires special settings (GCAEN set in I2Cx_C2). I don't think GC is supported in the current libraries. I've never tested it out anyway. It may be as simple as enabling that bit. If not you'll need to wait for someone to dig into the code and figure out how to support it (IIRC, GC has specific protocol format).

You can try enabling that bit in your setup code:
Code:
Wire.begin(0x??);        // pick a "real" Slave address, not 0x00
I2C0_C2 |= I2C_C2_GCAEN; // set GC addr enable

See if you get anywhere with that.
 
You are trying to setup a Slave device to respond to a General Call request? Is that right?

GC requires special settings (GCAEN set in I2Cx_C2). I don't think GC is supported in the current libraries. I've never tested it out anyway. It may be as simple as enabling that bit. If not you'll need to wait for someone to dig into the code and figure out how to support it (IIRC, GC has specific protocol format).

You can try enabling that bit in your setup code:
Code:
Wire.begin(0x??);        // pick a "real" Slave address, not 0x00
I2C0_C2 |= I2C_C2_GCAEN; // set GC addr enable

See if you get anywhere with that.

Indeed, I am trying to receive data sent out as a general call on the bus.

I have looked over the code in the Wire library and the twi, and it appears that the AVR implementation will utilize an address of 0x0 as a general call. If I understand what you are saying, that not the case with the Cortex and it's implementation. I have looked over the code in the Teensy areas and I do not see a spot where that bit is set anywhere, so this may be the answer, but I have to wait to test until tonight.

Matt
 
Oh, I had no idea you were trying to use general call addressing! That probably doesn't work.

If you have any test code on the Teensy 2.0 side, I'll give it a try here and see if I can improve the code in the Teensy-LC side.
 
Well,

I tried setting the GC bit in the register and that does not seem to work. Does anyone have the information sheet for doing IC2 on the MKL26Z64? I think that the library is just not letting the master know there is a slave on the bus interested in the data being sent.

Matt
 
Well,

I tried setting the GC bit in the register and that does not seem to work. Does anyone have the information sheet for doing IC2 on the MKL26Z64? I think that the library is just not letting the master know there is a slave on the bus interested in the data being sent.

Matt

I just did a test, enabling the GCAEN bit in C2 made a Slave respond to address 0x00. I also verified that bit specifically enables 0x00 address even when A1 and RA are both non-zero.

Attached is example code (using i2c_t3 example sketches). The Master code is the provided example with target Slave address set to 0x00, and the Slave code is the provided Slave-range example with GCAEN bit set as noted above.

View attachment gc_test_example.zip

If you load the sketches into two T3 (or LC) devices (external pullups required), and put a serial monitor on the Slave, then touching pin12 to GND on the Master device will send a burst of traffic to address 0x00, and the Slave will dump it's output to the monitor.

I get the following:
Code:
WRITE to Slave 0x0 at MemAddr: 0  Data: 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 
WRITE to Slave 0x0 at MemAddr: 32  Data: 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 
WRITE to Slave 0x0 at MemAddr: 64  Data: 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 
WRITE to Slave 0x0 at MemAddr: 96  Data: 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 
WRITE to Slave 0x0 at MemAddr: 128  Data: 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 
WRITE to Slave 0x0 at MemAddr: 160  Data: 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 
WRITE to Slave 0x0 at MemAddr: 192  Data: 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 
WRITE to Slave 0x0 at MemAddr: 224  Data: 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
READ from Slave 0x0 at MemAddr: 0
READ from Slave 0x0 at MemAddr: 32
READ from Slave 0x0 at MemAddr: 64
READ from Slave 0x0 at MemAddr: 96
READ from Slave 0x0 at MemAddr: 128
READ from Slave 0x0 at MemAddr: 160
READ from Slave 0x0 at MemAddr: 192
READ from Slave 0x0 at MemAddr: 224

This appears to be working fine, perhaps there is something else wrong.
 
Wow,

Thanks for this! After I made my post, I actually created a master that transmitted my data to the slave and I found, as you did, that setting the bit did work to receive the general call.

When I connect it to the real device, however, it still does not work. I beleive the real device must be behaving badly and locking up the slave. I say this because I have to use the WSWire library on the Teensy 2.0 to get it to receive correctly. The WSWire includes code to reset the slave when it appears that the device is locked in a state.

I will try to make the same mods to the Wire lib that Paul supplies for the TeensyLC and see if that works.

Also thanks for the example code using i2c_t3, I will switch to that first to make sure using that does not solve the problem.

Again, many thanks!

Matt
 
What is this real device that behaves badly? It's a commercial product which I could buy online somewhere?

It is the Spectra module from Hitec. It is part of the 2.4 GHz RC Airplane radio control system that they sell. It is all AVR based, and involves a module that plugs into the back of an RC Radio and a receiver that sits in the aircraft. The "Receiver" is actually a transmitter too, transmitting telemetry back to the Spectra Module in your radio. The telemetry data include data bout the battery level and a bunch of data collected using additional sensors and things in the aircraft (if you purchase them). The Spectra module has a port that allows you to receive this telemetry data over I2C and that is what I am reading.

Here is a post I made about using the Teensy 2.0 and a Bluetooth SPP module to get at the data and send it on to my App running on an Android device, it includes some pictures too. http://mcsarge.blogspot.com/2015/04/spectra-module-to-bluetooth-link-for-rc.html

Matt
 
Wow,

Thanks for this! After I made my post, I actually created a master that transmitted my data to the slave and I found, as you did, that setting the bit did work to receive the general call.

When I connect it to the real device, however, it still does not work. I beleive the real device must be behaving badly and locking up the slave. I say this because I have to use the WSWire library on the Teensy 2.0 to get it to receive correctly. The WSWire includes code to reset the slave when it appears that the device is locked in a state.

I will try to make the same mods to the Wire lib that Paul supplies for the TeensyLC and see if that works.

Also thanks for the example code using i2c_t3, I will switch to that first to make sure using that does not solve the problem.

Again, many thanks!

Matt

Well,

I looked at the code and it appears that the code for the Teensy does not use the twi code and that makes sense really. But I think it will take me some time to figure out where a similar lock up is happening in the TeensyLC code, if it is happening. I will post more if I am able to figure it out.

Matt
 
All,

Is it possible that this library is not working because it does not handle "repeated starts"? I know that this is sometimes an issue. I can not seem to figure out why it is not working, and it looks like I will have to give up using the Teensy LC for this project, though it appears to be the best in price and performance.

Any additional help would be appreciated.

Matt
 
All,

Is it possible that this library is not working because it does not handle "repeated starts"? I know that this is sometimes an issue. I can not seem to figure out why it is not working, and it looks like I will have to give up using the Teensy LC for this project, though it appears to be the best in price and performance.

Any additional help would be appreciated.
Matt

There is not much to go on. Nobody has the device you are working with, so you'll need to post some I2C traffic.
 
What is the best way to collect that traffic? I have a Bus Pirate, would that work?

Matt

Anything that can describe what's going on with the traffic. Scope shots, logic analyzer, bus pirate, all those should give some idea of the traffic. Specifically something showing traffic that is working correctly versus whatever the LC is doing (eg. does the part ACK the GC call, if so does the following traffic also get ACK'd). Logic analyzer is probably best if you have one. Bus pirate might obscure issues with timing or traffic it doesn't understand, not sure. Better than nothing though.
 
Anything that can describe what's going on with the traffic. Scope shots, logic analyzer, bus pirate, all those should give some idea of the traffic. Specifically something showing traffic that is working correctly versus whatever the LC is doing (eg. does the part ACK the GC call, if so does the following traffic also get ACK'd). Logic analyzer is probably best if you have one. Bus pirate might obscure issues with timing or traffic it doesn't understand, not sure. Better than nothing though.

I have the Diligent O'Scope and Logic Analyzer so I will fire that up and see if I can get a copy of what happens when working correctly and not so correctly. I can say that when the LC is hooked up I can see the master sending out the GC, and the LC looks like it is responding, but then nothing happens after that.

I will get a o'scope display of it running correctly later tonight and will try to get a logic analyzer working on it too.

OScope_Display_TeensyLC.jpg
 
Last edited:
OK, I have some pictures:

Simple setup: Teensy 2.0 with 1.5K external pull up resistors on pin D0 and D1 with those connected to the device. Successfully reading data sent by the master:
Teensy20_Success.jpg

Similar setup with the external pull ups on pins 18 and 19 of the TeensyLC; Not reading data (I also tried 5.1K pullups and got the same results):
TeensyLC_Fail.jpg

This setup is using the Teensy 2.0 as a master, sending out simulated data to the Teensy LC, same pull up resistors:
Teensy20_Master_to_TeensyLC_Slave.jpg

Here is the data that the Teensy 2.0 is receiving: First number is length, then each byte is printed with a ":" between and an [EOM] for end of message.
Code:
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:3F:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:3F:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:3F:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:AF:0:2D:1:40:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
21:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:[EOM]
 
I was also able to get the Logic Analyzer working for the data coming to the Teensy 2.0. Here is a shot of that screen when receiving a packet.

Logic Anal Teensy20.jpg
 
Similar setup with the external pull ups on pins 18 and 19 of the TeensyLC; Not reading data (I also tried 5.1K pullups and got the same results):
View attachment 4223

On plot2 I noticed a couple things. Assuming the Master is trying to drive identical signals as that in plot1, the LC appears to be slightly stretching the clock (plot1 byte transfer is ~58us, versus ~74us on plot2). That in itself is a little curious, but the Master seems to handle it.

But my guess is that somehow the Master device is thinking it lost arbitration. The reason I'm thinking this is due to how it terminates the signal in plot2. Even though an ACK bit is given by the LC, both SDA and SCL just jump high in a somewhat uncoordinated manner. This might be it trying to release the bus to the other apparent Master. It is certainly not a STOP signal as would be the case with a NAK.

It might be the large pulse between clocks 8 and 9 which is not evident in plot1. Maybe it doesn't like the SDA handover to the Slave. I don't see any apparent problem with the signaling, it appears to follow spec, but maybe the glitch is large and fast enough to cause some unseen problem.

An idea might be to try and suppress the glitch between clocks 8 and 9 by slowing the SDA line down. Maybe try a slower pullup on SDA only. Say 10k or 15k on SDA and 1.5k on SCL. Just a guess.

-------------
The clocks are somewhat odd, plot 1 looks closer to 200kHz, and plots 2/3 look closer to 100kHz. It's not clock stretching (typically only on 9th clock). I'm not sure why the Master would have inconsistent SCL.
 
Last edited:
On plot2 I noticed a couple things. Assuming the Master is trying to drive identical signals as that in plot1, the LC appears to be slightly stretching the clock (plot1 byte transfer is ~58us, versus ~74us on plot2). That in itself is a little curious, but the Master seems to handle it.

But my guess is that somehow the Master device is thinking it lost arbitration. The reason I'm thinking this is due to how it terminates the signal in plot2. Even though an ACK bit is given by the LC, both SDA and SCL just jump high in a somewhat uncoordinated manner. This might be it trying to release the bus to the other apparent Master. It is certainly not a STOP signal as would be the case with a NAK.

It might be the large pulse between clocks 8 and 9 which is not evident in plot1. Maybe it doesn't like the SDA handover to the Slave. I don't see any apparent problem with the signaling, it appears to follow spec, but maybe the glitch is large and fast enough to cause some unseen problem.

An idea might be to try and suppress the glitch between clocks 8 and 9 by slowing the SDA line down. Maybe try a slower pullup on SDA only. Say 10k or 15k on SDA and 1.5k on SCL. Just a guess.

-------------
The clocks are somewhat odd, plot 1 looks closer to 200kHz, and plots 2/3 look closer to 100kHz. It's not clock stretching (typically only on 9th clock). I'm not sure why the Master would have inconsistent SCL.

When I look at picture 1 and 2, I see that in pic 1 there are 9 SCK pulses before the SDA goes high, in pic 2, there are 8 pulses before it goes high. Is there some kind of 7bit addressing thing going on that the master is not using or something?

Matt
 
It depends on the Master/Slave SDA timing. The SDA direction changes twice, once before the 9th clock (as in plot2, it is so Slave can ACK), and once after (as in plot3, so Master resumes control). In either of those places a glitch can happen on SDA, it is very common. It is not a bug, per spec SDA can change as much as it wants when the SCL is low. Why the Master device doesn't like it isn't clear.
 
It depends on the Master/Slave SDA timing. The SDA direction changes twice, once before the 9th clock (as in plot2, it is so Slave can ACK), and once after (as in plot3, so Master resumes control). In either of those places a glitch can happen on SDA, it is very common. It is not a bug, per spec SDA can change as much as it wants when the SCL is low. Why the Master device doesn't like it isn't clear.

OK, I will try with the large resistor on SDA as you suggest, but I probably can not do it until Sunday night. Going to see my daughter get her graduate degree from Clemson on Friday! Thanks very much for all the help, I really appreciate it!

Matt
 
Status
Not open for further replies.
Back
Top