Raged's Groups Activities

CCS/MSP432P401R: XDS110 Debug probe and Emulation package 8.2.0.00004 issue

Raged — Thu, 01 Aug 2019 21:47:00 GMT

Part Number: MSP432P401R
Other Parts Discussed in Thread: UNIFLASH

Tool/software: Code Composer Studio

Hi,

For months, I have been flawlessly developing on my MSP432. However, I currently I started receiving the following error.

I have tried all of the suggestions outlined here:

e2e.ti.com/.../1786284

The problems seemed to have started as soon as I updated the emulation package to (Emulation package 8.2.0.00004). I have uninstalled ccs and reinstalled it many times but have not been able to get ti to work again. Any help is really appreciated.

MSP432P401R: Picking Daises at 48 MHz with an MSP432....

Rob Frohne — Tue, 16 May 2017 23:13:11 GMT

Part Number: MSP432P401R

Hi All,

I have been trying to figure out why my ADC14 application is so flaky. Sometimes it seems to work and sometimes not. I would really like to go at full speed if possible to make measurements from several different analog inputs at as near to the same time as possible with the ADC14. Because of this I was trying to set the clock so it would go at that frequency. I have narrowed my problem down to the following code. When I change the CS_DCO_FREQUENCY_48 to CS_DCO_FREQUENCY_24 it works wonderfully, but when I don't, single stepping along, it goes picking daises as soon as the MCLK is set at 48 MHz, and ends up at:

No source available for "0x9b28"

 * This was modified by Rob Frohne
 ******************************************************************************/
#include <ti/devices/msp432p4xx/driverlib/driverlib.h>

int main(void)
{
    // Halting WDT
    WDT_A_holdTimer();

    // Set to Vcore1
    PCM_setCoreVoltageLevel(PCM_VCORE1);

    // Set to use DCDC
    PCM_setPowerState(PCM_AM_DCDC_VCORE1);

    // Initializes Clock System
    CS_setDCOCenteredFrequency(CS_DCO_FREQUENCY_48);
    CS_initClockSignal(CS_MCLK, CS_DCOCLK_SELECT, CS_CLOCK_DIVIDER_1 );
    //CS_initClockSignal(CS_HSMCLK, CS_DCOCLK_SELECT, CS_CLOCK_DIVIDER_1 );
    CS_initClockSignal(CS_SMCLK, CS_DCOCLK_SELECT, CS_CLOCK_DIVIDER_2 );
    //CS_initClockSignal(CS_ACLK, CS_REFOCLK_SELECT, CS_CLOCK_DIVIDER_1);

    while(1)
    {
    }
    return 1;
}

This is with a "Red Launchpad". Any ideas?

Thanks,

Rob

Custom CCXML not working between old and new devices (both are rev C.)

Raged — Tue, 18 Jul 2017 11:00:41 GMT

Hi Chris,

I have been having issues with this file. I have been using two versions of the .ccxml file without problem for quite some time flashing a batch of MSP432's.

***version 1***
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
    <configuration XML_version="1.2" id="configuration_0">
        <instance XML_version="1.2" desc="Texas Instruments XDS110 USB Debug Probe" href="connections/TIXDS110_Connection.xml" id="Texas Instruments XDS110 USB Debug Probe" xml="TIXDS110_Connection.xml" xmlpath="connections"/>
        <connection XML_version="1.2" id="Texas Instruments XDS110 USB Debug Probe">
            <instance XML_version="1.2" href="drivers/tixds510cs_dap.xml" id="drivers" xml="tixds510cs_dap.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds510cortexM.xml" id="drivers" xml="tixds510cortexM.xml" xmlpath="drivers"/>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="MSP432P401R" href="devices/msp432p401r.xml" id="MSP432P401R" xml="msp432p401r.xml" xmlpath="devices"/>
            </platform>
        </connection>
    </configuration>
</configurations>

***version 2***
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
    <configuration XML_version="1.2" id="configuration_0">
        <instance XML_version="1.2" desc="Texas Instruments XDS110 USB Debug Probe" href="connections/TIXDS110_Connection.xml" id="Texas Instruments XDS110 USB Debug Probe" xml="TIXDS110_Connection.xml" xmlpath="connections"/>
        <connection XML_version="1.2" id="Texas Instruments XDS110 USB Debug Probe">
            <instance XML_version="1.2" href="drivers/tixds510cs_dap.xml" id="drivers" xml="tixds510cs_dap.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds510cortexM.xml" id="drivers" xml="tixds510cortexM.xml" xmlpath="drivers"/>
            <property Type="choicelist" Value="2" id="SWD Mode Settings">
                <choice Name="SWD Mode - Aux COM port is target TDO pin" value="nothing"/>
            </property>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="MSP432P401R" href="devices/msp432p401r.xml" id="MSP432P401R" xml="msp432p401r.xml" xmlpath="devices"/>
            </platform>
        </connection>
    </configuration>
</configurations>

The only difference between these two files is the following lines appearing only in version 2:

Now, I received a new batch of MSP432's and can only program them using the version 1 and not version 2 (version 1 and version 2 are being used to create two separate sections of IP). I would have never noticed this difference until I run into this problem. I am wondering if there's a difference in the silicon. All the silicon I am using is marked REV C. Would it be a problem to just revert back to version 1 of the ccxml file and use it . Any help would be really appreciated.

-Edgar

CCS/MSP432P401R: Disabling JTAG/SWD access repeatability

Raged — Fri, 05 May 2017 15:17:37 GMT

Part Number: MSP432P401R

Tool/software: Code Composer Studio

Hi,

I have a basic question about the JTAG/SWD behavior after it has been disabled once.

Using the sample code provided here "www.ti.com/.../slaa659" , I was able to successfully lock access to the MSP432401R dev board (Rev 2.1) using the "disable_jtag_swd" sample project. I performed a factory reset to regain access to the device and successfully loaded another simple blink led program to corroborate accessibility to the device.

I then attempted to disable JTAG/SWD by using the "disable_jtag_swd" sample project once more, but it seems that I have debug access to the device no matter what now. I do not need to do a factory reset anymore. As far as I understand ,the JTAG/SWD disable/enable functionality can be done/undone repeatedly as I described using a factory reset.

Am i missing something basic on the expected JTAG/SWD disable/enable functionality?

Any help is greatly appreciated.

Thanks,

-Edgar

CCS/MSP432P401R: JTAG/SWD Protection

Raged — Wed, 03 May 2017 18:13:16 GMT

Part Number: MSP432P401R

Tool/software: Code Composer Studio

Hi,

I want to lock any access to my code (it doesn't need to be field updatable for the first test units we're ready to deploy). Securing JTAG and SWD access seems to be the option that best fits my needs right now. There's a document pointing me to get more information via the Resource Explorer as shown below. However, the figure seems to be outdated. Where can I find information on executing JTAG/SWD lockout in my MSP432?

Thanks,

-Edgar

CCS/MSP-EXP432P401R: Can't find a source file at ".... " error

Raged — Mon, 13 Mar 2017 22:21:25 GMT

Part Number: MSP-EXP432P401R

Tool/software: Code Composer Studio

I have a modular mathematical model that I can easily expand and contract. I have no problem flashing the code with up to 6 of my module, but, when I try to store more that that, I get a run time error: it says:

Can't find a source file at "C:\space\msp432-driverlib\build\MSP432P4xx/flash.c"
Locate the file or edit the source lookup path to include its location.

With the maximum size of code, I use 59% of flash and 49% of SRAM.

Any help in pointing me in the right direction is much appreciated.

Thanks,

-Edgar

MSP432 SPI with DMA

John Murdoch — Wed, 16 Sep 2015 22:39:35 GMT

Hi,

I'm a bit new to this...

I'm wanting to improve the performance of the SPI, I understand that using DMA is the best solution.

Are their any example of SPI with DMA?

Currently without DMA, I have the SPI setup to send 1 byte at a time with:

SPI_transmitData(LCD_EUSCI_MODULE, data);

What I want to do is change this so I can fill a buffer with bytes, then say Send. Once thats finished sending I want to fill the buffer again and send the next set of bytes.

I tried to use this code although it appears to hang at the last line!

    DMA_enableModule();
    DMA_setControlBase(m_controlTable);

    DMA_assignChannel(DMA_CH0_EUSCIB0TX0);

    DMA_disableChannelAttribute(DMA_CH0_EUSCIB0TX0, UDMA_ATTR_ALTSELECT | UDMA_ATTR_USEBURST | UDMA_ATTR_HIGH_PRIORITY | UDMA_ATTR_REQMASK);

    DMA_setChannelControl(UDMA_PRI_SELECT | DMA_CH0_EUSCIB0TX0, UDMA_SIZE_8 | UDMA_SRC_INC_8 | UDMA_DST_INC_8 | UDMA_ARB_8);
    DMA_setChannelTransfer(UDMA_PRI_SELECT | DMA_CH0_EUSCIB0TX0, UDMA_MODE_BASIC, m_data_array, (void*)SPI_getTransmitBufferAddressForDMA(EUSCI_B0_MODULE), 1024);

    DMA_assignInterrupt(DMA_INT1, 0);
    Interrupt_enableInterrupt(INT_DMA_INT1);

I was planning to use the code above by filling the buffer "m_data_array" then calling DMA_enableChannel(0); although this didn't work.

How do i know when the buffer has been transmitted?

MSP432P401R: CS_setDCOFrequency driver function does not accept 40MHz since upgrade to REV C, red experimenter board (worked on REV B, black board)

Raged — Fri, 30 Dec 2016 16:06:13 GMT

Part Number: MSP432P401R
Other Parts Discussed in Thread: MSP432WARE

Since the upgrade from REV B to REV C, trying to set the DCO to 40MHz using the CS_setDCOFrequency driver sends me to the fault ISR and I get the following message as well.

CORTEX_M4_0: Trouble Halting Target CPU: (Error -1266 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 6.0.504.2)

I get the same issue/warnings using the MSP432ware provided "cs_dco_frequency_tune" sample project when I try to set up the DCO to 40MHz.

Is this a bug with the driver or is it a new limitation in the Silicon?

Any help is very much appreciated.

-Edgar.

Some questions about my first MSP432 / DriverLib SPI code

kazola — Thu, 07 May 2015 09:40:54 GMT

Good morning!

I have prepared this code inspired on an example from TI. I want to communicate my MSP432 through SPI to an external device. I use USCB0 since it is useful for my own launchpads! :) The external device works because I did this same code for MSP430G and it works perfectly.

Ok, let's go through it. Do not laugh very loud since it is my first MSP432 & DriverLib attempt. Hope it will avoid some register tweaking in my future life if I ever get comfortable enough with it. Great lib, by the way.

Here comes the code!

/*
 * ACLK = ~32.768kHz, MCLK = SMCLK = DCO ~ 1MHz
 *
 * MSP432 = SPI master, external device = SPI slave
 *
 *                MSP432P401
 *              -----------------
 *             |                 |
 *             |            P4.3 |-> CS
 *             |                 |
 *             |            P1.6 |-> Data Out (UCB0SIMO)
 *             |                 |
 *             |            P1.7 |<- Data In (UCB0SOMI)
 *             |                 |
 *             |            P1.5 |-> Serial Clock Out (UCB0CLK)
 *******************************************************************************/
/* DriverLib Includes */
#include "driverlib.h"

/* Standard Includes */
#include <stdint.h>
#include <stdbool.h>


static volatile uint8_t RXData[10];
static volatile uint8_t i = 0;
static uint8_t TXData = 0;
static uint8_t ii = 0;


/* SPI Master Configuration Parameter */
const eUSCI_SPI_MasterConfig spiMasterConfig =
{
        EUSCI_B_SPI_CLOCKSOURCE_ACLK,              // ACLK Clock Source
        32768,                                     // ACLK = LFXT = 32.768khz
        500000,                                    // SPICLK = 500khz
        EUSCI_B_SPI_MSB_FIRST,                     // MSB First
        EUSCI_B_SPI_PHASE_DATA_CHANGED_ONFIRST_CAPTURED_ON_NEXT,    // Phase
		EUSCI_B_SPI_CLOCKPOLARITY_INACTIVITY_LOW, // low polarity
        EUSCI_B_SPI_3PIN                           // 3Wire SPI Mode
};


int main(void)
{
    volatile uint32_t ii;

    /* Halting WDT  */
    WDT_A_holdTimer();

    /* Starting and enabling LFXT (32kHz) */
    GPIO_setAsPeripheralModuleFunctionOutputPin(GPIO_PORT_PJ, GPIO_PIN0 | GPIO_PIN1, GPIO_PRIMARY_MODULE_FUNCTION);
    CS_setExternalClockSourceFrequency(32768, 0);
    CS_initClockSignal(CS_ACLK, CS_LFXTCLK_SELECT, CS_CLOCK_DIVIDER_1);
    CS_startLFXT(CS_LFXT_DRIVE0);


    /* Selecting P1.0 as LED */
    GPIO_setAsOutputPin(GPIO_PORT_P1, GPIO_PIN0);
    GPIO_setOutputHighOnPin(GPIO_PORT_P1, GPIO_PIN0);


    /* SPI --> P4.3 = CS, P1.5 = CLK, P1.6 = MOSI & P1.7 = MISO */
    GPIO_setAsPeripheralModuleFunctionInputPin(GPIO_PORT_P1, GPIO_PIN5 | GPIO_PIN6 | GPIO_PIN7, GPIO_PRIMARY_MODULE_FUNCTION);
    GPIO_setAsOutputPin(GPIO_PORT_P4, GPIO_PIN3);
    GPIO_setOutputLowOnPin(GPIO_PORT_P4, GPIO_PIN3);


    /* Configuring SPI in 3-wire master mode & enabling it & interrupts */
    SPI_initMaster(EUSCI_B0_MODULE, &spiMasterConfig);
    SPI_enableModule(EUSCI_B0_MODULE);
    SPI_enableInterrupt(EUSCI_B0_MODULE, EUSCI_B_SPI_RECEIVE_INTERRUPT);
    Interrupt_enableInterrupt(INT_EUSCIB0);
    Interrupt_enableSleepOnIsrExit();
    /* Delaying waiting for the module to initialize */
    for(ii=0;ii<100;ii++);


    /* SPI, put CS high P4.3 and polling to see if the TX buffer is ready or busy */
    GPIO_setOutputHighOnPin(GPIO_PORT_P4, GPIO_PIN3);
    TXData = 0x40;
    while (!(SPI_getInterruptStatus(EUSCI_B0_MODULE,EUSCI_B_SPI_TRANSMIT_INTERRUPT)));
    SPI_transmitData(EUSCI_B0_MODULE, TXData);
    TXData = 0x00;
    while (!(SPI_getInterruptStatus(EUSCI_B0_MODULE,EUSCI_B_SPI_TRANSMIT_INTERRUPT)));
    SPI_transmitData(EUSCI_B0_MODULE, TXData);


    while(1) {}
	/*PCM_gotoLPM0();
    __no_operation();*/
}


void euscib0_isr(void)
{
    uint32_t status = SPI_getEnabledInterruptStatus(EUSCI_B0_MODULE);
    SPI_clearInterruptFlag(EUSCI_B0_MODULE, status);

    if(status & EUSCI_B_SPI_RECEIVE_INTERRUPT)
    {
        RXData[i++] = SPI_receiveData(EUSCI_B0_MODULE);
        if ((i % 2) == 1) {
        	 for( ii=0;ii<10;ii++);
        	 GPIO_setOutputLowOnPin(GPIO_PORT_P4, GPIO_PIN3);
        }

    }
}

SPI CS is pulled down after 2nd byte. Yes, quite ugly but I did fast :) In fact, the code goes up to the final loop. But I can see no answer on my MISO line! 0x40 means "read register 0" so I should be seeing back the default value which is not 0xFF :) You can see this in my picture below. Again, the slave hardware is checked to work. And even the ISR fires! So let me know your opinions about what I'm doing wrong and have a nice day :)

CC530 long startup time (~1min and 30sec)

Raged — Tue, 14 Jun 2016 17:32:38 GMT

Other Parts Discussed in Thread: CC2530, Z-STACK

Hi,
Is it normal for the CC2530 to take ~ a minute and a half to startup after power up? I'm running it from an MSP432 in UART mode. The hangup is initially waiting for the P0.4 | RT line to come low. I've monitored this with the oscilloscope. Otherwise, after the initial setup, it all works fine. Is this normal?

Any help is greatly appreciated.

Thanks,

-Edgar

Z-STACK-MESH: ZigBee Mesh Solutions UART long startup time issue CC2530 ZNP-MSP432

Raged — Mon, 17 Oct 2016 19:55:12 GMT

Other Parts Discussed in Thread: CC2530, CC2531EMK, Z-STACK

Hi,

I've been dealing with a long delay (>1 minute) using the UART communication on a CC2530.

It only occurs during initial setup. I have used the .hex file provided by TI for the generic mesh project. Finally, we tried a trial version of IAR to compile the very project that the TI-issued .hex compiled file claims to be associated with. Using this compiled version works great! There's not delay whatsoever. Is there a reason for this? Is there something in the compiled file from TI that would keep the co-processor (in this case my MSP432) waiting for a ling time?

Please let me know.

Thanks,

-Edgar

CC2530 Inidividual Pin access via Interface Specification command SYS_GPIO

Raged — Mon, 17 Oct 2016 20:08:33 GMT

Other Parts Discussed in Thread: CC2530

Hi,

I'm using the MSP432 as a co-processor interfacing with the CC2530 via UART using TI's Z-STACK-MESH ZigBee stack. In the CC2530-ZNP ZigBee PRO Network Processor interface specification document, there's a SYS_GPIO command that seems close to achieve what I want to achieve. But, I am not clear on how I can individually access pins on different ports. It only specifies pins0-3 but not of what port (ports?) I can modify via this command. AS per the documentation:

4.1.12 SYS_GPIO
4.1.12.1 Description
This command is used by the application processor to configure the accessible GPIO pins on the
CC2530-ZNP device. There are four accessible GPIO pins (GPIO0-3) on the CC2530-ZNP
device.

Any guidance on this will be greatly appreciated.

Thanks!

-Edgar

MSP432 retrieve programmed hex file

Raged — Thu, 22 Sep 2016 20:14:24 GMT

Hi,

I need to retrieve the HEX file from a couple of MSP432 boards. I need to compare them to each other to confirm that data obtained with each board uses the same firmware version. Is there a way to do this via CCs V6?

Thanks,

-Edgar

CORTEX_M4_0: Error connecting to the target: (Error -1063 @ 0x0) Device ID is not recognized or is not supported by driver. Confirm device and debug probe configuration is correct, or update device driver. (Emulation package 6.0.14.5)

Raged — Tue, 13 Oct 2015 16:45:10 GMT

Hi ,

I have a rather puzzling issue. I get the following error when trying to debug the MSP-EXP432P401R using the BlinkLED_MSP432P401R example:

CORTEX_M4_0: Error connecting to the target: (Error -1063 @ 0x0) Device ID is not recognized or is not supported by driver. Confirm device and debug probe configuration is correct, or update device driver. (Emulation package 6.0.14.5)

I have been able to run several programs up until earlier this morning, and, all of the sudden, the board just stopped communicating.

Was there a recent update?

I have downloaded and installed (re-installed?) the ti_emupack_setup_6.0.14.5_win_32.exe in an attempt to fix any software driver issues, but the problem remains unchanged.

MSP432 interrupt priority issue after CMSIS

Raged — Thu, 16 Jun 2016 21:15:33 GMT

Hi, After I migrated my software to the CMSIS compatible version I'm having issues with my interrupt prioritization:

Previously the following code worked just fine:

    MAP_Interrupt_setPriority(INT_EUSCIA1, 0x03);//Set the EUSCIA1 interrupt  priority
    MAP_Interrupt_setPriority(INT_TA1_N, 0x04);//Set the INT_TA1_N interrupt  priority
    MAP_Interrupt_setPriority(INT_PORT6, 0x05);//Set the INT_PORT_6 interrupt priority

Now, I get stuck at the loop waiting for the interrupt associated with Port6 pin2 to be activated. It only gets to the interrupt once. It is expecting to be receiving an interrupt at Port6_Pin2 more than once. After the first time the interrupt is activated, subsequent falling edges on Port6_Pin2 get seemingly ignored.

If I go back and program the MSP432 with the pre CMSIS compatible version of the software, everything works fine. Is there anything in the NVIC that changed? Maybe the implementation of the driver library?

Any help will be much appreciated. Thanks!

-Edgar