• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 40 subscribers
  • Views 823 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3200 slow clock weirdness

tom dunigan
Prodigy 70 points
Other Parts Discussed in Thread: ENERGIA

I wanted to use slow clock interrupts to drive an entropy generator based on dueling clocks.  I wrote a small sketch to test slow clock. see https://github.com/manitou48/CC3200/blob/master/slowclk.ino

 In the sketch if i set the time delta (DTICKS) to 32768, then i get an interrupt every second.  all is good.  But for my entropy generator, i need faster interrupts.  Setting DTICKS to 32, i get no interrupts!! instead of an interrupts every millisecond.  If I set DTICKS to 128, the delay takes 12 seconds instead of 4 seconds, so somehow slow clock is messing with other firmware clocks!  WEIRD ???

Any thoughts? (tests were done with Energia)

I developed a proof of concept entropy generator whose bits pass the various NIST random tests, see

 https://github.com/manitou48/CC3200/blob/master/rng.ino

  • 0
    TI__Genius 16370 points
    Tom, Let me check you code and revert back.

    -/Praneet
  • 0 in reply to Praneet Kumar
    Prodigy 70 points

    thanks. I noticed that if I do back-to-back PRCMSlowClkCtrGet(), it requires 51 slow-clock ticks, that's 1556 us!! So trying to use a small DTICKS value won't work, cause the the slow-clock will have passed before the "setting" sequence is finished. But I still don't know why millis() time is slowed... though it could be the sketch's ISR routine is taking several milliseconds resulting in "lost" systick interrupts ... sigh

    EDIT: I added a 32-bit free-running timer and measured the duration of the ISR --sure enough, ISR is taking 2596 us.  Unless there is a way to adjust the ISR priority, we're going to lose systick interrupts, and thus lose milliseconds.  so it's weird that slow-clock API is so slow (OCR Off Chip Register).

    EDIT 2: I lowerd the priority on the slow clock PRCM interrupt,

    IntPrioritySet(INT_PRCM,INT_PRIORITY_LVL_2);

    that helped millis() to keep track of time, but delay() is still being "extended" by the ISR ?

    I can fix delay() by replacing it with   start=millis();  while(millis()-start < 4000);

    With that, I can use DTICKS=128 (interrupt every 4ms).  I tried using CPUwfi() in the while spin (low power delay), but that messed up Serial.print() ?  Presumably, delayMicroseconds() would still be "extended" by the slow clock ISR.  Lowering the PRCM interrupt priority is NOT a good general solution, as that interrupt needs to fire first on any wakeups.  Need to find a way to queue a lower-priority interrupt inside the slow clock ISR and have that lower priority ISR update slow clock alarm ... TODO.  

    See earlier discussion

    https://e2e.ti.com/support/wireless_connectivity/simplelink_wifi_cc31xx_cc32xx/f/968/t/403017