Jump to content

Fabinhou

Members
  • Content Count

    11
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Fabinhou reacted to chicken in Debug and Release mode   
    While I know the problem of new bugs appearing in Release mode, the Debug mode program should start without pressing reset.
     
    Did you forget a breakpoint? Or is there an external peripheral that requires some time after power-on? For the latter, a quick&dirty fix would be to busy-wait a few 100ms at the start of your program (after turning off watchdog timer and setting up clock frequency).
     
    For the Debug vs Release bugs, check any places where data is passed between interrupts and the main thread. Make sure that the volatile modifier is used declaring those variables. Also think about race conditions if the interaction is more complex than one 8 or 16 bit value in one direction.
  2. Like
    Fabinhou reacted to cubeberg in USB-Tunneled Serial Connection   
    It's using a TI USB chip. Should be pretty easy to find something in the product documentation.
  3. Like
    Fabinhou reacted to RobG in Saving data to flash on power down   
    Here is a simple solution to the problem I had, saving data when power goes down.
    There are two parts needed, a diode (1N4148) and a capacitor (~47uF.)
    The way it works, you isolate main power from MCU and connect capacitor on the MCU's side.
    One of the pins is connected to the main power and will trigger an interrupt.
    In the interrupt routine, we will be saving data to flash.
    This is a simple proof of concept, the final code should include low voltage detection for situations like dying battery.
     

     


     

    #include "msp430g2231.h" unsigned int data = 0; unsigned int * const savedDataPtr = (unsigned int *)(0x1000); void main(void) { WDTCTL = WDTPW + WDTHOLD; P1DIR &= ~BIT1; P1IE |= BIT1; P1IES |= BIT1; P1IFG &= ~BIT1; P1REN |= BIT1; P1OUT &= ~BIT1; P1DIR |= BIT0; P1OUT |= BIT0; data = *savedDataPtr; if(data == 0xFFFF) data = 100; unsigned int counter = data; _bis_SR_register(GIE); while(1) { counter = data; while(counter > 0) { _delay_cycles(1000); counter--; } P1OUT ^= BIT0; } } // Port 1 interrupt service routine #pragma vector=PORT1_VECTOR __interrupt void Port_1(void) { P1OUT &= ~BIT0; data += 100; // Save value FCTL2 = FWKEY + FSSEL0 + FN1; FCTL1 = FWKEY + ERASE; FCTL3 = FWKEY; *savedDataPtr = 0; FCTL1 = FWKEY + WRT; *savedDataPtr = data; FCTL1 = FWKEY; FCTL3 = FWKEY + LOCK; P1IFG &= ~BIT1; }
  4. Like
    Fabinhou reacted to cde in Problem receiving ACK on I2C communication [MSP430g2553]   
    7 bit address 0111101 or 0x3D, 8 bit 01111010 write 0x7A 01111011 read 0x7B
  5. Like
    Fabinhou reacted to cde in Problem receiving ACK on I2C communication [MSP430g2553]   
    The USCI system is smart. It handles the read/write bit itself. You would still give the slave address of 0x3C for reads.
  6. Like
    Fabinhou reacted to jpnorair in Problem receiving ACK on I2C communication [MSP430g2553]   
    R/W bit is bit 0 of the address.  The 7 bit address is in the bits 7:1.  However, often I2C device datasheets specify addresses in right-aligned form, and they just specify only even addresses.  So, you have to read those datasheets twice.  Yes, read address would be 3D.
     
    Actually, you probably need to read the datasheet three times.  If I had a dollar for every I2C device that did not quite meet the spec...  I2C is a pain to debug -- most logic analyzers introduce too much capacitance and you'll need to go to an oscilloscope.  I am not an expert of this part, but I know some parts that don't even send ACKs -- they just clock stretch.  So, you need to become an expert of the part.
  7. Like
    Fabinhou reacted to cde in Problem receiving ACK on I2C communication [MSP430g2553]   
    Is this OLED have a schematic? Is it a pre-made board?
     
    Just double checking, on the OLED the Bus Select pins BS0 and BS2 are tied low with BS1 tied high right? Otherwise it is not in i2c mode. And is the OLED 5v or 3.3/3.6v logic? The IC has options for both. Is CS#, R/W#, E and D7-D3 pulled low? This is required for i2c communication. Is D2 and D1 tied together? These two pins are the SDA line. D0 is the SCL line.
    Do you have external pullups on the d2/d1/d0 lines?
     
    If the SDAout pin (I think D2) isn't connected, you won't get any acks. Meaning it would be write only with no i2c acks, not standard, you would have to code around that. (See the pdf 5.1.4 ( for info on that, it won't let me copy and paste the info)
     
    The Slave address you use is 0x78. That's Binary 0b01111000. That indicated that the D/C# (SA0) line is tied low, is that correct?
    That's an 8 bit address, including the write/read bit. The 7 bit address is 0x3C (0b0111100). I Think the USCI system requires a 7 bit address, not including the write/read bit, to be used. In that case, you are trying to write to the wrong address. Googling shows this to be correct. Try the 7 bit address, that might be the problem.
     
    Make sure you have the i2c pins correct. P1.7 is SDA, P1.6 is SCL
×
×
  • Create New...