cal_i2c read SDA locked down no STOP condition - bug?

[streammaster]

Hi Guys,

i was today debugging my hardware, and i experienced the PIC lock ups. After research, i pinpointed it to the i2c communication where the data (SDA) bus remains pulled down by PIC after read procedure is used. I also noticed that this occurs on second read (executing the read macro for second time) : first read will finish correctly but second read hangs.

Here is how the read i2c is implemented:

FC problematic i2C single read read.PNG

(25.9 KiB) Downloaded 2899 times

After this routine is executed second time (after processor startup), it looks that for some reason the STOP condition is never reached and the SDA is down, and the cal_i2c 'Master_RxByte(0) never returns back.:

i2C single read, buss not released - no Stop conditions.PNG

(92.02 KiB) Downloaded 2899 times

To fix this i added additional read amd this apears to be a 'fix':

FC fixed i2C read.PNG

(28.49 KiB) Downloaded 2899 times

It looks that there is something going on inside the cal which i can not debug since have no access to it. Could you please have a look in to this problem.

The oscilloscope illustration i will post in next post (since there is a limit of 3 attachments).

Regards,

Igor

[streammaster]

Here is the fixed 'double read' oscilloscope trace:

I2C double read.PNG

(137.68 KiB) Downloaded 2898 times

[LeighM]

As Ben recently mentioned http://www.flowcode.co.uk/mmforums/viewt ... 64&t=19312
the last read before stop needs to have (1) as a parameter, to indicate last byte to read.
You have that for the two byte read, but not for the single byte read.
Hope that helps.

[Docara]

Hi Leigh,

Just a slightly off topic question concerning the sort of action you mentioned here to get some nacross/components working.

Possibly anecdotally, there seems to be a lot of problems with components recently that to work, need some form of workaround or an obscure process only known by the FC staff - and component macros seem to be buggy - whats going on at FC?

The whole point of FC is that we, the user, just drag and drop icons to get a functioning programme, using the example above, why must we now have to DO something to get things working - they should just work this unfortunately, for I2C and SPI etc doesn't seem be the case anymore.

Ben recently stated that Matrix are working on v8 with features likely to make us want to upgrade "to keep the company in business" surely a better way is to have a product which works properly and has good documentation so it can be recommended to others and increase the user base.


Matt

[LeighM]

Hi Matt,
I take your point that our docs/help could be much better.
But this issue is not a case of a trick to get it working, but is part of the functioning of I2C and the macro API.
The Read macro has a help hint regarding this Last flag.
The complexity of I2C means it's probably best to read up on the protocol and have a look at examples, on the wiki etc.,
It's all too easy to make assumptions about the various sub-parts. We all do it
Leigh

[streammaster]

Hi Guys,

I understand now, but there is absolutely no reference in ANY of documentation about which values this property 'last' needs to be. Since most common use is a single byte it should be set to 1 by default.
In any case, component's function call should time out if there is some data error creating an unexpected condition.

I agree with Matt, the documentation should be much better especially for components and how to use them. The description and user guide should be updated accordingly how the issues are fixed or better-explained elsewhere like a forum. This is not so much work for Matrix guys but would have a large reflection on product use, and user satisfaction (10% of work will deliver 90% of issue solving).

The user forum is not the place to use references for how to use a product like instructions. User often have incorrect answers creating additional confusion and frustrations.

I will test this 'last' parameter and report back if this is solving it.
Leigh, I understand your suggestion and believe me I spent a nearly whole day searching for an answer.
The problem would be really fixed if in your help you have added following line:

Currently, this is all 'Help' proviced:
==============================
Master_RxByte
Returns a received data byte
Parameters
BYTE Last

Return value
BYTE
=============================

I suggest you update the help like this:

==============================
Master_RxByte
Returns a received data byte
Parameters
BYTE Last (0,1)
Set BYTE=0 if there is following more Master_RxByte macros
Set BYTE=1 if this is the last Master_RxByte and it is followed with Master_Stop.
If BYTE = 1 the I2C bus will be presented with a 'Nack' condition after reading the BYTE.

Return value
BYTE .Return (received data from the I2C bus)
=============================

The online help appears to provide in general terms any of such information, and as you commented, it is open to interpretation.
I do not agree that the I2C is "complex". The only issue is that the CAL implementation is lacking detailed description.
I was able to see the issue in the hardware (bus conditions) but didn't understand how the CAL component is implemented.

Regards,
Igor

[Docara]

........The description and user guide should be updated accordingly how the issues are fixed or better-explained elsewhere like a forum. This is not so much work for Matrix guys but would have a large reflection on product use, and user satisfaction (10% of work will deliver 90% of issue solving).

The user forum is not the place to use references for how to use a product like instructions.

Hi Igor,

I feel your pain my friend, you've repeated what I have said elsewhere here.

The fact we have paid our money I think gives us the right to moan. Steve (Matrix) posted recently what we would like to see in V8 and I responded, amongst, other things, about the documentation and the conversation promptly stopped. You notice that I again asked (above) about all the bugs in the communication components we have suddenly started seeing and the conversation seemed to stop.
Why should we buy V8 when Matrix will be adding headline grabbing feature which nobody will know how to use (again). I think Martin (Medelec) does such a wonderful job helping people but he shouldn't have to do it. The sort of things he helps with should be documented in a help. AN OFFLINE HELP!!!

Either Matrix are in trouble and can't afford the manpower or they have complete disregard for us the user. If it wasn't for Benj (and now LeighM) we would be right royally screwed. I think it is incredulous that their software engineers must be told not to write documentation for their code functions for FC. I know 2 VERY senior SW Engineers that automatically document as they go for know other reason than to help themselves out with their thought process AND to leave something behind if the where hit by a bus. It is not a leap of the imagination to extract help documentation from the paper trail.

I think Matrix have completely lost their way tried to expand into a field well over and above where they had a nice niche - schools.
I for one will not be paying for something I can't use.

At least Autodesk Fusion360 is free when reduces me pretty much to tears with frustration and annoyance - I paid for FC!!!!

Remember Matrix, if we didn't care and believe in your software we would have binned it and learnt C long ago. PLEASE EVERYONE partition Matrix to give us FULL documentation we deserve so we can USE each and every part of your fantastic product before you lose your loyal customer base.

Matt

[Benj]

Hi Igor,

I suggest you update the help like this

Done, thanks for the suggestion

Hi Matt,

I think providing something that is flexible, easy to maintain and up to date is very hard, the wiki is the ideal but you have mentioned you want offline help. Would this be in the form of a giant PDF or are you imagining something different? Maybe something built into Flowcode directly. We currently have tool tips for components that reflect the wiki content, in fact these are used to generate the wiki content. We know it's not ideal but it's hard to find the middle ground that makes everyone happy.

[Steve]

Hi Matt,

I agree with the general issue you are raising - that Flowcode's documentation is lacking in certain areas. However, I feel some of your specific statements are unfair and I want to comment on them below.

The fact we have paid our money I think gives us the right to moan.

Totally agree!

Steve (Matrix) posted recently what we would like to see in V8 and I responded, amongst, other things, about the documentation and the conversation promptly stopped. You notice that I again asked (above) about all the bugs in the communication components we have suddenly started seeing and the conversation seemed to stop.

I don't think any conversation "promptly stopped". Leigh has responded to your post above saying we agree that the documentation requires improvement. I also replied to your comment in a similar way (viewtopic.php?f=73&t=18999&p=82383#p82383).

I think Martin (Medelec) does such a wonderful job helping people...

I cannot thank Martin and our other VCs enough for their help in helping on this forum. Other Flowcode users contribute massively too, which is also much appreciated. I'm so pleased that this forum has a culture of helping each other in a professional and constructive manner which is sadly lacking on many other forums.

...but he shouldn't have to do it. The sort of things he helps with should be documented in a help. AN OFFLINE HELP!!!

Ideally, no, but the nature of many issues on this forum are unlikely to be addressed in a help file. We do have plans to improve documentation I fully agree it needs to improve. As a company, we feel an online up-to-date Wiki is more appropriate for this kind of product rather than an offline help manual.

Either Matrix are in trouble and can't afford the manpower or they have complete disregard for us the user.

We're certainly not in trouble. We have had a very good year (ours runs Aug - July) and recruited 3 new members to our dev team a few months ago. And if we had total disregard for the user, we would soon be out of business.

If it wasn't for Benj (and now LeighM) we would be right royally screwed. I think it is incredulous that their software engineers must be told not to write documentation for their code functions for FC.

Our software engineers are expected to document and maintain the functionality they develop. Benj and Leigh are responsible for the majority of components and code used by Flowcode which is why they are heavily involved in this forum.

I hope this goes some way to answering your concerns.

If you still have concerns and wish to take this further, then please get in touch via email/PM as this forum's purpose is product support and user-user help, rather that dealing with complaints and grievances.

Regards,
Steve.