In fact I've removed the onboard accelerometer and tried without it, but nothing changed. And there is no other I2C0 pin on the header. I guess your last codes are not necessary as you mentioned. Because if you don't declare them as I2C then they should be straight GPIO natively. (or not?)

I just checked RM for I2C0 pins and there are
I2C0_SCL
PTE24
PTB0
PTB2
PTC8

I2C0_SDA
PTE25
PTB1
PTB3
PTC9

Although I agree with you that unless the pin is defined as I2C0, it should not bother us.
But just in case, explicitly defining suspicious pins to other function or disabling them won't cost us a lot.

Also, when I activated the MMA8451Q via PTE24/25, over writing the program did not fix the situation
and I had to plag out/in the USB cable to cold start my FRDM-KL25Z board.

Yes I've noticed that after Eric's last comment.. :) And tried with PTB1/PTB2 pins. But nothing changed!!!! I dont know, I am very confused about that! I2C0 channel is not working definately.. Thanks for the answer..

I think some/many/most MCUs won't reset their peripheral registers to default values on just a software reset. So if one GPIO is set to the I2C, it will stay set to that until it gets a power-on reset or explicitly set to something else. But that should not be the issue here.

I double checked with my board. And as Ozgur-san noted, re-defining PTE24/PTE25 for GPIO was not necessary. With on-board MMA8451Q intact, my board is accessing MAG3110 via PTC9/PTC8.
So the good news is, yes PTC9/PTC8 can be used as I2C0 on FRDM-KL25Z.
The bad news is something wrong might have happened on Ozgur-san's FRDM-KL25Z board.

Sadly also not the answer, since the poster does not see any communication. In addition that issue is currently in the errata sheet of the KL25z, and the mbed library uses the official 'workaround' to make it work properly for the user.

Yes this is a copy-paste error. Actually its I2C i2c(PTC9, PTC8); I2C i2can(PTE0, PTE1).. I tried with just PTC9 - PTC8 and it did not work. I tried both the newest mbed lib and the old one (which works with LPC1768). With the newest library it hangs at least 2-3 seconds while reading I2C0 channel, after that it reads (or skipped I guess) always 0. With the old library (December 2013 dated not know the revision number) it doesnt hang but reads 0 always. I have no logic analyzer but as I can see in my oscilloscope there is no signal acitivity both SDA or SCL channel..

Can you verify that the DC levels are indeed correct on those pins, and that you are connecting the correct pins? (It sometimes happens you got your pins shifted one location).

Reason for asking is that it might be different in newer version that it timeouts different when bus seems busy: When there are no pull up resistors the bus will always seem to be busy.

In fact I am already suspicied about that issue. Because I had to pull up to 5v (not 3v3) LPC1768's I2C pins to work with these sensors; http://tr.mouser.com/ProductDetail/GE-MC-NovaSensor/NPA-700B-10WD/?qs=sGAEpiMZZMvhQj7WZhFIACCBXe74v8hwY%2ftuWhLlA3E%3d However I am not sure that KL25Z pins are 5v tolerant or not..

KL25 pins are NOT 5V tolerant. I don't think that it is currently your issue, although they could have broken already, often they survive for quite some time overvoltage situations.

However obviously that isn't something you want in a product. It does show on the mouser page it works on 3.3V too.

No, if you use 3v3 then they should be recalibrated and its impossible for low counts of purchases. Anyway, it cannot be the signal level problem because the other channel works (I2C1) perfect. Do you think PTE0/PTE1 pins have different logic voltage levels than the others?

The signal level issue could have physically broken those pins. For a product you will either need a 5V tolerant MCU, or a level shifter.

Here you can find the complete pinout: http://developer.mbed.org/users/mbed_official/code/mbed-src/file/fc4922e0c183/targets/hal/TARGET_Freescale/TARGET_KLXX/TARGET_KL25Z/PeripheralPins.c, can you try other pins?

I've tried I2C0 with PTB1-PTB2 pins but still doesn't read the sensor while I2C1 channel is reading the same sensor.. I am tired about that! I guess I will continue with LPC1768 ...:(

Dear Eric,; Do you think the sensor could kill my KL25Z's I2C0 channel (because of it works with 5v) ? Just an idea..!

No that can't be it. It could kill the pins it is connected to, but not the I2C channel itself, there are buffers in between which will prevent that from happening.

So while technically it is possible that you are really lucky that one channels keeps working while the other one does not work, I consider it to be very unlikely.

To be fair I have no idea what could be the problem now. (Unless it would be the overvoltage). I was going to test it later today myself, but Motoo already did it, and it should just work. You are not using any other I2C than those two? Did you try it with a very simple program? (So nothing besides just the I2C).

I've done whole these tests with only a I2C reading code..Not more.. May you share the test results please..

Well Motoo already shared his results: Worked fine.

Do you have a second KL25 you can use for testing?

I HAD some more KL25Z's and before this last one I tried with all of them.. (not worked) Propably all my KL25Z's are now without I2C0 ch.. .. Ok never mind, KL25Z adventure is finished for me. Thanks a lot for helps..