• AVR Freaks

Hot!PIC18F I2C clock selection problem

Author
Ragnar1138
New Member
  • Total Posts : 5
  • Reward points : 0
  • Joined: 2021/01/15 05:10:07
  • Location: 0
  • Status: offline
2021/01/20 05:30:47 (permalink)
0

PIC18F I2C clock selection problem

Hi all,
I'm working on a project that uses I2C. It all works fine - but I can only drive the clock at 100KHz. 
 
I used MCC to configure the project and used the default clock source - MFINTOSC. This correctly calculates and uses a 100KHz clock. Everything works fine - the application code is transmitting and receiving correctly and all the signal levels/timings are good.
 
However, I want to use a faster clock (e.g. 400KHz). The problem is that I cannot select the alternate clock sources mentioned in the datasheet for my microcontroller. If I try to use anything other than FOSC, FOSC/4, HFINTOSC, MFINTOSC or EXTOSC, I get an error - "xxxx clock source is not supported".
If I try to change the register settings manually to select a different clock source (e.g. TMR0), the project compiles but the I2C lines don't do anything.
 
Can anyone tell me how I can configure/use one of alternate clock sources (listed in MCC and the datasheets) to generate a 400KHz I2C clock?
 
I'm using a PIC18F47Q43 but I have the same problem if I try to configure any PIC18 that has the newer I2C modules (i.e. I2C is not part of MSSP). It seems that many of the clock sources listed in the datasheets cannot be used.
#1

11 Replies Related Threads

    Joel_C
    Junior Member
    • Total Posts : 28
    • Reward points : 0
    • Joined: 2019/12/28 14:13:53
    • Location: CT, USA
    • Status: online
    Re: PIC18F I2C clock selection problem 2021/01/20 16:21:09 (permalink)
    +1 (1)
    According to the PIC18F47Q43 datasheet there is a fast mode enable bit that must be set for 400 KHz operation.
    At start or reset this bit is set for 100 KHz operation. Have you set that Bit?
     
    Joel
     
    #2
    mbrowning
    USNA79
    • Total Posts : 1874
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: online
    Re: PIC18F I2C clock selection problem 2021/01/20 17:15:00 (permalink)
    +3 (3)
    I don't use MCC or Q43 (yet), but I do use K42's extensively and the I2C interface is identical. "fast" mode enable just changes the clock divider from 5 to 4. That's all the baud control you get within the I2C peripheral. The clock choice determines the rest, so with the MFINTOSC SCL goes from 100 to 125KHz in "fast" mode.
     
    To get 400KHz I use one of the timers or the CLKR set to 2MHz with fast mode disabled for 400KHz. The SMT could be used the same way. I've never tried the CLCs, and all the other clock sources are too fast (in my designs) for I2C.
     
    Again, I don't use MCC but I wonder if MCC is complaining that when you choose one of the other sources the SCL rate is too high. Set up CLKR for 2MHz output (div by 32 with HFINTOSC source) and select CLKR as the I2C clock source.
    #3
    Ragnar1138
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2021/01/15 05:10:07
    • Location: 0
    • Status: offline
    Re: PIC18F I2C clock selection problem 2021/01/21 05:19:33 (permalink)
    0
    Hi all,
    Thanks very much for the replies. The short answer is that I've tried that, and it doesn't help. Here's the long answer.
     
    The FME bit only seems to reduce the number of I2C clock source cycles per SCL period from 5 to 4. This does indeed increase the overall I2C clock frequency from 100KHz to 125KHz - but even that doesn't work as I have tried this before and failed.
    I retested your suggestion this morning just in case I missed something. I took my standard working code (configured to use MFINTOSC and an I2C clock of 100KHz) and enabled the FME bit. MCC shows that this increases the I2C clock frequency from 100KHz to 125KHz as per the calculations in the datasheet. I compiled and programmed this to my PIC18F47Q43 (on a Curiosity HPC board) and I2C stopped working - no clock pulses or data. What is even stranger is that I then can't get the I2C to work even if I undo this change (i.e. disable FME).
    Luckily, because I had seen this strange problem some time ago, I took a copy of my entire project before enabling FME. This allowed me to restore a working copy. It appears that enabling FME prevents I2C from working at all and the change is irreversible. I could do a DIFF on all the files in the project before and after enabling FME to investigate - but I chose not to do this as I want to concentrate on why I can't select an alternate I2C clock source in MCC.
     
    I did some more testing this morning that may help. I wanted to find out if I could change the I2C clock rate by other means - to confirm that I2C will clock at a higher frequency with the limited clock sources available. I was able to get a 400KHz I2C running - but at a price.
     
    My project uses HFINTOSC running at 64MHz as the system clock. It uses MFINTOSC (which I believe is 500KHz) as the I2C clock source - giving an I2C clock frequency of 100KHz.
    For the test, I slowed the HFINTOSC system clock from 64MHz to 8MHz and then changed the I2C clock source from MFINTOSC to Fosc/4. MCC correctly calculates the new I2C clock frequency as 400KHz. I compiled and downloaded this to the PIC and it worked fine - with the correct I2C 400KHz clock rate (note that FME is not enabled due to the problem I mentioned earlier).
    Although this works, it is not an option to me as it slows down the system clock from 64 to 8MHz - meaning it is no longer running fast enough for other sections of my design.
     
    From this I conclude that: -
    1) There doesn't seem to be anything wrong with the I2C peripheral clock - it will run at 100KHz or 400KHz as required
    2) My problem is not related to the I2C clock rate - it is that I am not able to select the alternate I2C clock sources as listed in the datasheet.
     
    To clarify:
    I can only select the following I2C clock sources: - Fosc, Fosc/4, HFINTOSC, MFINTOSC, EXTOSC.
    I cannot select the following I2C clock sources: - Clock reference output, TMR0, TMR2, TMR4, TMR6, SMT1 overflow, CLCnOUT.
     
    Please can someone try selecting these clock sources in MCC in case I'm doing something wrong? I've tried with a number of different PIC18Fs (the ones with a dedicated I2C module - not part of the MSSP module) and I get the same results.
    Following on from mbrowning's post, I configured a test project using a PIC18F47K42 - I have the same problem as above. On the K42, I can only select Fosc, Fosc/4, HFINTOSC, MFINTOSC, EXTOSC as the I2C clock source. All others result in the "xxxx clock source is not supported" error,
     
    Thanks in advance.
    #4
    oliverb
    Super Member
    • Total Posts : 403
    • Reward points : 0
    • Joined: 2009/02/16 13:12:38
    • Location: 0
    • Status: offline
    Re: PIC18F I2C clock selection problem 2021/01/21 05:49:42 (permalink)
    0
    Was the appropriate timer component actually configured in MCC when you tried to select it? It seems as if the ones that worked are the ones that are intrinsically always present, and the "not supported" ones would all require you to set up the appropriate source in MCC separately.
     
    Also have you tried going to MCC register view and forcing the setting? It could be "not supported" simply because MCC can't auto-fill the divider because it doesn't know what frequency you are feeding it?
     
     
    #5
    mbrowning
    USNA79
    • Total Posts : 1874
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: online
    Re: PIC18F I2C clock selection problem 2021/01/21 06:04:27 (permalink)
    0
    I risked my mental health and started up the latest MPLAB-X and created a new MCC project. I turned on I2C and saw a warning when I selected a TMR or CLKR for clock source. But MCC happily set up the register correctly. Just ignore the warning and set the registers up and see what happens. Maybe it'll work. I know the device works without MCC.
     
    edit - I did have the clock source turned on in MCC, but found that setting the period on the timers didn't seem to work right. They are so easy to set up in code from the datasheet. MCC just seems to make everything harder.
     
    I confess I've never tried setting the FME bit cause I thought a 25% speed increase didn't make it "fast". I thought it was better to use the div-by-5 and adjust the source clock for the desired output freq. It surely must work or there would be an errata on it, right :)
     
    This experience reconfirms that I never want to use MCC for anything except maybe occasionally helping to determine some register settings.
    post edited by mbrowning - 2021/01/21 06:06:52
    #6
    Ragnar1138
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2021/01/15 05:10:07
    • Location: 0
    • Status: offline
    Re: PIC18F I2C clock selection problem 2021/01/21 06:25:01 (permalink)
    +1 (1)
    Hi all,
    Thanks again for the quick replies. Based on your input, I've just done some more testing.
    @oliverb: I configured TMR2 to run with a 2us period as this would give a 500KHz clock (same as the 'working' MFINTOSC). I then configured MCC to use this clock source. It complained and gave me an error - but it did configure the I2C clock registers correctly as per the datasheet.
    When I compiled and downloaded it, the I2C stopped working completely. I would have expected this to work OK as I'm driving it at the (default) 100KHz.
     
    @mbrowning: Agreed, I don't plan on using FME either. 400KHz would be fine for me and, if I wanted it to go a little faster than that, I'd just tweak the I2C clock source frequency - if I could only choose a different clock sourcewink: wink
     
    This infers that MCC is correctly stating that these clock sources are not supported - because they don't work. This goes against the information in the data sheet (and I couldn't see anything in the errata either).
     
    Any more thoughts? I'm a bit stuck now.
     
    #7
    Ragnar1138
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2021/01/15 05:10:07
    • Location: 0
    • Status: offline
    Re: PIC18F I2C clock selection problem 2021/01/21 07:36:46 (permalink)
    0
    @mbrowning: You mentioned that you use the K42's extensively. Have you been able (without using MCC of course) to configure a K42 to use I2C at 400KHz and get it working?
    If so, could you possibly share the register settings with me so I can compare these with the MCC generated settings for my Q43 to see if there is a difference?
     
    Because of the strange FME bit setting problem I mentioned earlier, I'm wondering if the MCC is missing something relevant when calculating the I2C register settings.
     
    Thanks.
    #8
    Jerry Messina
    Super Member
    • Total Posts : 666
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Status: offline
    Re: PIC18F I2C clock selection problem 2021/01/21 08:37:11 (permalink)
    0
    Even though the FME bit does have an effect on SCL, I think the purpose of the FME bit is to change the timing of the master state machine more so than changing the actual SCL freq. With FME=0 the master needs to detect the SCL state twice, while with FME=1 it only needs to see it once.
     
    #9
    Ragnar1138
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2021/01/15 05:10:07
    • Location: 0
    • Status: offline
    Re: PIC18F I2C clock selection problem 2021/01/21 08:47:00 (permalink)
    0
    Hi Jerry,
    Thanks for the reply.
    The FME bit just changes the bit timing of the I2C serial clock (SCL). Normally (FME = 0), one SCL period is equal to the I2C source clock divided by 5 - meaning a 500KHz source clock (e.g. MFINTOSC) would give an I2C clock frequency of 100KHz (500000/5).
    With FME = 1, the I2C clock source is divided by 4 instead - meaning the same I2C clock source (500KHz MFINTOSC) would give an I2C clock frequency of 125KHz (500000/4).
     
    My problem isn't related to the FME bit (I'm not using it anyway) - it is because I am not able to select (as an I2C clock source) a timer overflow, CLC output etc.
     
    #10
    mbrowning
    USNA79
    • Total Posts : 1874
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: online
    Re: PIC18F I2C clock selection problem 2021/01/21 09:03:13 (permalink)
    0
    Ragnar1138
    @mbrowning: You mentioned that you use the K42's extensively. Have you been able (without using MCC of course) to configure a K42 to use I2C at 400KHz and get it working?
    If so, could you possibly share the register settings with me so I can compare these with the MCC generated settings for my Q43 to see if there is a difference?

    See post#3
    void init_i2c1 (void) {
    // init T6 as source clock for I2C engine
        T6CLK        = 0x01;        // CLK = Fosc/4 (16MHz)
        T6PR        = 7;        // output=16MHz/(7+1)=2MHz (/5 = 400KHz SCL)
        T6HLT        = 0x00;        // pre not sync, rising edge, clk not sync, SW ctrl
        T6CON        = 0x80;        // T6 on, pre 1:1, post 1:1

    // init T4 as source clock for bus timeout mechanism
        T4CLK        = 0x06;        // CLK = MFINTOSC (31.25KHz)
        T4PR        = 156;        // output = 31250/2/157 = 99.52 (10ms)
        T4HLT        = 0x07;        // mode = free running with high level preset
        T4RST        = 0x00;        // SCL1 (pin selected by T4INPPS)
        T4CON        = 0x90;        // T4 on, pre 1:2, post 1:1

    // init I2C1
        I2C1CON0    = 0x04;        // mode 7 bit master
        I2C1CON1    = 0x80;        // ACKCNT=1(nack), ACKDT=0(ack), sck stretch allow
        I2C1CON2    = 0x00;        // ACNT=0 GCEN=0 FME=0 ADB=0 SDAHT 300n, BFRET=0
        I2C1CLK        = 0x08;        // CLK TMR6 post-scaled output (2MHz)
        I2C1BTO        = 2;        // TMR4 used for bus time out
        I2C1PIE        = 0;        // Clear all enables
        I2C1ERR        = 0;        // Clear all enables
        I2C1IE        = 1;        // enable all enabled PIR interrupts
        I2C1EIE        = 1;        // enable all enabled ERR interrupts
        I2C1CON0    = 0x84;        // I2C Enbld, mode 7 bit master
    }

    With very few exceptions, everything I have ever tried on any 8b PIC works according to the datasheet. If MCC does something that doesn't work, that means MCC doesn't work. The chip will if the code is right. All the clock sources I've tried work. If it's not listed in the errata sheet, it works.
     
    There are exceptions, and I did find a hardware bug on I2C1 on 56/57K42 involving the I2C specific slew rate bits (confirmed by Microchip, but still not in the latest errata). After almost 4 years on the market there is one minor errata on the K42 I2C, and that's not on the Q43 (which has a different minor errata).
     
    Frankly, I see on this forum a lot of people spending more time debugging MCC code than it would take to write the code from scratch just from reading the datasheet.
    #11
    Jerry Messina
    Super Member
    • Total Posts : 666
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Status: offline
    Re: PIC18F I2C clock selection problem 2021/01/21 09:11:18 (permalink)
    +1 (1)
    FME does change the freq slightly but that's not its main purpose. If you look at the master clock synthesis timing diagrams, with FME=0 it samples SCL twice, while with FME=1 it samples it once. It's not like you'd use FME thinking you'd be going from 100KHz to 400KHz or something.
     
    Didn't mean to get too OT... I haven't tried the other clock sources myself, so I'm interested in what you find.
     
     
    post edited by Jerry Messina - 2021/01/21 13:19:32
    #12
    Jump to:
    © 2021 APG vNext Commercial Version 4.5