10 years, 3 months ago.

mbed build 77+ and RTC on KL25Z

Hello,

It seems like the RTC no longer works on the FRDM-KL25Z after mbed build 77. Build 76 works.

...kevin

Looking at the build numbers that might be my mistake. Will have a look at it tomorrow and report back :)

posted by Erik - 28 Feb 2014

Thanks Kevin Braun for reporting.

Keep us, Erik, informed.

Regards, 0xc0170

posted by Martin Kojtal 01 Mar 2014

Eric,

Per your lengthy explanation in the "green" section below, I will remove the MMA8451Q from one of my KL25Z boards to help narrow which IC may be the problem. That will leave no other devices on the I2C busses except the CPU. It will take a couple of weeks however, since the person I use for rework is out on holiday.

...kevin

posted by Kevin Braun 05 Mar 2014

2 Answers

Kevin Braun
poster
10 years, 3 months ago.

Hi Erik,

Here is a link to some sample code, I hope you can access it.

http://mbed.org/users/loopsva/code/KL25Z-rtc_i2c-100/

Notes: 1. This code runs fine with mbed build 76, but not 77. The RTC is fixed with your mbed-src-rtc build

2. The RTC code just checks for the RTC to increment between power up and 1.5 seconds later. If the count doesn't increment -or- a count that is way too low because of a power failure, I considered the RTC not working. I do initialize the RTC to Jan 1 2012 if it detects a failure. Though stripped out of this sample, I do have other code that properly sets the correct time and date.

2a. What I am seeing is that the RTC does not increment after 1.5 seconds, creating the failure.

Very important!! Once the i2c is broken and you want to go back (i.e. switch from 77 back to 76), you have to power cycle the KL25Z. It seems that once the i2c in the KL25Z gets in this mode, it cannot be undone until you remove power.

I am using TeraTerm at 115200 baud.

...kevin

Accepted Answer

Access denied, did you publish it as private? It must be public (non-linked is fine).

Edit: Or with me specifically given access, although I haven't used private myself before, so dunno where the option is.

Also had another look at the I2C code, and I cannot find a single line which changed in those revisions (the structure changed, but the actual code not). So I would guess it is due to something else, but not a clue what it could be atm. Maybe with your code I can reproduce it.

posted by Erik - 03 Mar 2014

I did. This one is public, but not broadcast to the world

http://mbed.org/users/loopsva/code/KL25Z-rtc_i2c-100a/

...kevin

posted by Kevin Braun 03 Mar 2014

Thanks Erik,

I believe that I forgot to power-cycle my KL25Z after loading the mbed-src-rtc library. All is well now.

...kevin

posted by Kevin Braun 03 Mar 2014

Imported it. I assume you are using a Wi-Go? That is easy since I got it too.

Now the hard part, finding the reason. I had just written that it worked fine for me, until I resetted it once more, and it indeed showed getting an ACK on all addresses.

However since I had to reset it a couple of times I tried with the old mbed lib again, and resetted it, and again, and again, and again, and it took some more resets, but in the end same behavior, ACKs on every single address.

So now I am 98% certain it is once of the ICs getting confused and happily ACKing everything. Especially since a power reset is required to fix it again. Now the question, while it does happen to me with both revisions, it certainly happens more often with the latest one. I tried increasing delay between addresses, but that didn't help.

I don't know exactly which revision, but recently also the compiler was switched to maximum optimizations. I can imagine this slightly speeds up when for example a stop command is sent over the bus, increasing the chance it goes wrong.

My current verdict is: one of the ICs is to blame. It happens with both versions, but definately more often with the latest version. A check with a logic analyser can give us more insight, but I don't have one.

Aditionally it seems to be accelerometer on the KL25, which my test showed to do the opposite: stop responding after read command followed by nothing (or at least with RW bit 1, dunno which one that is). But while the opposite, it is also unintended behavior. So I am going to blame the IC. Finally I also just put the baudrate at 10kHz of the I2C port, while obviously not ideal, this does seem to fix the issue. Also instead of writing nothing, writing 0 as single data byte has a different result: Then after a couple of resets it doesn't respond on any address anymore (same as what I observed before, but I didn't send a data byte with it, also sending random data byte is bad).

So the third TL;DR (this window is too small to see what I wrote before): The accelerometer looks to be the cullprit. There is a difference between library versions, but this might be optimization settings. A logic analyser plot couldn't hurt, but without one I currently don't think the code itself is to blame, and without for example a logic analyser showing something is too fast, I won't add delays into the mbed code. (Not even sure that would fix it). Oh and Kevin hasn't exactly mastered making a subtle effect with LEDs, make the blinking stop :P

posted by Erik - 03 Mar 2014
10 years, 3 months ago.

Kevin,

The bad news is that I have not been able to reproduce your issue, it works fine for me. The good news is that I did find an error, which might result in your problems. But before I create a pull request to fix that I like to be sure that this is the issue.

So can you delete your mbed lib from your program, and import: http://mbed.org/users/Sissors/code/mbed-src-rtc/. Apparantly I misread the user manual, and the RTC input pin on the KL25Z and KL46Z is on the wrong function: I2C instead of RTC input. The weird part however, and why I didn't find it when testing, is that in my tests this has no influence whatsoever. Even when I enable the relevant I2C peripheral and use it, it seems to work fine.

Still it is an error and it doesn't work for you (you might even have a different revision of the KL25 itself), but I cannot verify myself that this is the issue which prevents it from working for you. So if you could check if this solves it and report back it would be appreciated :)

Erik

Hi Erik,

Very interesting. I also ran into an i2c issue at the same time the RTC stopped working. At the beginning of my code, I run through a simple routine that does a single byte write at each i2c location (0x02, 0x04, 0x06...0xfe) to look for an i2c device ACK - on both i2c busses. I use this routine on the KL25Z, the LPC4088QS and LPC1768 boards I have. This broke on the KL25Z at the same time as the RTC (I have not checked the other 2 boards types I have). My routine now sees every address as valid, not just the attached devices.

Your latest build does fix the RTC issue I was having, but the i2c issue is still there. I have just tried this fix on a second, brand new KL25Z with the latest mbed bootloader. For now, I'm sticking with mbed build 76.

...kevin

posted by Kevin Braun 01 Mar 2014

Could you post code you use? I just tried the following:

#include "mbed.h"

DigitalOut myled(LED1);
I2C test(PTE25, PTE24);
int main() {
    unsigned char i = 0;
    int retval;
    while(1) {
        test.start();
        retval = test.write(i);
        test.stop();
        printf("Add %d = %d\r\n", i, retval);
        i = i + 2;
        wait(0.02);
        
    }
}

Only that I2C bus since that one has the accelerometer including pull-up resistors. Two things I noticed: if I also do address 59 (58 is write address, 59 read, or other way around), it fails to respond in the next cycle. But I assume that is just the IC getting confused.

But it nicely responds to only 0 (general call), and 58 (its address), everything else no ACK. So could you post code which has that behavior?

Regarding RTC, I made pull request on the mbed github, should be soonish on mbed-src, regular mbed whenever that one has a new version.

posted by Erik - 01 Mar 2014