1
\$\begingroup\$

How do I access the subsecond counter (1/256 second) on the MAX32660 rev A2?

I tried reading MXC_RTC->ssec, when busy=0 and ready=1, as suggested in Chapter 9 of the user guide, but this register has a mostly useless value (lower 8 bits of a 4096Hz counter, apparently). For example, reading it at 32Hz, the subseconds change by 128 units at each measurement, instead of the expected 8 units:

02183058us seconds=75564, subseconds=095, busy=0, ready=1
02214244us seconds=75564, subseconds=223, busy=0, ready=1
02245431us seconds=75564, subseconds=095, busy=0, ready=1
02276617us seconds=75564, subseconds=223, busy=0, ready=1
02307804us seconds=75564, subseconds=095, busy=0, ready=1
02338989us seconds=75564, subseconds=223, busy=0, ready=1
02370176us seconds=75564, subseconds=095, busy=0, ready=1
02401362us seconds=75564, subseconds=223, busy=0, ready=1

I am using the following struct definition from Maxim's SDK:

/**
 * @ingroup rtc_registers
 * Structure type to access the RTC Registers.
 */
typedef struct {
    __IO uint32_t sec;                  /**< <tt>\b 0x00:</tt> RTC SEC Register */
    __IO uint32_t ssec;                 /**< <tt>\b 0x04:</tt> RTC SSEC Register */
    __IO uint32_t ras;                  /**< <tt>\b 0x08:</tt> RTC RAS Register */
    __IO uint32_t rssa;                 /**< <tt>\b 0x0C:</tt> RTC RSSA Register */
    __IO uint32_t ctrl;                 /**< <tt>\b 0x10:</tt> RTC CTRL Register */
    __IO uint32_t trim;                 /**< <tt>\b 0x14:</tt> RTC TRIM Register */
    __IO uint32_t oscctrl;              /**< <tt>\b 0x18:</tt> RTC OSCCTRL Register */
} mxc_rtc_regs_t;

The errata sheet says zilch about RTC, so there cannot be hardware bugs.

Is there some switch to select the proper clock source for the subsecond counter, or am I reading the wrong register?

Update 1 I took the exact same code, but used it on the EVkit board with the system initialization code that came with the EVkit, and it is working properly: subseconds is 256Hz as expected. I still do not understand how the system init code can affect subseconds frequency.

Update 2 Same image as Update 1, but running on my custom board. subseconds is 4096Hz. I'm starting to like @Justme's theory about a hardware issue. The thing is though, if this is a problem with the crystal circuit, how come seconds is still 1Hz? This makes no sense.

Here are the possible relevant hardware differences:

  • EVkit: MXC_GCR->revision == 0xa1. Using this crystal (6pF version) on the board. seconds=1Hz, subseconds=256Hz (as expected).
  • My board: MXC_GCR->revision == 0xa2. Using this crystal (6pF version) on the board. seconds=1Hz, subseconds=4KHz (unexpected).

Given that both boards count seconds at 1Hz, I doubt that the crystal is at fault. The crystals are electrically very similar, and obviously both boards are getting accurate 32768Hz, even if in one case the subseconds register doesn't want to admit it.

Maybe I can order an a1 or desolder from the EVkit to try it on the other board...

\$\endgroup\$
4
  • \$\begingroup\$ It does not say anything about it being a low 8 bits of a 4096 Hz counter. Have you verifed with a scope that there is no hardware issue, like the oscillator ticking unreliably at some higher harmonic of 32768Hz? \$\endgroup\$
    – Justme
    Mar 31 at 19:31
  • \$\begingroup\$ @Justme Right, the datasheet suggests we should get bits 11.4 not bits 7..0. I still need to scope it, but, based on the seconds count timing, and the value from the 4096Hz counter, it is very reliably dividing the 32768Hz down to 1Hz. Just not giving me all of the counter bits that I need. Effectively I get bits 7..0 and 43..12 ony. (while the datasheet suggests that 43..4 should be fully accessible) \$\endgroup\$ Mar 31 at 20:28
  • \$\begingroup\$ But based on block diagram and register map, there is no 4096Hz counter you can read. I don't understand which registers you are reading and which way. You can only read the 256Hz sub-second count from SSEC and for safety you should use 8 least significant bits only. The whole seconds are stored in SEC which is a 32-bit register, so you get thus total 40 bits of count in 256Hz units. And the registers must be read when status bits indicate that the hardware is not updating the count. \$\endgroup\$
    – Justme
    Mar 31 at 20:48
  • \$\begingroup\$ @Justme Right, that is what the user guide says. Not what the part actually does. As I mentioned in the question, I am reading RTC_SSEC aka MXC_RTC->ssec (in the SDK). Yes, I checked the status bits. But it doesn't seem to make a difference whether I read the value when ready=0 or ready=1. In any case, synchronization issues of that sort would not explain the subsecond count frequency being 4096Hz instead of the expected 256Hz. \$\endgroup\$ Apr 1 at 2:18
0
\$\begingroup\$

I just noticed that A2 has its own errata sheet. There is specific text about the subsecond register:

Software reads of the RTSS register will always return RTSS[31:28] = 0000b. This only affects software reads, and software writes to those bits correctly. Hardware updates the full 32-bit counter correctly and the RTC alarm functions operate correctly. (ME11-161)

It's saying that 4 bits are lost, which is essentially what I'm observing. Although the text doesn't really make sense, since RTSS is not a 32-bit register, but an 8-bit field of RTC SSEC. So I'm not sure what RTSS[31:28] means. SSEC[31:8] is supposed to be 0/reserved, as I observe on A1 and A2. What's happening is actually that SSEC[3:0] is showing up in SSEC[7:4].

However, the fact that the errata calls out the specific register that I'm seeing the issue with, and that this shows up only on the A2 errata and silicon, but not A1 errata or silicon, makes it seem likely that my issue is related to this erratum.

Maybe there was a game of telephone? "Hey, Frank, when you're updating that errata sheet, can you note that the upper 4 bits of RTSS are read as zero". "Sure, Bob. How many bits is that register? Frank, which one, hunh? I'm on the phone. Oh what, registers, they're 32 bits. Bob, OK, I'll update the errata sheet. Thanks"

Now What?

So, we only get the lower 8 bits of the 4096Hz counter. Here's an algorithm we could use to infer RTC to subsecond accuracy:

  • on entering full power state, wait for the next second count, and immediately record cycle counter value and 8-bit 4096Hz value (which will be 0 initially). Extend the 4096Hz value to 44 bits by prepending the second count. I.e., {seconds, 12'0}
  • at later times, again record the cycle counter value and the 8-bit 4096Hz value. Use the last cycle counter delta to infer a 44-bit 4096Hz value. Round this to the nearest 44-bit value matching the recently recorded 8-bit 4096Hz value. The rounded value is accurate if the inter-clock drift since the last measurement is <30ms.

The 1s wakeup time is unfortunate. Hopefully Maxim aspires to fix the issue one day, perhaps by allowing people to purchase A1 chips. A2 does not fix the biggest issue with A1 (namely, broken UART rx) and seems to introduce at least 2 bugs in RTC (subsecond count, and trim).

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.