• AVR Freaks

Helpful ReplyHot!Harmony 2.03b I2C issue PICMZ - Silicon Errata

Page: < 123 > Showing page 2 of 3
Author
thackerp
Super Member
  • Total Posts : 123
  • Reward points : 0
  • Joined: 2012/01/18 12:25:44
  • Location: Chandler, AZ
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/17 04:29:07 (permalink)
0
Johnny0099
@thackerp
 
is there a way to get A3 chip samples?


PM sent.
#21
Mysil
Super Member
  • Total Posts : 3476
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: online
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/17 06:49:35 (permalink) ☄ Helpfulby Johnny0099 2017/05/18 20:55:42
5 (1)
Hi,
Code shown in message #19 seem like a step in the right direction,
but may not be appropriate in all cases.
A function like  DRV_I2C_Bus_Clear (sysObj.drvI2C0);  will mainly be correct to use in 2 cases;
1:  If microcontroller have been Reset while Reading data from a slave device,
    such that slave device is waiting for SCL clock to continue.
    Such a Reset may happen during development or debugging,
    or because of WDT timeout or program crash in a production build.
2:  If a I2C Bus collision have been detected by I2C hardware during Reading from a slave device.
    Such a Bus collision may be caused by noise, EMC, hot-plugging...
 
In both above cases, SDA line is stuck Low, while SCL line behave normally.
 
Code in message #19 look like an attempt to Retry a transfer that was active in the driver,
or encourage the driver to resume processing with the next transfer in queue.
Restarting a ongoing I2C transfer, may depend upon the current state of the I2C interrupt driver.
In general, I2C specification expect that: if Bus collision is detected during Start condition signaling,
or during Address arbitration, the transfer should be retried by the driver by sending Start signal and address again.
If Bus Collision happen during data transfer, there is no sure way to know what to do on the driver level,
without risk of corrupting data,
so transfer should be aborted, and the failure reported to application status.
If other transactions in queue from the same client, should also be failed, I don't know.
It is not sufficient to just clean up the queue, failure status must also be reported to application code, I am not sure how this is done in Harmony driver.
 
If the driver or hardware get stuck during Stop signaling,
    DRV_I2C_Bus_Clear (sysObj.drvI2C0); 
may not do anything useful, just bitbanging the Stop condition signal may be sufficient.
 
If there is a Multimaster environment, using  DRV_I2C_Bus_Clear (sysObj.drvI2C0); 
at the wrong time may cause a lot of confusion.
 
Regards,
   Mysil
#22
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/20 02:14:26 (permalink)
0
What the hell!! We have to go in production with 2500 items ASAP and already don't know what to do.
 
1) Don't know if A3 revison works better that A1.
2) Don't know where to find a few A3 samples.
3) Can't use bitbanged I2C since PIC32 is running at 50 Mhz and have performance isssues on other tasks.
4) Can't find an effective workaround to I2C Errata. Need to work on this, ok, but I need time and have to wait long each time to verify if it works since this issue happes once every 4 or 5 hours.
5) Any useful Help from Ticket/Support.
 
Is there a valuable workaround from Microchip? Don't think I'm the only one having this issue!!
 
Anyway, thank you Mysil for your suggestion I will try this path.
#23
GDA
Junior Member
  • Total Posts : 83
  • Reward points : 0
  • Joined: 2015/08/31 16:46:40
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/22 08:47:22 (permalink)
0
I do not believe that A3 silicon will work better than your A1 silicon.
 
1) In order to reproduce the problem, try and setup a continual transmission test.  Unless I am very much mistaken, you should be able to reproduce the problem every few minutes rather than over several hours.  This will allow much faster testing of possible solutions.
 
2) Did you see my suggestions in post #20?
 
3) Can you confirm that your working in a single master environment?
 
4) Can you confirm that the transmissions you are trying to achieve in the production code are relatively slow?  That is, how many bytes are you trying to transmit and then receive and how often do you need to do that?
 
5) In order to get the solution I proposed to work from post #13 you have to go through the driver, and not use PLIB calls which talk directly to the peripheral behind the driver's back.
 
6) I have seen exactly the sort of issue you describe in several projects now.  I have been able to fix them all by implementing the Clear Bus call and by re-sending whatever transaction caused the problem.  The code you posted in #19 is a start, but it did not seem to reset the driver transaction queue and re-send the failed transaction.
 
7) Here is a little code snippet:
<code>
static void MASTER_APP_I2C_Task (void)
{
  switch(master_appData.i2cStates)
  {
    default:
    case MASTER_APP_I2C_START:
    {
      RED_LEDOff();
      YELLOW_LEDOff();
      GREEN_LEDOff();
      // Keep the I2CBufferHandle invalid until a successful call to the transmit function
      // sets it to a valid transaction queue handle.
      master_appData.I2CBufferHandle = NULL;
      master_appData.i2cStates = MASTER_APP_I2C_TRANSMIT;
      break;
    }
    // If no transmission is currently in progress, then start one.
    // If the Bus Collision interrupt detects a problem, then reset the I2C bus and restart the transmission.
    // If a transmission is in progress, then check its status until it is complete, finishes with an error, or 
    //      the bus error interrupt signals a problem.
    case MASTER_APP_I2C_TRANSMIT:
    {
      if (I2C_Error)
      {
        I2C_Error_1 = false;
        // Handle bus collision
        DRV_I2C_Bus_Clear ( sysObj.drvI2C1 );
        DRV_I2C_QueueFlush ( master_appData.handleI2C1 );
        master_appData.i2cStates = MASTER_APP_I2C_START;
      }
      else if(master_appData.I2CBufferHandle == NULL)
      {
        // If no transmission has occured yet...
        YELLOW_LEDOn();
        master_appData.I2CBufferHandle = DRV_I2C_TransmitThenReceive ( master_appData.handleI2C1,
                master_appSlaveAddress,
                master_appWriteString,
                sizeof(master_appWriteString),
                master_appReadString,
                sizeof(master_appReadString),
                NULL);
      } else {
        master_appData.I2CBufferEvent = DRV_I2C_TransferStatusGet ( master_appData.handleI2C1,
        master_appData.I2CBufferHandle );
        if(master_appData.I2CBufferEvent == DRV_I2C_BUFFER_EVENT_COMPLETE)
        {
          master_appData.i2cStates = MASTER_APP_I2C_DONE;
        }
        if(master_appData.I2CBufferEvent == DRV_I2C_BUFFER_EVENT_ERROR)
        {
          master_appData.i2cStates = MASTER_APP_I2C_ERROR;
        }
      }
        break;
    }
    case MASTER_APP_I2C_DONE:
    {
      master_appData.i2cStates = MASTER_APP_I2C_START;
      GREEN_LEDOn();
      break;
    }
    case MASTER_APP_I2C_ERROR:
    {
      RED_LEDOn();
      master_appData.i2cStates = MASTER_APP_I2C_START;
      break;
    }
  }
}
</code>
 
The timing of the LEDs is a bit fast here, but it lets me know if any unhandled errors occur.  Meanwhile, it allowed me to try different things in the if(I2C_Error) block to try and recover in different ways.
Obviously, this is just an example.  The idea is to detect a bus collision while waiting for the previous transmission to complete and clear the bus before re-sending that transmission.
 
8) If you need to, you could create a new case in this sequence to make the clear bus less blocking.  The trick to that would be to make sure that the clock pulses held a minimum timing.  They don't need to be precisely timed, just so long as they meet the minimum requirements of whatever slave devices might be attached.
 
 
I hope this helps.
 
 
#24
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/27 00:03:44 (permalink)
0
gary.attarian
I do not believe that A3 silicon will work better than your A1 silicon.

I suppose so, but, did you test both? Do you have any evidence?
 
gary.attarian
1) In order to reproduce the problem, try and setup a continual transmission test.  Unless I am very much mistaken, you should be able to reproduce the problem every few minutes rather than over several hours.  This will allow much faster testing of possible solutions.

My application is using I2C intensively by default. I've 3 apps each one with a I2C client on it that continuosly reads data from sensors on the same BUS. 
 
gary.attarian
2) Did you see my suggestions in post #20?

Yes, I'm not sure why the BUS is not starting again anymore. Will check SCL and SDA lines with a scope. It's not easy in my application to clear the queue. I've 3 apps using the same I2C trhough different clients.
 
gary.attarian 
3) Can you confirm that your working in a single master environment?

Yes, it's a single master environment with multiple clients operating on the same I2C Bus.
 
gary.attarian 
4) Can you confirm that the transmissions you are trying to achieve in the production code are relatively slow?  That is, how many bytes are you trying to transmit and then receive and how often do you need to do that?

BUS speed is set to 50 Khz now, but I've tested 100 KHz, 400 KHz and 10 Khz too. Not so much difference. I'm continuolsy reading data from several sensors on the I2C bus. Each transaction is a few bytes (5 or 10 bytes at all), buy I'm reading every 50/100 ms.
 
gary.attarian 
5) In order to get the solution I proposed to work from post #13 you have to go through the driver, and not use PLIB calls which talk directly to the peripheral behind the driver's back.

I'm doing it. Not so easy to clear the queue, since I'm using multiple clients, an the queue belongs to the client, so I've to re-sink all clients. Want to try also to identify the client that was using the BUS at the time of the fault and clear/resink only that queue.
 
gary.attarian 
6) I have seen exactly the sort of issue you describe in several projects now.  I have been able to fix them all by implementing the Clear Bus call and by re-sending whatever transaction caused the problem.  The code you posted in #19 is a start, but it did not seem to reset the driver transaction queue and re-send the failed transaction.

Will try to work on it. The main problem with the queue resink is that with one I2C client I'm sending a data to a digital potentiometer that should be continuosly modulated with a waveform. If I'm missing to send a packet I should resend. If I clear the queue, need to know the last successful transaction and need to send the next one. I'm using the queue to syncronize asyncronous tasks. I prefer to "repair" the queue rather then clear it.
 
#25
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/27 01:08:44 (permalink)
4.33 (3)
Microchip is on the right way to solve I2C issues on PIC32, just start removing it from new MCU releases:
 
http://ww1.microchip.com/downloads/en/DeviceDoc/60001402D.pdf
 
PIC32MK does not have I2C al all! :-)
Next step will be removing it from PIC32MZ??
#26
GDA
Junior Member
  • Total Posts : 83
  • Reward points : 0
  • Joined: 2015/08/31 16:46:40
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/30 08:10:16 (permalink)
0
Johnny0099
gary.attarian
I do not believe that A3 silicon will work better than your A1 silicon.

I suppose so, but, did you test both? Do you have any evidence?

 Yes.  The fundamental issue in the A step silicon is still present in the A3 silicon.  Improvements were made, but the root cause of the issue was not corrected.  I've seen both demonstrate the same behavior that you describe.
 
 
 
Johnny0099
gary.attarian
1) In order to reproduce the problem, try and setup a continual transmission test.  Unless I am very much mistaken, you should be able to reproduce the problem every few minutes rather than over several hours.  This will allow much faster testing of possible solutions.

My application is using I2C intensively by default. I've 3 apps each one with a I2C client on it that continuosly reads data from sensors on the same BUS. 

Hmm.....  Yes, that will make things more difficult.
 
Let me ask a few more questions about potential fixes.
 
1) Would an API to skip the current transaction work for you?  I'm envisioning an API that you could call with the Transaction Handle of the current transaction which would simply mark it complete (with error), and then alter the driver state to look for the next transaction.  I'm not certain that this would work, nor how to make it work, I'm just exploring.
 
2) You have 3 applications querying how many sensors?
 
3) Do each of your apps communicate exclusively with just one sensor?  Or do they share all of the sensors?
 
4) We might be able to send the error signal into the driver rather than check it in the application.  We'd have to create an Error_Tasks function which the error interrupt would call.  This function could use the Driver internal variables to clear the bus and close the last transaction queue item (with error), and then update the task state to check for the next queue item.  
The idea would then be for your application to operate slightly differently if a transaction finished with an error than if it completes successfully.
 
 
I have to think about that a bit.  I'm not at all certain how to solve this in a more general way.
 
I hope this helps.
#27
Aaron Hancock
Junior Member
  • Total Posts : 90
  • Reward points : 0
  • Joined: 2016/02/23 15:10:25
  • Location: Virginia, USA
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/05/30 12:37:47 (permalink)
3 (1)
In my project, using PIC32MZ2048EFH144 (200 MHz), I ran into a hanging I2C issue that I could only recover from with a power cycle.  I assume (though haven't verified) that the slave device was missing the last ack on a multi-byte read and was therefore keeping control of the SDA line.  After I discovered the errata for I2C, I first slowed the clock I2C rate to 50K and reduced my block read/write size from 512 to 256 bytes.  This helped a lot, but didn't entirely solve the problem.
So, I turned off the I2C module and wrote my own bit-banged I2C driver.  I am only talking to a Cypress FM24V10 FRAM chip, so the interface was pretty clean.  After I got it working, I was able to go back to 1MHz I2C clock and 512 byte transfers.  It has not failed since.
#28
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/06/01 06:22:14 (permalink)
3 (1)
gary.attarian
Yes.  The fundamental issue in the A step silicon is still present in the A3 silicon.  Improvements were made, but the root cause of the issue was not corrected.  I've seen both demonstrate the same behavior that you describe.

 
 Great! I just ordered some A3 silicon from Microchip Direct looking for a remote possibility to have better behaviour on I2C compared to A1. My last hope end here :-(
 
gary.attarian
1) Would an API to skip the current transaction work for you?  I'm envisioning an API that you could call with the Transaction Handle of the current transaction which would simply mark it complete (with error), and then alter the driver state to look for the next transaction.  I'm not certain that this would work, nor how to make it work, I'm just exploring.

 
I2C Bus collision and other errors are notified into the ISR IntHandlerDrvI2CErrorInstance0. If the error is further notified to the app trough the event handler, the app would call this api inside the event handler function. I think an API like the one you are proposing would help to remove only the failed transaction from the queue and not the entire queue. The app would then decide how to manage this situation.
 
gary.attarian
2) You have 3 applications querying how many sensors?
3) Do each of your apps communicate exclusively with just one sensor?  Or do they share all of the sensors?

 
App1: MCP4451 (Digital Potentiometer) + MCP4728 (12 bit DAC) + 24FC64 (I2C EEprom)
App2: 24FC64 (I2C EEprom) different from the one used within App1 + MCP4652 (Digital Potentiometer)
App3: LIS2HH12TR (Accelerometer) + HTU21D (Temp + Humi) + BMP280 (Barometer) + BD2606MVV-E2 (Led Driver)
 
gary.attarian
4) We might be able to send the error signal into the driver rather than check it in the application.  We'd have to create an Error_Tasks function which the error interrupt would call.  This function could use the Driver internal variables to clear the bus and close the last transaction queue item (with error), and then update the task state to check for the next queue item.  
The idea would then be for your application to operate slightly differently if a transaction finished with an error than if it completes successfully.

 
It's really a good idea. In case of any transaction error, clearing the bus (in case any peripheral on the bus is stuck), closing the last queue item (with error), notify this error to the app trough the event handler, allow the driver to restart from the next queue item is the behaviour that i'm expecting from Harmony I2C driver. In the event handler in case of error notification is up to the client to decide what to do (clearing the queue, ignoring the error, retransmit a specific sequence, retransmit the last transaction, etc..).
 
Next step for me will be to try modifiying I2C driver trying to reach this behaviour. It will be time spending, but I have no other choice at this time. This issue is blocking my company. We have oders from customers, production ready to go with 2500 items, and no way to get out from this I2C Errata nightmare. Hope to find a solution to this issue before my company will decide to close this project definitively. Revision A0, A1, A2, A3, B0, B1 and no way to have a working I2C module on PIC32MZ EF? We have also to consider PIC32MZ EC previous failures on I2C? Unbelievable, it seems a joke!!
 
Generally speaking, the benefit of this Harmony I2C driver is the possibility to handle comunication of different peripherals within the same BUS from different Apps (different clients) throughe the queue. This is fantastic, but at the same time is really hard to manage transaction errors, and in this particular case I2C Errata makes things worse.
 
Thank you GDA by taking in charge this issue. I will inform you if I will have any good news from my side.
post edited by Johnny0099 - 2017/06/01 06:24:09
#29
GDA
Junior Member
  • Total Posts : 83
  • Reward points : 0
  • Joined: 2015/08/31 16:46:40
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/06/01 07:06:07 (permalink)
0
One Last question, Johnny0099, you have some available timers in your project, correct?  I'm thinking of ways to implement my earlier suggestion, and one of them (in order to do it right) might require the I2C driver to use a timer.  AT this point, that means that it would need to have exclusive access to that timer.  I just want to make sure that such a solution won't run into any other issues with your project.
#30
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/06/01 12:28:17 (permalink)
0
Yes, I have a couple of available timers in this project. 
 
BTW, I'm assuming that your idea is to set a timeout to trigger I2C inactivity when an error is happening without generating any error interrupt. Maybe it's also possible to use System Ticks instead of a physical timer.
 
SYS_TMR_TickCountGetLong()
SYS_TMR_TickCounterFrequencyGet()
#31
GDA
Junior Member
  • Total Posts : 83
  • Reward points : 0
  • Joined: 2015/08/31 16:46:40
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/06/01 13:57:06 (permalink)
0
I would prefer to use the system timer.  Especially since we only need to time events when an error occurs.  But we need the timer to cause different code to run, and we need it to do so in a non blocking manner.
 
We could do something like check the time every time the buffer status routine is called, but that introduces a very non deterministic polling method into what should be a very tight timing feature.
 
What I'm thinking is to use the Bus Error interrupt to start a timer interrupt.
The timer interrupt would be used to make the clear bus function non blocking.
I would also use the rewrite as an excuse to make the clear bus function much faster (currently it assumes a 50KHz I2C clock).
Finally, I would modify the clear bus function to cause the latest queue item to abort with an error condition while leaving any remaining queue items alone.
 
After writing that, however, I'm rethinking it.  IF I can get the clear bus function to do that last item, then that alone might get you moving again.  IT would be slow, and the clear bus would still be blocking, but it would remove the need to flush the queue in the application.
 
Hmmmm.....  I need to think that through a bit more.
#32
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/06/02 05:57:50 (permalink)
0
According to PIC32 MZ EF Errata there should be 3 type of issues:
 
False Error Condition 1:
False Master Bus Collision Detect (Master-mode only) – The error is indicated through the BCL bit (I2CxSTAT<10>)
In this case the interrupt for this error is set in hardware. Errara suggest to clear BCL and monitor S bit (I2CxSTAT<3>) and the P bit (I2CxSTAT<4>) to wait for an Idle bus, then, the comunication can restart by asserting a new start condition. Since this is a "false" master bus collition, there is no way to know if it was appening at the beginning of the I2C transaction or in the middle. Am I right? If this error happens only after asserting a new start condition the driver should: a) wait for idle bus, b) clear che bus for slave peripherals by cycling the clock.
 
False Error Condition 2:
Receive Overflow (Master or Slave modes) – The error is indicated through the I2COV bit (I2CxSTAT<20>)
In this case it's only required to clear the I2COV bit, but what about the slave peripherals? Bus must be cleared in case of any stucked one in the middle of a byte transmission?
 
False Error Condition 3:
Suspended I2C Module Operations (Master or Slave modes) – I2C transactions in progress are inadvertently suspended without error indications.
Here a timer must be used to check periodically if a transaction is suspended. I2C module must be reinitialized and bus must be cleared.
 
In general, each I2C Master operation is followed by a Master Interrupt if successful of by a Error Interrupt in case of failure/error. A workaround action should be initialized in Error Interrupt (Error Handler Task), while in case of Suspended I2C Module Operations (False Error Condition 3) a timer should trigger the Error Handler.
 
Error Handler should be able to manage all the above critical situations and errors by checking I2C registers. Depending on when the error happend it shoud decide if to clear the BUS or not for peripherals blocked in the middle of a byte transfer.
 
Let me see what I can do.. really really not easy!!!
#33
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/06/03 10:18:54 (permalink)
0
Today I made some other test on I2C and found that:
 
1) In the most of times the error is False Master Bus Collision. Interrupt error is triggered and registers are like above:
 
I2C1STATbits.BCL = 1
I2C1STATbits.IWCOL = 0
I2C1STATbits.I2COV = 0
I2C1STATbits.P = 0
I2C1STATbits.S = 1
 
It seems that error is happening when asserting a start condition. When the error is appening the I2C task (dObj->task) is set to DRV_I2C_TASK_PROCESS_WRITE_ONLY or DRV_I2C_BUS_SILENT.
 
In this case, I just set a flag in the Error ISR and I'm clearing the BUS in the main loop.

 
/* I2C Error ISR */
 
void __ISR(_I2C1_BUS_VECTOR, ipl1AUTO) _IntHandlerDrvI2CErrorInstance0(void)
{
    SYS_ASSERT(false, "I2C Driver Instance 0 Error");
 

    IFS3bits.I2C1BIF = 0;
    i2c_error = true;
}
 
 
 
/* Clear error in main loop */
if (i2c_error == true)
{
    DRV_I2C_OBJ *dObj = (DRV_I2C_OBJ*)sysObj.drvI2C0;
    SYS_INT_SourceStatusClear(dObj->mstrInterruptSource);
    DRV_I2C_Bus_Clear (sysObj.drvI2C0);

    if ( (PLIB_I2C_BusIsIdle(dObj->i2cId)) &&
    (!(SYS_INT_SourceStatusGet(dObj->mstrInterruptSource))) )
    {
        _DRV_I2C_InterruptSourceEnable( dObj->mstrInterruptSource ) ;
        _DRV_I2C_InterruptSourceEnable( dObj->errInterruptSource );
        dObj->task = DRV_I2C_TASK_PROCESS_STOP;
    }
 
    i2c_error = false;
}
 

With the above workaround the I2C driver restart working from the next queue item.
 
2) Sometimes the I2C driver stop working without any error (Error ISR is not triggered). The I2C driver seems stopped within the task DRV_I2C_TASK_PROCESS_READ_ONLY.  In this case I'm doing manually trough USART terminal the following actions just to test if there is a way to restart it:
 
a) Setting the i2c_error variable to true, so that bus is cleared in the main loop, but this action is not enough, the driver does't restart.
b) Call manually one time the DRV_I2C_Tasks function - DRV_I2C_Tasks(sysObj.drvI2C0).
 
With the second action the I2C driver start working again. Now I think that a timer that will check if a queue item operation is timed out, could solve the problem just clearing the BUS and triggering the task function once.
 
The the DRV_I2C_Bus_Clear function should be non blocking, maybe it should be inserted in the DRV_I2C_Tasks.
 
I'm going to do something in this direction soon..
post edited by Johnny0099 - 2017/06/03 10:20:26
#34
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/06/05 09:37:54 (permalink)
0
I see that Microchip is removing Hardware I2C from new MCU. What's happening?
#35
CinziaG
die fucking humans
  • Total Posts : 3145
  • Reward points : 0
  • Joined: 2016/12/07 14:20:36
  • Location: Wien
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/06/05 09:40:28 (permalink)
0
Johnny0099
I see that Microchip is removing Hardware I2C from new MCU. What's happening?




really?? Smile

in 2018 you signed for your annihilation. in 2019 it will come ;) I promise
my most wonderful creations here
https://www.youtube.com/c...dPFRvtwsbSTXp6Sk6azGOQ
#36
Mysil
Super Member
  • Total Posts : 3476
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: online
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/06/05 11:29:24 (permalink)
3 (1)
Hi,
I see that Microchip is removing Hardware I2C from new MCU. What's happening?

 
Have observed the same, but do not know any real answers, nor have I seen any reasoning. 
For PIC32MM, I did regard omitting the I2C as a deliberate simplification.
That device does seem to be designed as minimalistic, and I2C include some requirements that may be troublesome in connection with PPS remapping.
There is a start of a bitbanging I2C implementation on the PIC32MM documentation webpage,
and Driver API for Master mode operations, compatible with MCC drivers for other MCC devices, 
in a thread I started. http://www.microchip.com/forums/FindPost/989704
 
For the new PIC32MK device, it seem more like they thrown in some copy of what is in MZ, 
but didn't get it to work, and just gave up for the time beeing.
 
I haven't looked into what the DA chip may promise.
 
   Mysil
#37
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/06/05 11:44:30 (permalink)
3 (1)
No Hardware I2C on PIC32MK
 
http://ww1.microchip.com/downloads/en/DeviceDoc/60001402D.pdf
 
Just these notes on some PINS
 
6: The I2C Library is available in MPLAB Harmony. For future hardware or silicon compatibility, it is recommended to use these pins for the I 2C master/slave clock. (i.e., SCL).
 
7: The I2C Library is available in MPLAB Harmony. For future hardware or silicon compatibility, it is recommended to use these pins for the I 2C data I/O, (i.e., SDA).
#38
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/06/07 12:09:15 (permalink)
0
@GDA, any new idea/suggestion on how to go ahead on I2C driver improvement/debugging?
#39
Johnny0099
Super Member
  • Total Posts : 157
  • Reward points : 0
  • Joined: 2015/06/20 00:33:20
  • Location: 0
  • Status: offline
Re: Harmony 2.03b I2C issue PICMZ - Silicon Errata 2017/06/11 05:11:07 (permalink)
0
I received some PIC32MZ2048EFM100 Rev. A3 and will test next week if things are going better than A1, but I'm pretty sure that this will not solve my issue.
 
I'm trying also to solve by modifying I2C driver, but I still don't have a stable workaround at this time..
#40
Page: < 123 > Showing page 2 of 3
Jump to:
© 2019 APG vNext Commercial Version 4.5