cde 334 Posted October 25, 2012 Share Posted October 25, 2012 Trying to see if anyone has had the same issue. I tried porting over my old i2c-explorer code I made for the g2231, over to the g2452 (because it has USI, which I coded the i2c for). It uses NJ's Uart code too. Both are using the default 1mhz calibration. Only one compile error as is, regarding TimerA0_Vector. The g2452 has a slightly different timer (A3 vs A2), and the header file doesn't have the alternative name define. Based on the g2231 header, TimerA0_Vector is also Timer_A0_Vector, a name trivial change in the code. Also changed the include to point to the right msp430 header. Compiled, downloaded, tried to use it. The serial console was really slow, and kept giving back errors (typed a character, and sometimes it would give back a random character, or it would ignore input). The i2c code would sometimes just give all nacks (no acknowledgement, no response from slave), or not work at all. [natch, there is a hardware errata that might explain this, USI4, my really slow clocked i2c might be triggering that, but that doesn't explain the uart issues] I thought it was the new launchpad, maybe I did a crappy job soldering in the crystal (or not disable it) or screwed up adding the 5v/usb testpoint pins, but I pulled the chip onto the working older launchpad that I confirmed was working with the same code (including the vector name change) on the g2231. The family guide places these two as nearly identical, except for number of pins and code space/ram. Any ideas? Has anyone tried NJ's uart code on the g2452 without issue? Maybe I just fried the chip somehow? Or did I miss something in porting the code over, since it didn't error out, and the implementation did worked, just badly. I'll try with fresh one tomorrow. Quote Link to post Share on other sites
jsolarski-backup 22 Posted October 25, 2012 Share Posted October 25, 2012 use the crystal fault code to check your crystal. other wise your best bet is to connect it up to the debugger, then run it till you get the error and see where it is screwing up.... Sorry havent used NJs code yet Quote Link to post Share on other sites
cde 334 Posted October 25, 2012 Author Share Posted October 25, 2012 use the crystal fault code to check your crystal. other wise your best bet is to connect it up to the debugger, then run it till you get the error and see where it is screwing up.... Sorry havent used NJs code yet Well, that's why I removed the g2452 and put it in a crystal-less launchpad, and had the same problem. Quote Link to post Share on other sites
jsolarski-backup 22 Posted October 25, 2012 Share Posted October 25, 2012 Hmm, do you have another 2452 to test? or re-flash the default 1Mhz? I can test the code in a day, i have some un used g2452 lying around. Quote Link to post Share on other sites
jsolarski 94 Posted October 29, 2012 Share Posted October 29, 2012 testing tomorrow, have you figured it out? Quote Link to post Share on other sites
cde 334 Posted October 29, 2012 Author Share Posted October 29, 2012 No, halloween and no Hurricane Sandy have had me tied up. Quote Link to post Share on other sites
jsolarski 94 Posted October 29, 2012 Share Posted October 29, 2012 I will let you know tonight on if my port works then.... Quote Link to post Share on other sites
grodius 18 Posted December 31, 2012 Share Posted December 31, 2012 I had to change the HALF_BIT_TIME within uart.c to double ( 2 * HALF_BIT_TIME ) (so actually BIT_TIME ) to get this to work without issues on the 2452: CCR0 += HALF_BIT_TIME; // Set time till first bit to: CCR0 += 2 * HALF_BIT_TIME; // Set time till first bit or: CCR0 += BIT_TIME; // Set time till first bit cde 1 Quote Link to post Share on other sites
cde 334 Posted December 31, 2012 Author Share Posted December 31, 2012 I had to change the HALF_BIT_TIME within uart.c to double ( 2 * HALF_BIT_TIME ) (so actually BIT_TIME ) to get this to work without issues on the 2452: CCR0 += HALF_BIT_TIME; // Set time till first bit to: CCR0 += 2 * HALF_BIT_TIME; // Set time till first bit or: CCR0 += BIT_TIME; // Set time till first bit Huh. Ill have to try that. No more errors or lag on the serial? Is there a specific project you used or your own project? Quote Link to post Share on other sites
grodius 18 Posted December 31, 2012 Share Posted December 31, 2012 It was for your updated i2c explorer, code only imported into a bare 2452 CCS5.3 project. It compiled OK by just updating the 2452 include so that was simple enough... but the hyperterminal experience was wacky. I got better success with HT set to 1 start bit, 7 data bits and 1 stop bit before delving into the UART code (to see it was trying 8 data bits). I made some other tiny changes to improve timings but none of true consequence. Try that full wait after the start bit and I think you will get the UART part fully interactive and confidence inspiring. It's enough to get an ADXL345 90% working with the issues being i2c repeatability flakiness, not UART related. Anyhow this will fix the described problem and I will have completely overachieved my 'noob class' pigeon-hole, or can I Doogie Howser straight to leet haxxor on the back of this? Just kidding, but thanks for the work on the explorer and hopefully I might be of some use in a 2553 USCI port. Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.