• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 78 subscribers
  • Views 578 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.

MSP430F5508/ 5522 startup and A/D errors

Henry Lehmann
Prodigy 170 points

All,

I am working on an assembly project in IAR using a 5-series MSP with USB.  At the moment, the program synthesizes a sine wave using data loaded in info memory and the DMA module.  I have observed the following:

1) The DMA does not run after a cold boot (<80mV on Vcore)

2) The timer that triggers the DMA does run like it should after cold boot, but does not actually trigger the DMA.

3) Using the FET debugger to diagnose the problem has been difficult, since I can't see what the register values are in memory while it is malfunctioning.  Applying a reset causes the CPU to run properly.

4) A work-around I have devised is to test the cause of the previous reset at the end of peripheral initialization.  If the cause was a software BOR, the program continues.  If not, I execute a software BOR using the appropriate bit in PMMCTL0.  After the restart and passing of the BOR-cause test, the program executes properly.

5) The problem seems tied to how quickly Vcc rises.  A slow rising Vcc doesn't cause the malfunction.  Our power supply on the board with the CPU can reach 3.3V in under 300us, compared to 30ms+ for the bench supply.

Since the software reset fixes the problem, I believe it is reasonable to think that there is not a bug in the code itself, as the problem would continue to repeat if there were.  I will have to get authorization before I can post a snippet of the code here for analysis.

What I really need to know is this: Is there a specific sequence required to ensure that all of the MSP's registers get written properly during code execution?

Thanks for the help!

  • 0
    Guru 227245 points

    The problem could be related to core voltage and CPU speed control. If the code starts after VCC has settled, fine. If it starts while VCC is slowly rising, fine, but if VCC is changing quickly, there seems to be a problem. What if you add a delay of ~1ms before configuring clocks and core voltage?

  • 0 in reply to Jens-Michael Gross
    Prodigy 170 points

    Jens-Michael,

    I tried to use varying lengths of delay (from 1ms up to 327ms)  at the very beginning of code execution, but that doesn't fix the problem.  To get the JTAG to read the values in RAM, I added this:

    [code]

    Trap   nop

               jmp     Trap

    [/code]

    to halt code execution where I wanted to check the RAM values.  This worked, but revealed that DMA0SZ wasn't written properly, reading as 0404h instead of 0028h as coded.  Occasionally other values would be incorrect as well.  What I did to work around the problem follows:

    [code]

    reset     mov #03400h, SP ; set up stack

    ;NOTE: WDT active 32ms
                 cmp #0006h, &SYSRSTIV        ; was cause of reset SW BOR? **
                  jz RunProg                                  ; if yes, continue w/ no BOR **


    ;Delay reset
                   mov #07D0h, R4                        ; 10ms delay **
    Delay    dec R4
                   jnz Delay
                  mov #PMMPW+PMMSWBOR, &PMMCTL0 ; ** BOR reset *
    ;
    RunProg (continue code execution)

    [/code]

    The A/D errors that I thought we had were simply caused by a typo, and are not related to this issue.

  • 0
    Prodigy 170 points

    Okay, so I've been in contact with some folks in-the-know with TI, and the whole problem appears to be centered on our fast-rising Vcc.  The Vcc rise-time spec is 1000V/s, and our rise time is at least 10 times as fast, with 0-1.8V occurring at 41kV/s.  We will deal with that issue and see where we are.

  • 0 in reply to Henry Lehmann
    Guru 227245 points

    Good you got an explanation (and a workaround too).

    Some larger capacitance on VCC would increase voltage rise time. Or you could try an R/C combo on RST pin that keeps the MSP in reset for some time after the brownout has released the MSP.

**Attention** This is a public forum