I'm on a MOD54415 and starting to implement my RTC capabilities. I'm using a PCF8563 I2C RTC chip which is supported in the RTC lib.
I'm using I2C2 for all my I2C needs here. I've got other I2C stuff running without issue but am having issues talking to the RTC using the lib call. Digging in deeper, as I was guessing it looks like it isn't using any of the Multichannel_I2C functions so I'm guessing this is all expecting it to be on I2C0?
If so, has this already been updated in newer NNDK or expected to be soon (couldn't tell from the Release Notes)? I'm on NNDK 2.6.7.
Is there any other easy solutions other than just pulling all the code into my app and changing it?
Thanks.
Scott
RTC I2C lib issue
Re: RTC I2C lib issue
<crickets..>
Okay so now that I've got NNDK 2.7.1 running I'm still seeing the same issue here. Digging further I've changed multichanneli2c.h to have #define DEFAULT_I2C_MODULE (2) so that should reference I2C2 as the default and recompiled system libs.
Sprinkling a few iprintf statements in DetectRTC() in RTC.cpp I find that it always returns (0) instead of return (2) for the NXP8563.
If I pull DetectRTC() into my own code and localize it just by prefixing the call and vars with "z" then I find that it always reliably detects the RTC chip and does a return (2).
I've even removed the I2CInit() call from my local zDetectRTC() function to make sure that the re-init in local code wasn't masking an issue. Nothing changed.
So does this mean that the RTC libs for I2CStart(), etc are not respecting the DEFAULT_I2C_MODULE define?
Thanks.
Scott
Okay so now that I've got NNDK 2.7.1 running I'm still seeing the same issue here. Digging further I've changed multichanneli2c.h to have #define DEFAULT_I2C_MODULE (2) so that should reference I2C2 as the default and recompiled system libs.
Sprinkling a few iprintf statements in DetectRTC() in RTC.cpp I find that it always returns (0) instead of return (2) for the NXP8563.
If I pull DetectRTC() into my own code and localize it just by prefixing the call and vars with "z" then I find that it always reliably detects the RTC chip and does a return (2).
I've even removed the I2CInit() call from my local zDetectRTC() function to make sure that the re-init in local code wasn't masking an issue. Nothing changed.
So does this mean that the RTC libs for I2CStart(), etc are not respecting the DEFAULT_I2C_MODULE define?
Thanks.
Scott
Re: RTC I2C lib issue
Anyone from Netburner? Dan? Paul?
The issue is that in rtc.cpp it has #include <i2cmaster.h>. It needs to be #include <multichanneli2c.h> to properly use the #define DEFAULT_I2C_MODULE (2) for I2C2.
Can this be updated so going forward we aren't having to modify lib files? Since rtc.cpp is already target specific (C:\nburn\MOD5441X\system) it wouldn't seem like that would cause issues for other platforms.
Thanks
Scott
The issue is that in rtc.cpp it has #include <i2cmaster.h>. It needs to be #include <multichanneli2c.h> to properly use the #define DEFAULT_I2C_MODULE (2) for I2C2.
Can this be updated so going forward we aren't having to modify lib files? Since rtc.cpp is already target specific (C:\nburn\MOD5441X\system) it wouldn't seem like that would cause issues for other platforms.
Thanks
Scott
Re: RTC I2C lib issue
Got back to Scott here on support. I was hesitant to do this because of conflicts where people were using both the rtc and multichannel drivers separately, but then I remembered there's a check for the multichannel and master drivers to see whether other drivers are installed, so this would be a non-ussue.
I'm going to update the mcf54 platforms to use the multichannel drivers and the non 54 platforms to continue to use the master driver. This will ensure someone whose code was written ages ago (software wise, realistically, it can't have been more than a few handfuls of years) can still update their nndk release and rebuild without any new problems, but people who are building new applications with the mcf54 platform will have to more consciously use the multichannel drivers. If you've written code with the multi and master drivers before, everything should still work, you'll just need to change the define.
I'm going to update the mcf54 platforms to use the multichannel drivers and the non 54 platforms to continue to use the master driver. This will ensure someone whose code was written ages ago (software wise, realistically, it can't have been more than a few handfuls of years) can still update their nndk release and rebuild without any new problems, but people who are building new applications with the mcf54 platform will have to more consciously use the multichannel drivers. If you've written code with the multi and master drivers before, everything should still work, you'll just need to change the define.