Looks like KSDK HAL triggers it, but can't find that line in the header file.

The only relevant code in the current implementation (latest mbed SDK sources):

    if ((config->bitsPerFrame < 4) ||
        ((config->bitsPerFrame > 16) && (HW_SPI_MCR(baseAddr).B.MSTR == 1)) ||
        ((config->bitsPerFrame > 32) && (HW_SPI_MCR(baseAddr).B.MSTR == 0)))
    {
        return kStatus_DSPI_InvalidBitCount;
    }

Thats SPI, this is the I2C code ;)

Thanks, Eric, that path doesn't exist on my PC. I had actually initially ignored it since I assumed it was a remote path of some kind. :) I'm using the mbed-official I2C library. I'll check to see which version I'm using. Thank you for the suggestion!

Oh wait, I was just assuming you were working offline since I was doing that when I got that one, but thats the path the mbed online compiler uses :P. Still you can use it in the mbed-src to find the file. But the question is more when that function is being called.

But could you post the code you are using? At least regular mbed releases get automatically tested on a whole bunch of stuff, including I2C. Now you can have found an unhandled situation (for example I don't think there is a test for wrong slave address supplied), so it might be useful to post your code and setup :).

I'm using a BlinkM module from Sparkfun, and am just calling my SetRgb method:

bool BlinkM::SetRgb( uint8_t r, uint8_t g, uint8_t b)
{
    _i2cmgr.SelectDevice( this);
    char data[4] = { 'n', r, g, b };
    _i2cmgr.write( _device_address, data, 4);
    _i2cmgr.DeselectDevice( this);
    return true;
}

device_address is 0x12. The I2cManager class that is referenced merely handles locking of the I2C bus so that no two devices can try to write to the bus at the same time. I2cManager inherits from I2C.

I just realized that I failed to check the return value from write, not that that would matter in this case, but I should add that.

I also have multiple I2C devices on the bus. If I remove the BlinkM call, the other I2C devices seem to have no issues being polled. If I add the BlinkM, then it freaks out. I never had this problem until I started to send that module commands in a tight loop. Maybe it's that particular device in this specific use case. I'll put it back in with a Thread::wait to see what happens.

It probably never arrives at that check, since I assume that that write goes wrong. Now it is already late, maybe I can check tomorrow some stuff, see if for example incorrect _device_address triggers it. Otherwise it becomes bit later. But in the meantime can you also check if it works with latest version?

And the folder structure is also there in the online compiler. Or if you want something bit more responsive/clearer, for example here on the site: http://developer.mbed.org/users/mbed_official/code/mbed-src/

Thanks, Eric, I will try that soon. I attempted to update yesterday, but the problem was that the latest version of the mbed library causes compilation errors with the EthernetInterface library. I'll trip out EthernetInterface and run the tests again later today. Also, thanks for the link regarding the folder structure. I only briefly tried to figure it out but the online compiler just says "Too many files" - hopefully the link you have provided explains what that's all about!