search

sshuv / iicmb

BSD 2-Clause "Simplified" License
8 stars 4 forks source link

Bus occupied via Flags 'Bus Busy' & 'Bus captured' sometimes not working #10

Open andkae opened 9 hours ago

andkae commented 9 hours ago

Hi Sergey,

the proposed way (#8) to detect another Bus Master ownership with the implementation in:

https://github.com/sshuv/iicmb/blob/b0f6e5916a1a3ee016e685f3219ff459498d231d/software/irq/iicmb.c#L585-L596

Works under special conditions not. The Signal busy is generated in the conditioner.vhd and the signal captured in mbyte.vhd. The skew between both signals lead to an false-positiv if the sampling ocures in this tiny time window:

Startbit: image

Stopbit: image

Do you have an idea, how we can solve this issue?

Thanks for your support.

BR, Andreas

sshuv commented 5 hours ago

Hi Andreas!

The relationship you point out between the 'captured' and 'busy' signals cannot be eliminated. The signal 'busy' is controlled directly by the SCL and SDA transitions, and this is good. This allows to see the state of the bus as it is, without taking into account the IICMB's internal state. The signal 'captured' is just an alias for a subset of byte-level state machine states (see mbyte.vhd). Both signals are interesting on their own and I don't see any need to synchronize them to each other.

Generally speaking, if your objective is just to perform several operations on the selected I2C bus, you don't have to check the bus state explicitly. Just write the required command into the IICMB and it will wait, if required, until the bus become free, and then it will capture the bus and complete the command. I recommend not to look at 'busy' and 'captured' signals while performing regular operations on I2C bus. Read these signals only in emergency conditions, when you feel that something went wrong.

For example, every operation on I2C bus begins with Start Condition, so the first thing your driver should do is to write the 'Start' command into the CMDR. After that the two things could happen:

  1. After some acceptable time the bit DON in the CMDR becomes '1'. This means everything goes well, you have captured the bus;
  2. No response for quite a long time. Something really went wrong, the bus is always in busy state. Here driver might check explicitly the 'busy' signal -- it will be '1'. The driver can also check the states of the FSMs in the FSMR register and report the information as an error message.

After 'Start' command you issue several 'Read' or 'Write' commands and finally 'Stop' command. Do not look at 'busy' or 'captured', just wait for a response in the CMDR register (or lack of a response).

If there is anything still unclear, please ask.

Best regards, Sergey