Jump to content

Optronik

Members
  • Content Count

    18
  • Joined

  • Last visited

About Optronik

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Location
    Dallas, TX
  1. I was trying to make an accurate measurement of the internal temperature sensor (MSP430G2553). For this the ADC calibration values are stored in the Info Memory, also called TLV. To pick the right value first the tag needs to be searched and then a location based on an index array is calculated. Investigating this matter I browsed through the register definition file of CCS and found that not only the ADC calibration is stored in such a way but also the clock calibration. However, when using the clock calibration I have never seen a program going through the process of searching the info memory for the specific tag and then taking the indexed position. It always looks like this: DCOCTL = CALDCO_8MHZ; BCSCTL1 = CALBC1_8MHZ; That makes me wondering if this is using the correct values from the info memory? Or why can the clock calibration values be picked that easy from the info memory and not the ADC calibration? The register definition shows this: /* TLV Calibration Data Structure */ #define TAG_DCO_30 (0x01) /* Tag for DCO30 Calibration Data */ #define TAG_ADC10_1 (0x08) /* Tag for ADC10_1 Calibration Data */ #define TAG_EMPTY (0xFE) /* Tag for Empty Data Field in Calibration Data */ SFR_16BIT(TLV_CHECKSUM); /* TLV CHECK SUM */ SFR_8BIT(TLV_DCO_30_TAG); /* TLV TAG_DCO30 TAG */ SFR_8BIT(TLV_DCO_30_LEN); /* TLV TAG_DCO30 LEN */ SFR_8BIT(TLV_ADC10_1_TAG); /* TLV ADC10_1 TAG */ SFR_8BIT(TLV_ADC10_1_LEN); /* TLV ADC10_1 LEN */ define CAL_ADC_25T85 (0x0007) /* Index for 2.5V/85Deg Cal. Value */ #define CAL_ADC_25T30 (0x0006) /* Index for 2.5V/30Deg Cal. Value */ #define CAL_ADC_25VREF_FACTOR (0x0005) /* Index for 2.5V Ref. Factor */ #define CAL_ADC_15T85 (0x0004) /* Index for 1.5V/85Deg Cal. Value */ #define CAL_ADC_15T30 (0x0003) /* Index for 1.5V/30Deg Cal. Value */ #define CAL_ADC_15VREF_FACTOR (0x0002) /* Index for ADC 1.5V Ref. Factor */ #define CAL_ADC_OFFSET (0x0001) /* Index for ADC Offset */ #define CAL_ADC_GAIN_FACTOR (0x0000) /* Index for ADC Gain Factor */ #define CAL_DCO_16MHZ (0x0000) /* Index for DCOCTL Calibration Data for 16MHz */ #define CAL_BC1_16MHZ (0x0001) /* Index for BCSCTL1 Calibration Data for 16MHz */ #define CAL_DCO_12MHZ (0x0002) /* Index for DCOCTL Calibration Data for 12MHz */ #define CAL_BC1_12MHZ (0x0003) /* Index for BCSCTL1 Calibration Data for 12MHz */ #define CAL_DCO_8MHZ (0x0004) /* Index for DCOCTL Calibration Data for 8MHz */ #define CAL_BC1_8MHZ (0x0005) /* Index for BCSCTL1 Calibration Data for 8MHz */ #define CAL_DCO_1MHZ (0x0006) /* Index for DCOCTL Calibration Data for 1MHz */ #define CAL_BC1_1MHZ (0x0007) /* Index for BCSCTL1 Calibration Data for 1MHz */
  2. Yes, this is what I did after I figured the problem out. There are other online calculators. They give you a numeric value that end up in the same problem I had. If one is as stupid as I was and using the value as a register content then it will not work reliably.
  3. Oh sh**!, I just realized that I used the value from the datasheet table directly. But the UCA0MCTL register is placing the value at an other position. UCA0MCTL: UCBRFx [7:4], UCBRSx [3:1], UCOS16 [0] Baud rate table: UCBRx = 208 = 0x00, 0xD0 UCBRSx = 3 = 0b011 UCBRFx = 0 UCA0MCTL: 0000,011,0 = 0x06
  4. I am currently working on a project that is transferring data to a host computer via UART. Standard baud rate is 9600bps, UART is clocked with SMCLK 8MHz (using calibrated DCO values). I am not using the launchpad, the MSP430 is connected to the computer by a Prolific serial to USB converter. So far so good. To speed up the data transfer I implemented the feature to increase the baud rate by a command send from the computer. Target idea was to change from 9600 to 38400. It did not work, the MSP430 changed the baud rate but the PC could not identify the characters (I changed the baud rate on the PC as well). I changed the UART settings to 19200bps and it worked. Back to 38400, same problem. Double checking the settings revealed nothing. The suggested settings for 38400Bps are: UCA0BR0 = 0xD0 UCA0BR1 = 0x00 UCA0MCTL = 0x03 I then added some test code (see below) that looped the UART settings, varying the modulator value since this caused significant distortion at an other issue. It turned out that every time the modulator value has an even number 2, 4, 6, 8 the 38400 setting is working correctly. What can be the reason why the recommended modulator setting is not working? for (i=0; i<16; i++) { IE2 &= ~UCA0RXIE; IE2 &= ~UCA0TXIE; UCA0CTL1 |= UCSWRST; // UART state machine Reset UCA0CTL1 |= UCSSEL_2; // SMCLK UCA0BR0 = 0xD0; //0xD0; // 8 MHz, 38400 Bps UCA0BR1 = 0x00; //0x00; // 8 MHz, 38400 Bps UCA0MCTL = i; //0x03; // 8 MHz, 38400 Bps UCA0CTL1 &= ~UCSWRST; // UART state machine IE2 |= UCA0RXIE + UCA0TXIE; tempChar=i+48; transmitByte_UART(tempChar); transmitBytes_UART ("\r\n", 2); }
  5. I will try that. The fall back does probably not happen because ACLK is used with the crystal. The fall back seems only happen for MCLK.
  6. I am currently working on a project that uses the external crystal for the watchdog timer and the internal DSO clock for all other tasks. The crystal is 32kHz. The watchdog timer interrupt is taking care of controlling the state machine in the main loop. At first sight everything looks ok. However, after a while (hours later) the controller (MSP430G2553) appears to be stuck. Closer investigation show that this is due to the watchdog timer interrupt not served, means that the 32Khz clock is not present. I already tried to play with the XTAL capacitor settings to no effect. I am wondering if scope measures could be done in order to see if there is something ongoing in the clock circuit that could point to an issue with the XTAL capacitors, driver circuit, parasitics, etc. However, I do not know what exactly to look for. Can anyone help me here?
  7. I updated CCS from v5.5 to v6. I thought all existing projects and settings are migrated. However, after installing v6 I found now that a) both versions are now on my computer; v6 has not took over settings from the previous version and does even not detect the existing projects. Have I missed something or is there simply no way?
  8. @@KatiePier thanks for this info. I choose the G2553 because of the compact package/pincount plus UART+SPI capability. FR2933 is a bit oversized. I will stay with DCO for now, just hoping that the UART issue is solved. Do you know at what temperature the DCO calibration values are measured?
  9. Well, it might be a TI thing but the description of controller features is rather confusing. Looking at the device specific datasheet I get a brief overview on the first page, followed by the phrase "For Complete Module Descriptions, See the MSP430x2xx Family User
  10. Does someone know if there is an overview of MSP430 controllers and their modules (e.g. ADC12, BOR, SVS, ...) available? I was surprised to find out that for example the MSPG2553 has no SVS even though this is listed in the family user guide. So it would be great to have a spreadsheet showing all controllers and the present modules of each. I did already search for it but could not find anything useful beyond the standard I/O pin, flash memory, etc. tables.
  11. Thanks for pointing me to the MSPdebug. It looks like that works also with the Launchpad as programming hardware. Need to investigate this further. MSP-FET is to expensive since in some cases I want to give a programmer to a customer.
  12. I used to work with AVR a lot and are now converting some projects to MSP430. On the AVR I used a software called AVRdude together with a simple parallel port interface. A hex file was loaded into the tool which is programmed to the controller soldered into the target application. Also fuse bit's could be set, flash memory erased and checksums verified. This worked very efficient. 50 controllers could be programmed in less than an hour, AVRdude was running from the command line and working in batch-mode. Now on the MSP430 (in particular G2553) I am wondering if a similar tool/toolchain exists? I currently use CCS to program but that is far too slow in a semi production environment. I could imagine to use the launchpad to create the programming interface that connects to the PCB with the target controller. However, what programming tool similar to AVRdude is supporting this?
  13. I am using a Prolific USB to serial cable in order to communicate with the computer. However, the MSP430 will not only communicate with the computer in the final project, it will also communicate with a GPS sensor (which also transmits at 9600 baud). So since I encountered already issues with the connection to the PC it is quite likely the same problem goes on with the GPS. Bad thing here is that it may remain undetected. The issue was not like just one character was missing/wrong, the whole bit flow seemed to be shifted so that the PC/Prolific chip could not resync.
  14. Thanks for looking into this. However, I just checked what settings I used in my code. UCA0MCTL was loaded with 0x06 when the issue got present. I just took a look at table 15-2 to find the 0x4A relation to UCBRS=3. I might be blind but I can not see how this should correlate: 0x4A = 01001010 UCBRS=3 : 01010100 As a temporary fix I changed BRCLK to DSO generated clock. I will see if that improves the situation.
  15. Well, there is a nice document explaining how to calculate the correct modulator value: http://www.win.tue.nl/~johanl/educ/RTcourse/MSP430%20UART.pdf According to this (page 14, table 2) the modulator value should be 0x4A for ACLK 32768Hz and baud rate 9600. Looking into the G2553 datasheet (http://www.ti.com/lit/ug/slau144j/slau144j.pdf), chapter 15.4.5, shows the modulator register. Bit 0 is UCOS16 which should be 0 for low frequency mode (per section 15.3.9.1 Low-Frequency Baud Rate Generation). Bits 4-7 are ignored if UCOS16 is 0. This leaves bits 1-3 for possible modulation values. So how would I use the modulator 0x4A on these 3 bits ?
×
×
  • Create New...