Jump to content


  • Content Count

  • Joined

  • Last visited

About jayaura

  • Rank
  • Birthday 08/20/1991

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
  • Interests
    Embedded, Linux
  1. If it was an RC osc, I would've used an oscillator. But since its DCO, its supposed to be more stable. I never got any issue yet with SMCLK from DCO @ 1Mhz for 9600 bps. Didnt try higher freqs.
  2. My bad!, I didnt check the comment on the interrupt vector definition. I guess I breezed though that part of the datasheet. Thank you very much Its all clear now
  3. Great! But still, thats timer's problem, right? Why would that mess with UART? It must be some kinda reset like you mentioned, but how do I go about finding what exactly its happening inside the chip? I havent used gdb yet. Will it be *theoritically* possible to know whats happening inside if I use it?
  4. Okay I found a solution. But my conscience says that fix is *impossible*, but for some reason, its working!!! This is the setting that's working (both UART and Timer). What did the trick is, change the line: TACTL = TASSEL1 | MC0 | TAIE; to TACTL = TASSEL1 | MC0; So dont enable the timer interrupt. Then timer interrupt routines will work! Please someone should help me explain why its so! The full code which works is http://pastebin.com/HtP5yfDW
  5. Still its not working; TACCR0 = 25000; // since clk = 1MHhz => 25us count TACTL = TASSEL1; //set SMCLK as source - TASSELx = 10 TACTL |= TAIE; //enabe timer_A interrupt //TACCTL0 |= OUTMOD2; // Toggle mode - OUTMODx = 100 TACCTL0 |= CCIE; //enable interrupt for capture/compatre; TACTL |= MC0; // Set Up mode (upto TACCR0) - MCx = 01 But the weird thing is, this time, if I uncomment line starting TACCR0, (first one), UART works
  6. Thank you for the response @@pabigot, but I cant figure out what exactly I'm supposed to change in UART. It doesnt have any prescaler setting. AFAIK, just has a clock select (which is SMCLK in my case), and the Baud rate control registers, UCA0BR0 and UCA0BR1. Those values are constants, for a particular baud rate I believe. Though Timer has one independent prescaler, my setting is no prescaling (1). It seems I can have a global prescaler for SMCLK, but will equally change the timer's clock too. What exactly are you proposing to change? ,
  7. Dear all, I am an AVR atmega8 refugee, and msp's clocking scheme seems pretty feature rich (not to mention complex!). I am using MSP430G2 launchpad (g2553). This program uses TImerA, and hardware UART with interrupt. It runs at 1Mhz from DCO. And the peripherals take clock from SMCLK. The UART just echos whatever it receives. The timer generate 500ms delay, and toggles the red and green leds on board http://pastebin.com/yApLyFbu The problem is, I can only have one peripheral at a time using the SMCLK. If I have the above code running exactly as it is, the timer will correctly run and toggle the leds as expected, but the UART echo wont work. If I comment out line 8, TACTL = TASSEL1; //set SMCLK as source - TASSELx = 10 (which means timer is not turned-on at all, right?) then UART echo works. So is it something wrong with my code, or is it like that with the MSP430G2253 ? -- Thanks and Regards, Aurabindo
  8. Dear pabigot Thank you for that informative response. I tried adding __set_watchdog_clear_value(WDTPW+WDTHOLD); ed at the start of main() and checked the disassembled output, but I get the same watchdog_support section as before. What is the right way to use the inbuilt watchdog ? It might be an overkill for me right now to use these advanced stuff, but I would also like to know about all the other internal features that mspgcc has. Is there a documentation about them anywhere? I googled, but couldnt find anything regarding the watchdog functions you mentioned. The best I could find was http://mspgcc.sourceforge.net/manual/book1.html. I already had -Os in the build.
  9. Hello everyone, I disassembled the following code: #include <msp430.h> #define RED BIT0 #define GREEN BIT6 int main(int argc, const char *argv[]) { WDTCTL = WDTPW + WDTHOLD; P1DIR = BIT6 | BIT0; while (1) { P1OUT = BIT6; __delay_cycles(500000); P1OUT ^= (BIT6 | BIT0); __delay_cycles(500000); } return 0; } On running msp430-objdump -D hello_world.elf, I got: Disassembly of section .text: 0000c000 <__watchdog_support>: c000: 55 42 20 01 mov.b &0x0120,r5 //0x120 is WDTCTL c004: 35 d0 08 5a bis #23048, r5 ;#0x5a08 //Supposed to be WDTPW + WDTHOLD c008: 82 45 00 02 mov r5, &0x0200 // copying to RAM 0000c00c <__init_stack>: c00c: 31 40 00 04 mov #1024, r1 ;#0x0400 0000c010 <__do_copy_data>: c010: 3f 40 00 00 mov #0, r15 ;#0x0000 c014: 0f 93 tst r15 c016: 08 24 jz $+18 ;abs 0xc028 c018: 92 42 00 02 mov &0x0200,&0x0120 c01c: 20 01 c01e: 2f 83 decd r15 c020: 9f 4f 88 c0 mov -16248(r15),512(r15);0xc088(r15), 0x0200(r15) c024: 00 02 c026: f8 23 jnz $-14 ;abs 0xc018 0000c028 <__do_clear_bss>: c028: 3f 40 00 00 mov #0, r15 ;#0x0000 c02c: 0f 93 tst r15 c02e: 07 24 jz $+16 ;abs 0xc03e c030: 92 42 00 02 mov &0x0200,&0x0120 c034: 20 01 c036: 1f 83 dec r15 c038: cf 43 00 02 mov.b #0, 512(r15);r3 As==00, 0x0200(r15) c03c: f9 23 jnz $-12 ;abs 0xc030 0000c03e <main>: c03e: b2 40 80 5a mov #23168, &0x0120 ;#0x5a80 c042: 20 01 c044: f2 40 41 00 mov.b #65, &0x0022 ;#0x0041 c048: 22 00 c04a: f2 40 40 00 mov.b #64, &0x0021 ;#0x0040 c04e: 21 00 c050: 3e 40 03 00 mov #3, r14 ;#0x0003 c054: 3f 40 06 8b mov #-29946,r15 ;#0x8b06 c058: 1f 83 dec r15 c05a: fe 23 jnz $-2 ;abs 0xc058 c05c: 1e 83 dec r14 c05e: fc 23 jnz $-6 ;abs 0xc058 c060: 03 43 nop c062: f2 e0 41 00 xor.b #65, &0x0021 ;#0x0041 c066: 21 00 c068: 3e 40 03 00 mov #3, r14 ;#0x0003 c06c: 3f 40 06 8b mov #-29946,r15 ;#0x8b06 c070: 1f 83 dec r15 c072: fe 23 jnz $-2 ;abs 0xc070 c074: 1e 83 dec r14 c076: fc 23 jnz $-6 ;abs 0xc070 c078: 03 43 nop c07a: e7 3f jmp $-48 ;abs 0xc04a 0000c07c <__stop_progExec__>: c07c: 32 d0 f0 00 bis #240, r2 ;#0x00f0 c080: fd 3f jmp $-4 ;abs 0xc07c 0000c082 <__ctors_end>: c082: 30 40 86 c0 br #0xc086 0000c086 <_unexpected_>: c086: 00 13 reti Disassembly of section .noinit: 00000200 <__wdt_clear_value>: ... Disassembly of section .vectors: 0000ffe0 <__ivtbl_16>: ffe0: 82 c0 82 c0 bic r0, &0xc082 ffe4: 82 c0 82 c0 bic r0, &0xc082 ffe8: 82 c0 82 c0 bic r0, &0xc082 ffec: 82 c0 82 c0 bic r0, &0xc082 fff0: 82 c0 82 c0 bic r0, &0xc082 fff4: 82 c0 82 c0 bic r0, &0xc082 fff8: 82 c0 82 c0 bic r0, &0xc082 fffc: 82 c0 00 c0 bic r0, &0xc000 My questions are: 1) In <__watchdog_support> c000: 55 42 20 01 mov.b &0x0120,r5 //0x120 is WDTCTL c004: 35 d0 08 5a bis #23048, r5 ;#0x5a08 //Supposed to be WDTPW + WDTHOLD c008: 82 45 00 02 mov r5, &0x0200 // copying to RAM The second line - WDTHOLD is the 8th bit in WDTCTL. So shouldnt it be 0x5a80 ? Why is it 0x5a08 ? Why copy the modified content to RAM ? Why not directly write to WDTCTL register? But later in main: c03e: b2 40 80 5a mov #23168, &0x0120 ;#0x5a80 Now this seems consistent. So why is that "watchdog support" section even there? 2) In section <__do_copy_data> c010: 3f 40 00 00 mov #0, r15 ;#0x0000 c014: 0f 93 tst r15 c016: 08 24 jz $+18 ;abs 0xc028 When #0 is explicitly moved to r15, after tst, its pretty obvious that jz will be evaluate to true. Then why not unconditionally jump to 0xc028 ? If thats the case, what about the code just below jz? that is *dead* code, right?
  10. Fixed. It was the bad cable! :-O Dear admin/moderator, please feel free to delete this thread!
  11. Hello everyone, FIrst - its not the permission issue of not having a proper udev rule. I am on Debian Wheezy with all the msp related packages installed from the official repos - including mspdebug. But after I connect the launchpad and give: mspdebug rf2500 I get usbutil: unable to find a device matching 0451:f432 My computer is not detecting the board. The output of lsusb is: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 003: ID 1210:25f4 DigiTech Bus 002 Device 003: ID 04f3:0232 Elan Microelectronics Corp. Mouse I get *no* information at dmesg while I plug in or disconnect the launchpad. Absolutely nothing. The output of lsmod | grep ti confirms that the ti's usb driver module has not been loaded. So I manually loaded that one with modprobe ti_usb_3410_5052 Now I see something in dmesg: [ 1496.709197] usbcore: registered new interface driver usbserial [ 1496.709227] USB Serial support registered for generic [ 1496.709266] usbcore: registered new interface driver usbserial_generic [ 1496.709273] usbserial: USB Serial Driver core [ 1496.722267] USB Serial support registered for TI USB 3410 1 port adapter [ 1496.722313] USB Serial support registered for TI USB 5052 2 port adapter [ 1496.722733] usbcore: registered new interface driver ti_usb_3410_5052 [ 1496.722741] ti_usb_3410_5052: v0.10:TI USB 3410/5052 Serial Driver Now I plugged in the board again. But absolutely *no* change in the dmesg or lsusb output. The board is a fresh one, and its working well - when I plug in into USB, I can see its demo program blinking those red and green leds. Now, as mentioned in http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Getting_Started_with_Debugging, I looked for the firmware file to copy, but the file ti_3410.fw doesnt exist anywhere in my /lib/firmware. But I do have a file ti_3410.fw.ihex in /usr/lib/mspdebug which obviously came with mspdebug. What's wrong? What should I do to get the USB port detected? It might be irrelevant, but I can connect an Arduino board on the same port, and it works well. Thanks in advance!
  • Create New...