Jump to content
43oh

jp430bb

Members
  • Content Count

    38
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    jp430bb got a reaction from LiviuM in 4-wire JTAG with mspdebug and Raspberry Pi GPIO   
    Having a small collection of older F1xx and F4xx MSP430 devices, I've been looking for a convenient way to flash and debug them.  The devices I have don't support Spy By Wire, so they require 4-wire JTAG.  They also have their JTAG pins shared with other functions, so the test and reset pins have to be used to put them into JTAG mode.  
     
    While I do have an Olimex parallel-port JTAG adapter, the computer I use most of the time has no parallel port.  
     
    A Raspberry Pi running Debian Jessie and mspdebug with its gpio driver looked like a good option.  Adding a patch to mspdebug so that the gpio driver supports the reset and test pins got it working.  
     
    The patch is here: https://github.com/johnp789/mspdebug/tree/gpiojtag
     
    Now, I only need a Raspberry Pi Zero, Debian Jessie with the USB ethernet gadget configured on a micro SD card, a USB cable, and 7 jumper wires to flash and debug 4-wire JTAG MSP430 devices.  The Pi Zero might be the lowest-cost 4-wire MSP430 JTAG debugger available!  
    $ sudo ./mspdebug -j -d "tdi=3 tdo=2 tms=4 tck=17 rst=22 tst=27" gpio MSPDebug version 0.24 - debugging tool for MSP430 MCUs Copyright (C) 2009-2016 Daniel Beer <dlbeer@gmail.com> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc. gpio tms= 4 gpio tdi= 3 gpio tdo= 2 gpio tck= 17 gpio rst= 22 gpio tst= 27 Starting JTAG JTAG_power on JTAG_connct led green JTAG ID: 0x89 Chip ID data: ver_id: 49f4 ver_sub_id: 0000 revision: 01 fab: 40 self: 0000 config: 00 Device: MSP430F44x Available commands: ! fill power setwatch_r = gdb prog setwatch_w alias help read simio blow_jtag_fuse hexout regs step break isearch reset sym blow_jtag_fuse hexout regs step break isearch reset sym cgraph load run verify delbreak load_raw save_raw verify_raw dis md set erase mw setbreak exit opt setwatch Available options: color gdb_default_port enable_bsl_access gdb_loop enable_fuse_blow gdbc_xfer_size enable_locked_flash_access iradix fet_block_size quiet Type "help <topic>" for more information. Use the "opt" command ("help opt") to set options. Press Ctrl+D to quit. (mspdebug) prog fet440_1.c.hex led green Erasing... led red led red Programming... Writing 74 bytes at 1100... led red led red Writing 32 bytes at ffe0... led red led red Done, 106 bytes total (mspdebug)
  2. Like
    jp430bb got a reaction from jazz in 4-wire JTAG with mspdebug and Raspberry Pi GPIO   
    4-wire JTAG with this setup did not work for me with an MSP430G2452.  Mspdebug gave me a response that it read 0xFF for a device ID and exited.  However, looking at the JTAG entry sequence on my scope, it didn't look quite right.  I patched mspdebug again, and now I get a connection to the MSP430G2452.  I haven't changed my wiring back to try it with the 'F449 yet, so I may have broken that.  
    $ git diff diff --git a/drivers/jtaglib.c b/drivers/jtaglib.c index 1161606..17975ce 100644 --- a/drivers/jtaglib.c +++ b/drivers/jtaglib.c @@ -386,12 +386,20 @@ unsigned int jtag_init(struct jtdev *p) jtag_rst_clr(p); p->f->jtdev_power_on(p); - jtag_tst_set(p); jtag_tdi_set(p); jtag_tms_set(p); jtag_tck_set(p); jtag_tclk_set(p); + + jtag_rst_set(p); + jtag_tst_clr(p); + + jtag_tst_set(p); jtag_rst_clr(p); + jtag_tst_clr(p); + + jtag_tst_set(p); + p->f->jtdev_connect(p); jtag_rst_set(p); jtag_reset_tap(p);
  3. Like
    jp430bb got a reaction from jazz in 4-wire JTAG with mspdebug and Raspberry Pi GPIO   
    Having a small collection of older F1xx and F4xx MSP430 devices, I've been looking for a convenient way to flash and debug them.  The devices I have don't support Spy By Wire, so they require 4-wire JTAG.  They also have their JTAG pins shared with other functions, so the test and reset pins have to be used to put them into JTAG mode.  
     
    While I do have an Olimex parallel-port JTAG adapter, the computer I use most of the time has no parallel port.  
     
    A Raspberry Pi running Debian Jessie and mspdebug with its gpio driver looked like a good option.  Adding a patch to mspdebug so that the gpio driver supports the reset and test pins got it working.  
     
    The patch is here: https://github.com/johnp789/mspdebug/tree/gpiojtag
     
    Now, I only need a Raspberry Pi Zero, Debian Jessie with the USB ethernet gadget configured on a micro SD card, a USB cable, and 7 jumper wires to flash and debug 4-wire JTAG MSP430 devices.  The Pi Zero might be the lowest-cost 4-wire MSP430 JTAG debugger available!  
    $ sudo ./mspdebug -j -d "tdi=3 tdo=2 tms=4 tck=17 rst=22 tst=27" gpio MSPDebug version 0.24 - debugging tool for MSP430 MCUs Copyright (C) 2009-2016 Daniel Beer <dlbeer@gmail.com> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc. gpio tms= 4 gpio tdi= 3 gpio tdo= 2 gpio tck= 17 gpio rst= 22 gpio tst= 27 Starting JTAG JTAG_power on JTAG_connct led green JTAG ID: 0x89 Chip ID data: ver_id: 49f4 ver_sub_id: 0000 revision: 01 fab: 40 self: 0000 config: 00 Device: MSP430F44x Available commands: ! fill power setwatch_r = gdb prog setwatch_w alias help read simio blow_jtag_fuse hexout regs step break isearch reset sym blow_jtag_fuse hexout regs step break isearch reset sym cgraph load run verify delbreak load_raw save_raw verify_raw dis md set erase mw setbreak exit opt setwatch Available options: color gdb_default_port enable_bsl_access gdb_loop enable_fuse_blow gdbc_xfer_size enable_locked_flash_access iradix fet_block_size quiet Type "help <topic>" for more information. Use the "opt" command ("help opt") to set options. Press Ctrl+D to quit. (mspdebug) prog fet440_1.c.hex led green Erasing... led red led red Programming... Writing 74 bytes at 1100... led red led red Writing 32 bytes at ffe0... led red led red Done, 106 bytes total (mspdebug)
  4. Like
    jp430bb got a reaction from Fmilburn in 4-wire JTAG with mspdebug and Raspberry Pi GPIO   
    Having a small collection of older F1xx and F4xx MSP430 devices, I've been looking for a convenient way to flash and debug them.  The devices I have don't support Spy By Wire, so they require 4-wire JTAG.  They also have their JTAG pins shared with other functions, so the test and reset pins have to be used to put them into JTAG mode.  
     
    While I do have an Olimex parallel-port JTAG adapter, the computer I use most of the time has no parallel port.  
     
    A Raspberry Pi running Debian Jessie and mspdebug with its gpio driver looked like a good option.  Adding a patch to mspdebug so that the gpio driver supports the reset and test pins got it working.  
     
    The patch is here: https://github.com/johnp789/mspdebug/tree/gpiojtag
     
    Now, I only need a Raspberry Pi Zero, Debian Jessie with the USB ethernet gadget configured on a micro SD card, a USB cable, and 7 jumper wires to flash and debug 4-wire JTAG MSP430 devices.  The Pi Zero might be the lowest-cost 4-wire MSP430 JTAG debugger available!  
    $ sudo ./mspdebug -j -d "tdi=3 tdo=2 tms=4 tck=17 rst=22 tst=27" gpio MSPDebug version 0.24 - debugging tool for MSP430 MCUs Copyright (C) 2009-2016 Daniel Beer <dlbeer@gmail.com> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc. gpio tms= 4 gpio tdi= 3 gpio tdo= 2 gpio tck= 17 gpio rst= 22 gpio tst= 27 Starting JTAG JTAG_power on JTAG_connct led green JTAG ID: 0x89 Chip ID data: ver_id: 49f4 ver_sub_id: 0000 revision: 01 fab: 40 self: 0000 config: 00 Device: MSP430F44x Available commands: ! fill power setwatch_r = gdb prog setwatch_w alias help read simio blow_jtag_fuse hexout regs step break isearch reset sym blow_jtag_fuse hexout regs step break isearch reset sym cgraph load run verify delbreak load_raw save_raw verify_raw dis md set erase mw setbreak exit opt setwatch Available options: color gdb_default_port enable_bsl_access gdb_loop enable_fuse_blow gdbc_xfer_size enable_locked_flash_access iradix fet_block_size quiet Type "help <topic>" for more information. Use the "opt" command ("help opt") to set options. Press Ctrl+D to quit. (mspdebug) prog fet440_1.c.hex led green Erasing... led red led red Programming... Writing 74 bytes at 1100... led red led red Writing 32 bytes at ffe0... led red led red Done, 106 bytes total (mspdebug)
  5. Like
    jp430bb got a reaction from Rickta59 in 4-wire JTAG with mspdebug and Raspberry Pi GPIO   
    Having a small collection of older F1xx and F4xx MSP430 devices, I've been looking for a convenient way to flash and debug them.  The devices I have don't support Spy By Wire, so they require 4-wire JTAG.  They also have their JTAG pins shared with other functions, so the test and reset pins have to be used to put them into JTAG mode.  
     
    While I do have an Olimex parallel-port JTAG adapter, the computer I use most of the time has no parallel port.  
     
    A Raspberry Pi running Debian Jessie and mspdebug with its gpio driver looked like a good option.  Adding a patch to mspdebug so that the gpio driver supports the reset and test pins got it working.  
     
    The patch is here: https://github.com/johnp789/mspdebug/tree/gpiojtag
     
    Now, I only need a Raspberry Pi Zero, Debian Jessie with the USB ethernet gadget configured on a micro SD card, a USB cable, and 7 jumper wires to flash and debug 4-wire JTAG MSP430 devices.  The Pi Zero might be the lowest-cost 4-wire MSP430 JTAG debugger available!  
    $ sudo ./mspdebug -j -d "tdi=3 tdo=2 tms=4 tck=17 rst=22 tst=27" gpio MSPDebug version 0.24 - debugging tool for MSP430 MCUs Copyright (C) 2009-2016 Daniel Beer <dlbeer@gmail.com> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc. gpio tms= 4 gpio tdi= 3 gpio tdo= 2 gpio tck= 17 gpio rst= 22 gpio tst= 27 Starting JTAG JTAG_power on JTAG_connct led green JTAG ID: 0x89 Chip ID data: ver_id: 49f4 ver_sub_id: 0000 revision: 01 fab: 40 self: 0000 config: 00 Device: MSP430F44x Available commands: ! fill power setwatch_r = gdb prog setwatch_w alias help read simio blow_jtag_fuse hexout regs step break isearch reset sym blow_jtag_fuse hexout regs step break isearch reset sym cgraph load run verify delbreak load_raw save_raw verify_raw dis md set erase mw setbreak exit opt setwatch Available options: color gdb_default_port enable_bsl_access gdb_loop enable_fuse_blow gdbc_xfer_size enable_locked_flash_access iradix fet_block_size quiet Type "help <topic>" for more information. Use the "opt" command ("help opt") to set options. Press Ctrl+D to quit. (mspdebug) prog fet440_1.c.hex led green Erasing... led red led red Programming... Writing 74 bytes at 1100... led red led red Writing 32 bytes at ffe0... led red led red Done, 106 bytes total (mspdebug)
  6. Like
    jp430bb reacted to Lgbeno in This Weeks Amp Hour   
    I was lucky enough to be a guest on the Amp Hour this week.  We talked mostly about analog.io but I made a special point to give a shout our to everyone here on 43oh!  @@bluehash, I hope it helps grow the user base!
     
    http://www.theamphour.com/272-an-interview-with-luke-beno-of-analog-io/
  7. Like
    jp430bb got a reaction from phenyl in CC2650STK demo firmware + Android app, IMU not working   
    My CC2650STK just arrived, and I'm checking it out with the TI demo Android app.  The humidity, noncontact temperature, barometric pressure, and lux sensors all behave like they should, but the app doesn't show sensible data for acceleration, rotation, or magnetic fields.  All those fields show zero.  I've updated the CC2650STK firmware to revision 1.12 (Jun 23 2015) using the Android app.  The Android app is revision 2.3.  I'm running it on a 1st-gen Moto X with Android 4.4.4.  
     
    Is this a known software issue, or do I have bad SensorTag hardware?  
  8. Like
    jp430bb reacted to tripwire in CC2650STK demo firmware + Android app, IMU not working   
    Yes, but the necessary modification is difficult at present.
     
    The emulator firmware doesn't support cJTAG (only SWD and JTAG), while the CC26xx doesn't support SWD (only JTAG and cJTAG). That means that full four-wire JTAG is the only option that will work right now. The problem is that the launchpad only exposes pins for SWD and cJTAG rather than the full JTAG pinout used with the on-board target.
     
    To add a JTAG cable you need to tap into one of the traces on the PCB by scraping off the soldermask and tacking a wire to the trace. The other connections are exposed at J103 and one is on a terminal of S101. See these posts on TI's forum for more details:
     
    XDS110 from MSP432P401R Launchpad for CC26xx/CC13xx
    MSP432P401R LaunchPad External Target Mod (See the detailed instructions in the PDF)
     
    I have a sneaking suspicion that TI might add cJTAG support to the XDS110 on the Debug DevPack to fix the issue with debugging while using the serial flash. If they do there's a slim chance that the same might be added to XDS110-ET. That would make it far easier to use the MSP432 launchpad with the SensorTag, because only connections to J103 would be required. None of this is confirmed, and it'll be at least a few months before the next major XDS110 firmware update. I heard predictions of October from TI, but their toolchain updates are prone to slippage.
  9. Like
    jp430bb reacted to tripwire in CC2650STK demo firmware + Android app, IMU not working   
    You're right, the power won't have started to run down until the plastic strip was removed. Unfortunately I wasn't exaggerating when I called the power consumption atrocious. People have reported draining the battery enough to affect the IMU within a couple of days.
     

    I think you might need a newer firmware than that. Are you updating over-the-air from a phone or with a Debug DevPack?
     
    I use the DevPack, and the SensorTag sample in the BLE Stack 2.1 has been updated with the power consumption fixes. It's also available as a prebuilt hex file for programming with SmartRF Flash Programmer V2 from here: https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/912/CC2650SensorTag_5F00_BLE_5F00_App_5F00_v1_5F00_20.hex
     
    If you need to update over-the-air then I'm not sure what version is available.
     

    That rings a bell, I think older firmware had problems with the wake-on-motion feature. The IMU would give output for a while, but then stop and never restart.
  10. Like
    jp430bb got a reaction from bluehash in TI ADS1118 Booster Pack and Stellaris LaunchPad possible short   
    I've just noticed that the ADS1118 Booster Pack's J4 connector has long pins extending below the PCB, and one of them can contact the top of the VDD jumper.  It looks like a possible short could occur between these two points.  For now, I've stuck a business card in between to keep them from touching.  
     
    Do the Booster Pack design guidelines include any bottom-side exclusion areas for downward-extending pins?  
  11. Like
    jp430bb reacted to DrMag in LaunchPad's UART at more than 9600 baud ?   
    I finally figured out why the linux behavior was weird (ie. getting 10 Gbit baud rates): the screen program transparently changes your requested rate to something it can do, usually the next lowest, but if you're out of range completely it defaults to 9600.
     
    Here's a list of the rates I confirmed work for the LaunchPad USB serial in Linux:
     


    75 4800
    110 9600
    150 19200
    200 38400
    300 57600
    600 115200
    1200 230400
    2400 460800

  12. Like
    jp430bb reacted to xpg in Permissions for /dev/ttyACM0 for LaunchPad on Linux   
    Indeed. If no process grabs the data, I need to replug the Launchpad to make it work again. This bug causes me to use a separate USB<->UART device almost all the time.
    Does anyone know why the driver behaves this way? A regular bug, or something related to the strange fact that it shows up as a modem device?
  13. Like
    jp430bb reacted to gordon in Dead LaunchPad? Possible to re-flash the emulator?   
    IIRC the zip posted by OppaErich contains a zero-length ti_5052.fw .
     
    Actually, so do I (on 2.6.32, Ubuntu 10.04), works flawlessly, for values of "flawless" you could otherwise expect from a TUSB.
  14. Like
    jp430bb reacted to xpg in Dead LaunchPad? Possible to re-flash the emulator?   
    Same here. I have /dev/ttyACM0 and it "works", using the same definition, on my Ubuntu 11.10 system.
  15. Like
    jp430bb reacted to OppaErich in Permissions for /dev/ttyACM0 for LaunchPad on Linux   
    /dev/ttyACM0 is a modem device, if the Launchpad shows up as one of these you're probably missing the firmware for the TI USB chip. viewtopic.php?p=18354#p18354
  16. Like
    jp430bb reacted to larsie in Thermistor code for MSP430   
    I

  17. Like
    jp430bb got a reaction from bluehash in Getting started with MSP430G2231 and Atmel DataFlash   
    I hope it's not bad form to reply to my own post, but I've gotten a little bit further.
     
    The DataFlash chip auto-detects whether it's seeing SPI Mode 0 or Mode 3. I wasn't sure if I was setting up the USI for Mode 3 properly, so I checked Davies' book and made a couple of adjustments in spi_init(). After that, reading the manufacturer ID still doesn't work. I even alternated reading manufacturer ID and status bytes in read_both(); manufacturer ID gets just zero every time, status gets 0x9C (as it should) every time.
     
    I implemented reads and writes to the SRAM buffers on the DataFlash. These seem to work: I can write a set of test values to the buffer, overwrite my array in memory with zero, read back the values from the buffer, and they all look correct in the debugger memory view.
     
    Here's my code so far:
     

    //****************************************************************************** // MSP430G2231 SPI Master / Atmel DataFlash Slave 3-wire SPI // // // Using a LaunchPad with an MSP430G2231 and an Atmel AT45DB041D [1] // // Pins: // MSP430G2231 AT45DB041D // 1 3,5,6 (VCC -> /RESET, /WP, VCC) // 6 4 (P1.4 -> /CS) // 7 2 (SCLK -> SCK) // 8 1 (SDO -> SI) // 9 8 (SDI -> SO) // 14 7 (DVSS -> GND) // // //****************************************************************************** #include #include #define PIN_LED BIT0 #define PIN_CS BIT4 #define ID_READ 0x9F #define STATUS_READ 0xD7 void spi_init(void) { P1DIR = PIN_CS; // Set CS P1OUT = PIN_CS; // CS to high // SDI enable, SDO enable, SCLK enable, master mode, // data output enable, release USICTL0 = USIPE7 | USIPE6 | USIPE5 | USIMST | USIOE | USISWRST; // CKPH = 0 (write then read), interrupt enable USICTL1 = USIIE | USIIFG; // SMCLK / 128, clock idles high USICKCTL = USIDIV_6 | USISSEL_2 | USICKPL; USICTL0 &= ~USISWRST; // USI released for operation USICTL1 &= ~USIIFG; // clear unwanted interrupt } uint8_t cmd8(uint8_t op) { USISRL = op; // Load op into register USICNT = 8; _BIS_SR(LPM0_bits + GIE); // Enter LPM0 w/ interrupt return USISRL; } void repeat_info(void) // does not work!! just reads zero { volatile unsigned int i; volatile uint8_t mfg = 0xFF; volatile uint8_t dev_low = 0xFF; volatile uint8_t dev_high = 0xFF; volatile uint8_t dev_ext = 0xFF; while(1) { for (i = 0x7FFF; i > 0; i--); // Time for slave to ready P1OUT &= ~PIN_CS; // Take /CS low cmd8(ID_READ); // Send opcode for mfg&ID read mfg = cmd8(0); i = mfg + 3; // just for the debugger dev_low = cmd8(0); dev_high = cmd8(0); dev_ext = cmd8(0); P1OUT |= PIN_CS; // Take /CS high P1OUT ^= BIT0; // Toggle LED } } void repeat_status(void) // works!! Result in mfg is 0x9C { volatile unsigned int i; volatile uint8_t mfg = 0xFF; volatile uint8_t dev_low = 0xFF; volatile uint8_t dev_high = 0xFF; volatile uint8_t dev_ext = 0xFF; while(1) { for (i = 0x7FFF; i > 0; i--); // Time for slave to ready P1OUT &= ~PIN_CS; // Take /CS low cmd8(STATUS_READ); // Send opcode for status read mfg = cmd8(0); i = mfg + 3; // just for the debugger dev_low = cmd8(0); dev_high = cmd8(0); dev_ext = cmd8(0); P1OUT |= PIN_CS; // Take /CS high P1OUT ^= BIT0; // Toggle LED } } void repeat_both(void) // does not work!! just reads zero { volatile unsigned int i; volatile uint8_t mfg = 0xFF; volatile uint8_t dev_low = 0xFF; volatile uint8_t dev_high = 0xFF; volatile uint8_t dev_ext = 0xFF; while(1) { for (i = 0x7FFF; i > 0; i--); // Time for slave to ready P1OUT &= ~PIN_CS; // Take /CS low for (i = 0xFFF; i > 0; i--); // Time for slave to ready cmd8(ID_READ); // Send opcode for mfg&ID read mfg = cmd8(0); i = mfg + 3; // just for the debugger dev_low = cmd8(0); dev_high = cmd8(0); dev_ext = cmd8(0); P1OUT |= PIN_CS; // Take /CS high P1OUT ^= BIT0; // Toggle LED for (i = 0x7FFF; i > 0; i--); // Time for slave to ready P1OUT &= ~PIN_CS; // Take /CS low for (i = 0xFFF; i > 0; i--); // Time for slave to ready cmd8(STATUS_READ); // Send opcode for status read mfg = cmd8(0); i = mfg + 3; // just for the debugger dev_low = cmd8(0); dev_high = cmd8(0); dev_ext = cmd8(0); P1OUT |= PIN_CS; // Take /CS high P1OUT ^= BIT0; // Toggle LED } } void buffer_write(uint8_t buffer, uint16_t addr, uint8_t n, uint8_t *dat) { uint8_t bytes_left = n; P1OUT &= ~PIN_CS; // Take /CS low if (buffer == 1) { cmd8(0x84); } else { cmd8(0x87); } cmd8(0); // don't care byte cmd8(addr>>8); cmd8(addr & 0xFF); while (bytes_left > 0) { cmd8(*dat); dat++; bytes_left--; } P1OUT |= PIN_CS; // Take /CS high } void buffer_read(uint8_t buffer, uint16_t addr, uint8_t n, uint8_t *dat) { uint8_t bytes_left = n; P1OUT &= ~PIN_CS; // Take /CS low if (buffer == 1) { cmd8(0xD4); } else { cmd8(0xD6); } cmd8(0); // don't care byte cmd8(addr>>8); cmd8(addr & 0xFF); cmd8(0); // don't care byte while (bytes_left > 0) { *dat = cmd8(0); dat++; bytes_left--; } P1OUT |= PIN_CS; // Take /CS high } void main(void) { volatile uint16_t i; uint8_t dat[16] = {0x55, 0xff, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0xde, 0xad, 0xbe, 0xef, 0x55, 0xaa, 0xcc, 0x88}; WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer spi_init(); P1OUT &= ~PIN_LED; P1DIR |= PIN_LED; // Port 1.0 (LED) set to output while(1) { for (i = 0x7FFF; i > 0; i--); buffer_write(1, 0x00, 16, &(dat[0])); // breakpoint here for(i=0; i<16; i++) dat[i] = 0; buffer_read(1, 0x00, 16, &(dat[0])); // breakpoint here } } // USI interrupt service routine #pragma vector=USI_VECTOR __interrupt void universal_serial_interface(void) { USICTL1 &= ~USIIFG; // Clear interrupt flag _BIC_SR_IRQ(LPM0_bits); // Clear LPM3 bits from 0(SR) }
×
×
  • Create New...