• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 78 subscribers
  • Views 1421 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

1MHz dco calibration value halts clock?

digdoug
Prodigy 70 points
Other Parts Discussed in Thread: MSP430F248

I've recently run into an issue on one particular msp430f248, out of several production devices, that halts when I set the DCO using the 1MHz cal values.  I've inspected/captured the InfoA ROM and it's values look reasonable 0x86(BCSCTL1) and 0xDA(D0CTL).

If I single step the assembly the JTAG session dies when D0CTL is written.  It looks like the clock stops altogether, and I can't get it back until I reset the processor.  

Has anyone else seen this? Do i just have a bad proc?

Thanks

  • 0
    Guru 74080 points

    Digdoug,

    there is something in the errata about the DCO:

    www.ti.com/.../slaz182h.pdf

    Try to set DCOCTL to 0 before loading the constants.

    Don't know if that is your problem, too, but you can give it a try.

    Otherwise you could try setting the DCO yourself and look if that works. Just for testing.

    Dennis

  • 0 in reply to Dennis Eichmann
    Prodigy 70 points

    Dennis, thanks for pointing that out.  It is/was the BCL12 issue.  That issue seemed weird enough I'm surprised I din't recognize I was in Errata-Land.

  • 0 in reply to digdoug
    Guru 74080 points
    Digdoug,

    how do you have solved it now in your code?
    Please post your lines of the configuration. Others will benefit from it.

    Dennis
  • 0 in reply to Dennis Eichmann
    Prodigy 70 points

    When I do get around to addressing the issue I'll share what I can.

  • 0 in reply to digdoug
    Prodigy 70 points

    It's quite simple, just follow the workaround to the letter.  In C it's just a couple lines, assembly a few more.  I can't post code I've implemented, but it's basically the following:

    // check to see if RSEL is greater than 13.. if so then set it to 13 before loading the new value

    if ((BSCTL1 & 0xFF) > 13)

    BSCTL1 = (BSCTL1 & ~0xFF) | 13

    BSCTL1 = CALCBC1_XMHZ 

    It seems likely you'll run into it if you set RSEL more than once.  If you only set it once then it's unlikely you'll see it since RSEL comes up as 0 from a reset and this issue is only when you transition RSEL from a value greater than 13 to one that's less than 13.

  • 0 in reply to digdoug
    Guru 12050 points

    One too many F's, Rsel is the 4 lowerbits
    And as you have to make sure the bit change is atomic, eg the compiler does not do any intermediate value except 13
    and if you want to leave the upper 4 bits alone, if think my solution below is the only way.
    You would only need to do the code below If CALBC1_1MHZ <13

    if  15:  1111
    or 14: 1110
    to 13: 1101

      char  i = BCSCTL1 & 0x0F;
  if (i == 15)
  BCSCTL1 &= ~BIT1;                // set it to 13
  else if (i == 14)  
  BCSCTL1 ^= BIT0+BIT1;            // set it to 13
  BCSCTL1 &= ~0x0f                 // now clear it to 0
  BCSCTL1 |=  CALBC1_1MHZ_ &0x0F;  // merge in the calibrated value

compiles to:
 00C02C    425E 0057          mov.b   &BCSCTL1,R14
 00C030    F07E 000F          and.b   #0xF,R14
 00C034    907E 000F          cmp.b   #0xF,R14
 00C038    2003               jne     0xC040
 00C03A    C3E2 0057          bic.b   #0x2,&BCSCTL1
 00C03E    3C06               jmp     0xC04C
 00C040    907E 000E          cmp.b   #0xE,R14
 00C044    2003               jne     0xC04C
 00C046    E0F2 0003 0057     xor.b   #0x3,&BCSCTL1
 00C04C    F0F2 00F0 0057     and.b   #0xF0,&BCSCTL1
 00C052    D0F2 000F 0057     bis.b   #0x4,&BCSCTL1

  • 0 in reply to Tony Philipsson
    Prodigy 70 points

    You're right on.  I'd implemented my fix in assembly as part of a bootloader and just threw out the "C" code in my last post without fully thinking it through.  You're totally correct about the change being atomic.   I pulled BCSCTL1 into a register and worked on it from there so when I pushed it back it was an atomic change. 

**Attention** This is a public forum