i2c handler

[tehn]

get i2c receive into the handler system

[tehn]

right now i2c test is /aleph/utils/avr32_blank

[electropourlaction]

is this active in the latest build? I'm looking into a possible hookup with another device, need to do some tests/proof-of-concept.

[tehn]

this is quite possibly not working correctly-- it hasn't been looked at for a long time. i'll have a change to revisit it next month, as i rewrote the i2c code for the new modules-- it can be back-ported to the aleph.

On Thu, Jun 4, 2015 at 4:54 PM, electropourlaction <notifications@github.com

wrote:

is this active in the latest build? I'm looking into a possible hookup with another device, need to do some tests/proof-of-concept.

— Reply to this email directly or view it on GitHub https://github.com/tehn/aleph/issues/89#issuecomment-109047379.

[electropourlaction]

I read as there is a 3.3V IC in the aleph, is there a possibility for it to reconfigure it for 5V (does it have a high voltage option?) or would I need some kind of i2c level shifter?

[tehn]

i2c is 3.3v on the aleph.

yes, you'll need a shifter.

On Fri, Oct 2, 2015 at 7:59 AM, electropourlaction <notifications@github.com

wrote:

I read as there is a 3.3V IC in the aleph, is there a possibility for it to reconfigure it for 5V (does it have a high voltage option?) or would I need some kind of i2c level shifter?

— Reply to this email directly or view it on GitHub https://github.com/tehn/aleph/issues/89#issuecomment-144998373.

[electropourlaction]

I have tried to port the i2c mod code to the aleph, getting output but it looks to be a little out of control (it just pours out funky lookin' data on both SDA and SCL channels), would it be likely that the mod code can be ported without any modifications? I will try and walk it thru step by step one more time, testing with the i2c_master_tx function and a logic analyser at this stage just to get a starting point, communication from the avr32 to an stm32 will be the purpose later on.

[ghost]

also very keen to get i2c feature into bees! Happy to cast an eye over your port tonight... Wish I could be more help on the board config / low-level but probably not able to help much there (don't have logic analyser or scope at home)

[electropourlaction]

mostly puzzled right now so happy to get any help(!) the data that comes it makes no sense, as far as I know I'm not actively sending anything yet.

I'm hoping to see something like... setup write to [address] + NAK

but this is what comes out... Time [s],Packet ID,Address,Data,Read/Write,ACK/NAK 0.028900500000000,,'0',,Write,Missing ACK/NAK 0.048798500000000,7,'0','0',Write,ACK 0.068759500000000,,'0',,Write,Missing ACK/NAK 0.068825000000000,9,'0','0',Write,ACK 0.068891666666667,9,'0','0',Write,ACK 0.068963250000000,9,'0','0',Write,ACK 0.069370833333333,,'0',,Write,Missing ACK/NAK 0.069599000000000,,'0',,Write,Missing ACK/NAK 0.089114833333333,13,'0','0',Write,ACK 0.109168166666667,,'0',,Write,Missing ACK/NAK ..and so on....

[ghost]

Have you debugged the the logic analyser using already known-working device? I know how this song & dance goes on a beaglebone black if you have access to one? So basically plug the scl/sda from bbb into the logic analyser & sanity-check all is well. (Apologies if that's patronisingly obvious or not helpful!)

[electropourlaction]

I tried it with the stm32 just before and that looks fine, one thing that just crossed my mind is cable length/interference, I'm using a cut 1/8" cable to the aleph, the stm32 is a dev-board so I can connect directly to the pins.

[tehn]

might suggest slowing down the rate, and checking the pullup resistors involved? there are 10k's on the board. might need to add some resistors additional resistors to lower the overall pullup.

On Thu, Apr 21, 2016 at 4:53 PM, electropourlaction < notifications@github.com> wrote:

I tried it with the stm32 just before and that looks fine, one thing that just crossed my mind is cable length/interference, I'm using a cut 1/8" cable to the aleph, the stm32 is a dev-board so I can connect directly to the pins.

— You are receiving this because you were assigned. Reply to this email directly or view it on GitHub https://github.com/tehn/aleph/issues/89#issuecomment-213109783

[ghost]

have been dragging all kinds of cruddy cables around a noisy lab with i2c without an issue, but have to admit I am ignorant of clock speed settings, suggested pullups etc - bbb plugged & played!

Would chuck a scope straight on the ends of cut cable (with everything disconnected) you should see nothing until setting/getting a register (idle high), then a split second of activity on those 2 lines (lots of edges), then again nothing. Can see this with a decent multimeter if you don't have scope. Scope could also give you a sense if the digital edges are clean or garbage.

From your description it sounds as if the 2 lines on i2c bus are constantly flapping up and down as soon as you fire up the device? any change in visual activity trigger-able from code? (as much as you can tell by watching digital signals fly by on scope trace).

[electropourlaction]

ok, so it does not look pretty, both channels are basically doing a very distorted/broken resemblance of a pulse wave between 0 - 5V (ouch...)

[ghost]

just to reiterate - both lines are idle high on beaglebone -> fpga setup here in the lab. Nothing until I send i2cget or i2cset signals.

Also - all the i2c I've seen here at work is 3.3v (think it's more common than 5V) could that be a clue?

[electropourlaction]

it should be 3.3v, I will try the same scope-test with the stm32 to get a reference (tomorrow!)

[electropourlaction]

update, please ignore my stupidity, but I have now realised that a stereo cable is needed so there is SDA, SCL and ground, hopefully that will help further progress on my end :)

both SDA and SCL are set high after initialisation when connected like this.

[electropourlaction]

in the build I'm working from the TWI clock was not enabled, so by enabling it I managed to send with the twi_master_write_ex() function, in cont_clock.h added one line to the #define statement.

define CONFIG_SYSCLK_INIT_PBAMASK ( (1 << SYSCLK_USART0) \

                 | (1 << SYSCLK_USART1) \
                 | (1 << SYSCLK_INTC) \
                 | (1 << SYSCLK_GPIO) \
                 | (1 << SYSCLK_TC) \
                 | (1 << SYSCLK_PDCA_PB) \
                 | (1 << SYSCLK_SPI0) \
                 | (1 << SYSCLK_SPI1) \
                                 | (1 << SYSCLK_TWI) )

[electropourlaction]

walked into some trouble, happy to get any ideas/input

I'm setting up an i2c where avr32 as master is transmitting to an stm32 as slave, managing to send one message and I can verify that the data in the first message is written, so all good, until a second message is sent, then I get the error message on the avr32 TWI_RECEIVE_NACK (-5), and meanwhile on the stm32 I get stuck in the i2c interrupt. as it looks the av32 is trying to setup a second write but gets a NAK in return, so the second message is not sent.

went thru the registers on the stm32 before and after the error, found some differences, but I have not been able to write to these registers after the jam, not sure what that implies.

CR1_ACK: set before the error, and cleared after CR2_ITERREN, ITEVTEN, ITBUFEN (interrupt related registers): set before, cleared after

trying to figure out on which end I should solve this as I'm continuing to dig into i2c register tables!

edit: attached the first successful message, it doesn't look like the avr32 is actively sending a stop message, but maybe it does not need to(?)

edit2: avr2 is sending a stop bit, I just missed that when I looked at this screen shot the first time..

[electropourlaction]

found a way to send multiple messages, but still only the first message is written, not sure if this kind of brute force is the best way to go though...

added these commands to the interrupt callback on the stm32: setting the i2c data pin to low (now I can write to the i2c registers) setting the CR1_ACK register setting the CR2_ITEVTEN register setting the i2c data pin back to high

edit: if I should continue down this path I need to find the proper "while busy command" so that the 8 bytes that is a message always is 8 bytes, plus a way to "reset or restart the writing to the i2c buffer"-register so that multiple messages are also written, not just the first.

[electropourlaction]

finally got this to work! after adding this to the smt32 i2c callback;

// here I want to improve this and try to wait for the stop message flag instead but this will do for now.. while (hi2c1.XferCount);

// re-setting the counter, each message is 8 bytes.. hi2c1.XferCount = 8;

// re-setting the pointer to the start of my receiving buffer hi2c1.pBuffPtr = receive;

// setting SDA low, to allow writing to the registers HAL_GPIO_WritePin(GPIOB, GPIO_PIN_9, RESET);

// re-setting ACK, looks like the second message is not accepted by the stm32 without this hi2c1.Instance->CR1 |= I2C_CR1_ACK;

// re-setting interrupts, without this the interrupt stalls after one message hi2c1.Instance->CR2 |= I2C_CR2_ITEVTEN; //maybe this one is enough hi2c1.Instance->CR2 |= I2C_CR2_ITBUFEN;

// setting SDA high HAL_GPIO_WritePin(GPIOB, GPIO_PIN_9, SET);

// and then I just copy the data from the receive buffer to where I want it..

[tehn]

fantastic!

[tehn]

so was this an aleph issue or stm32 issue? could you post the stm32 code somewhere as reference?

[electropourlaction]

it really looks like an stm32 issue, at least I did not make any changes to the twi-function/avr32 lib, but honestly I'm not so "knowledged" in this that I can rule out the possibility of an avr32 solution, right now I'm just happy it works(!)

attached a short version of the stm32 code, just for the communication part in main() which I'm testing now. there is still some work to do on the complete solution, but I will post that too (when it's done!)

main.txt

[electropourlaction]

I have a question on the i2c phone connector, I can not find it in the bom, is it an unswitched stereo connector?

[electropourlaction]

fyi, I have an i2c i/o functionality ready, input on interrupt that posts an event (as slave) and output as master, if anyone needs this right now I can try to upload just these parts, otherwise I will just post everything with the next version of the PRGM app.

[electropourlaction]

nevermind!