MSP430F6736: Trouble Writing Memory Block at 0x1800 on Page 0 of Length 0x200: Could not erase device memory

Hi Cameron

These are the download/debug settings that were always set...but what is interesting is that when i changed the erase options to "erase main memory only" i STILL got the same error message! And that really puzzled me.

Hi Cameron

As it is i AM using the infoD memory. I have an initialised structure in my application that utilises that space...but it hadnt changed in the last week...

Also, a further issue arose which may or may not be connected....the enhanced UART A1 developed a couple of issues - namely it stopped recognising the receipt of NULL bytes AND started garbling transmitted bytes.

I replaced my dev board with another and that all worked fine.

So it would appear that something actually DID happen to the MSP the evening the memory block message appeared although the EXTENT of the issue wasn't entirely apparent.

Thanks for your input!

Best regards

Hi Cameron

I discovered that it wasnt reacting to null bytes when the logic analyser showed that the PC was transmitting them. And similarly, the analyser showed the garbled bytes the MSP was transmitting.

No..i'm not using DMA..But i am tempted to do so (perhaps for the 2nd release).

But i will re connect everything and hook it up to the scope and capture a transmission in the next day or two.

kind regards

Hi Cameron

Sorry about the delay.

The replacement board i was using packed up on the Tx side!...below is the waveform of both the Rx & Tx (Tx in yellow & Rx in blue) after it packed up & then with another board where the same comms produced correct signals..

What has happened to the Tx side to produce such an output???...its almost like the Tx is mimicking the Rx.

The correct signals came from the board I reconnected that was the cause of this thread & whose Rx side had previously packed up (see 2 msgs up)....but its now working perfectly (so being off mains for a few days resolved its issue)!! i have now kept it connected to mains and will see if it packs up again in a few days time.

thank you Chester...there was!

in fact, looking under the microscope, i could see the pin move when i nudged  it!!

Hi Cameron

I'm working on new prototype board which has the problem of not picking up NULL bytes...it picks up the other bytes, just not NULL....why???

The logic analyser picks it up correctly on the MCU Rx pin as  2h ABh CDh EFh 2Ah 20h 4h 5h 0h 5h 0h 24h 3h
The captured waveform is as below.  Vmax is 4.08V Vmin is 0V Baud is 9600.

Hi Cameron

This is the setup code and the interrupt code. Bear in mind that it works on other identical boards.
And it is ONLY the NULL byte...transmission is fine (it sends the correct responses to packets that do not have the NULL byte).

Oh, an one more thing, at some point the Rx & Tx pins may have been subjected to voltages of about 7V.

void SetupRS232Port(void)
{

  UCA1CTLW0 = 0; // this makes everything into the default state
  UCA1CTLW0 |= UCSWRST;   // Put state machine in reset
  UCA1CTLW0 |= UCSSEL1;   // use SMCLK
  UCA1CTLW0 |= UCRXEIE; //enable eroneous char intr..DO THIS ELSE WE MISS CRUCIAL BYTES
  UCA1BRW = ((uint16_t)0x68 );
  UCA1MCTLW = 0xd600 | 0x0020 | 0x0001;  
  UCA1CTLW0 &= ~UCSWRST;                  // Initialize USCI state machine...
  UCA1IE |= UCRXIE;                       // Enable USCI_A1 RX interrupt
  return;
}

// USCI_A1 interrupt service routine
#pragma vector=USCI_A1_VECTOR
__interrupt void USCI_A1_ISR(void)
{
uint8_t bb;

   switch (__even_in_range(UCA1IV, 10))
    {
      case USCI_UART_UCRXIFG:             // RXIFG
            bb = UCA1STATW & UCRXERR;// check if had an error (framing/overrun/parity)..reading resets the state which is important
            if(bb) // we had an error...so just recodr the fact for posterity at this time
               ++rxErrs;
           rs232RxBuffer[rs232RxHead] = UCA1RXBUF; // auto clears the error status
          if(++rs232RxHead == MAXRXBUFFER)
               rs232RxHead = 0;
          break;

       case USCI_UART_UCTXIFG:
           if(rs232TxHead != rs232TxTail)
                UCA1TXBUF = rs232TxBuffer[rs232TxTail++];
           if(rs232TxTail == MAXTXBUFFER)
               rs232TxTail = 0;
           if(rs232TxHead == rs232TxTail)
               UCA1IE &= ~UCTXIE; // disable USCI_A1 TX interrupt
           break;      // TXIFG
      case USCI_NONE:
           break;                    
      case USCI_UART_UCSTTIFG:
           UCA1IFG &= ~UCSTTIFG;
           break;
      case USCI_UART_UCTXCPTIFG:
           UCA1IFG &= ~UCTXCPTIFG;
           break;  
      default:
           break;
      }
}

......and elsewhere these few lines gets executed before the above

#define P1DIR_INIT                                  (BIT7 | BIT5 | BIT3 | BIT2 | BIT1 |BIT0)
#define P1SEL_INIT                                  (BIT5 | BIT4 | BIT3 | BIT2)
#define P1OUT_INIT                                  (0)

  P1DIR = P1DIR_INIT;
  P1SEL = P1SEL_INIT;
  P1OUT = P1OUT_INIT;

cheers
moshe

Hi Moshe,

So you said "new prototype" board, but there is no difference from the other boards? 

7V could have caused damage that would be unpredictable in behavior.

Thanks Cameron