Comparing zephyrproject-rtos:main...malt...
Thanks @ZacckOsiemo
as of right now,
my I2C Signal looks something like this
As you can see, The SCL line stays low for a set amount of time after the write setup
https://github.com/zephyrproject-rtos/zephyr/compare/main...malto101:zephyr:ai64-r5-testing-i2c
GitHub
Comparing zephyrproject-rtos:main...malto101:ai64-r5-testing-i2c · ...
Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures. - Comparing zephyrproject-rtos:main...malto101:ai64-...
50 Replies
What device are you interfacing with?
can you try another device?
@melta101
a eeprom(24LC256)
Let me try
Another thing is it only turn SCL low when it gets ack
so you get an ack then scl goes low?
Correct!
what operation did you request
Standard write
Ok so the eeprom wants you to wait
so its stretching the clock
at 100 Kbps?
are you writing a lot of data?
do you need to configure the device before you write
like enabling and such?
Your datasheet should say when the device will stretch the clock
Does your master device account for clock stretching
Nope,
I still have to add the clk stretching features
also it seems like it is released in the end
does the operation succeed or fail?
Okay i think i figured it out
fail
BUt this is for SDA
not for SCL
That's wierd
wat master are you using
Beaglebone AI-64
i was trying to bring support to it with a couple of other TI devs
Ah you are modifying Zephyr, thats a lovely effort
Yep
Ok now we really want to help
GPIO, UART are done
so I2C , then SPI is on the roadmap
nice! I'm keen as to get involved
so we likely need to look at the i2c drivers and see if we need to account for clock stretching
what does the reference manual say about clock stretching and i2c?
As of right now,
The features i was able to implement are
I2C_init
reset
bus busy
setup write
rx or tx
Fifo resizing
100 Kbps selection
nothing
Just saw that
I mean they must be using a documented i2c module do you happen to know which one
or whats the previous version of this board?
This are new gen microprocessor
but they are compatible with OMAP I2C from linux kernel
ah
Also if you look into my code
you may say about the way i write clk calc
but the main thing is clk control cannot be accessed unless another module called TI-SCI is added to zephyr(which is a major effort)
So for now , i am dealign with the by changing the prescaler value etc..
and assuming the the main clock to be in default value
I really its with my own driver's logic
Hmmm just get on the right page the clk should be controlled by your clock source based on the prescalers
Hmm its hazardous to assume the main clock value, do you not have a default start up value
in st we can read a few registers and calculate the clock speed, can we do the same in beaglebone?
Sys_CLK values cannot be changed or read
is what i mean
Yep
its 12 Mhz
Oh dear thats a shame.
There is a saperate protocol which can do that
Ah thats ok
What document is this? can I please have it?
we should look at that and find a way of reading the clock source and pscs
I am not familiar with omap_i2c
The thing is
this isnt a simple microprocessor
This hold 2 A72, 6 R5F, 1 M4, and a bunch of DSP and GPU which effectively lets you do linux and RTOS simultaneously
but I do want to dig into it
J721e Datasheet
lemme share the link
Ah lot's of co processors on board
Yes I am having sort of the same issue with my mimxrt1060 but that is a few evolutions in so lots to use as a base.
I like it!
TDA4VM data sheet, product information and support | TI.com
TI’s TDA4VM is a Dual Arm® Cortex®-A72 SoC and C7x DSP with deep-learning, vision and multimedia accelerators. Find parameters, ordering and quality information
We are using the TDA4VM
Good thing is it is very well documented
MPU systems still confuse me to be honest, I have stream in a bit then I can come back to this. Do you mind if I take some time to wrap my head around this?
Yea, that is main plan,
but it is a massive undertaking which is in progress, but it isnt a single driver (somewhere around 15-16 drivers which when combines work on the protocol)-quite integrated
Also is there a zephyr issue for this ongoing work?
AH
Thats no prob
I have to go to work also lol
There is a board support PR on this
Yes please share a link to that.
Rather driver dev than control functions 🙂
GitHub
Add TI J721e R5 and BeagleBone AI64 R5 initial support by glneo · P...
This PR adds SoC support for TI J721e, specifically the R5 cores found in the MAIN domain (there is an R5 in the MCU domain we will add support for later). We also add board support for the Beagleb...
This is just the beginning
we have DDR support, GPIO, Mailbox also on stage
How do I get a device? Is there a working group
I would not mind digging
Currently it is mainly by TI devs
But i hold my discussion in the beagleboard Discord
I see
Just an update
I was able to fix it
was my driver isuue
It was trying trying to data even thought no data was passed
Oh thats amazing, haven't had a chance to look at this again.