RTC and I2C drivers Thread-Safe?

[joepasquariello]

Hello, We're using the MOD5213, the NB-standard Intersil RTC, and the NB RTC functions. My question is whether it's okay for more than one task to do clock reads and/or writes? Our main task does clock reads, and a serial communication task does clock write-then-read when a SetTime command is received.

We've seen a strange problem where the RTC on some boards have become "stuck", reporting the same time, and we're unable to set the time. The RTC functions are returning no error (0), and I checked and made sure that the DetectRTC() function was correctly identify the RTC as Intersil and not as NXP. The problem will persist through many reboots and attempts to set the time, and then will mysteriously go away.

Any ideas will be greatly appreciated. Using NNDK 22 rc2.

Joe

[Ridgeglider]

No, by themselves the i2c calls are not thread safe and need to be protected, typically with an OS_CRIT section, or an OSCritObj. If you search this forum for OS_CRIT you will see examples. Also, see C:\Nburn\docs\NetBurnerRuntimeLibrary\uCOSLibrary.pdf, or the OSCritObject Example in Section 15.1.5 of the NNDKProgMan.pdf at C:\Nburn\docs\NetworkProgrammersGuide. You can also use semaphores to implement these locks, but I think the OS_CRIT approach is better.

[thomastaranowski]

The I2C IO calls are also relatively slow, so I would not put them inline with your mainline logic. I would recommend isolating them in another thread which periodically updates a database/variable, which you can query quickly from your main application. Better yet, isolate all of your i2c calls in a single thread, that way you don't have to worry about thread safety, and minimizes locking.

[joepasquariello]

Thanks for your quick responses. I will go ahead and create a clock task. That seems like the cleanest and most reusable approach. Do either of you have an opinion on whether the strange behavior I'm seeing could be due to the non-safe way in which we've been writing to the RTC registers? I know you can't know for sure, but it's very strange, and I haven't been able to come up with a model for how an I2C conflict like this could explain the behavior.

Joe

[Ridgeglider]

Pragmatically, you can virtually guarantee that if one task is reading over i2c while another is writing then data will be corrupted. If so, I wouldn't begin to speculate about "stuck" clocks or other symptoms. Fix what you know is an issue.

On a sort of related note.... No matter what you do, rtc calls will be slow because they use i2c. What I do is to use the system time which can be read very quickly. When the system boots, I sync the system time to the RTC. Thereafter, about once an hour (from within a houskeeping task) I resync system time to the RTC. Since the rtc is only accurate to a second, there is no way the system will drift that far in an hour although it will eventually stray in a day. The result is a fast but accurate way to keep track of time with much less overhead.

[joepasquariello]

Ridgeglider,

I implemented an RTC task for the MOD5213, and it works quite well. Althought I haven't specifically reproduced the problem seen in the field, I'm pretty sure now that it was due to my un-thread-safe use of the I2C via the RTC calls. Others using MOD5213 might find this task useful. Is there a place to post files?

Joe

[Ridgeglider]

This forum does not have a separate "files" post section, although you can easily zip your work and attach them as a post to this thread. Another much less used but possible place is the NB wiki http://wiki.embeddedethernet.com/Main_Page