This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

F28M35/Concerto Register updates and other issues

Other Parts Discussed in Thread: CONTROLSUITE

Hello,

Since I got the Concerto Control card I've been testing the samples provided by the ControlSuite Software. I had no problems connecting it to the computer and entered debug mode (followed the steps to make a new project, outside ControlSuite folder, this information is on the pdf file F28M35x Firmware Development Package available in the doc folder of F28M35, in the ControlSuite).In this file there are instruction on how to assign different code to each of the cores and shows how to debug them, the examples codes are to program the master (M3) to blink the first 8 bits of the GPIO (GPIO0-7) and the control (F28335) for other 8 bits (GPIO 8-15).

Everything went ok till I tried to monitor the outputs bits using an oscilloscope. Most of the Control bits were OK, but the Master bits were not working. 2 problems here!

1- I said most of the bits because (in the code) it is written: "GpioDataRegs.GPADAT.all = 0x0000FF00;" during debuging the address has "0x00007F00" instead of the desired 0x0000FF00 (meaning Bit 15 isn't changing or is changing outside this code). Analyzing the assembly code for these lines (I'm no expert, don't know what is DP, or @0x0, but understand MOVL and by comparison, the 0x00FF00 :)

0x00804C:   8F00FF00      MOVL                   XAR4, #0x00ff00
0x00804E:   761F017F      MOVW                 DP, #0x17f
0x008050:   A800               MOVL                   @0x0, XAR4
0x008051:   FF69               SPM                       #0

Only when PC goes to 0x008051 the register (GPIOG1DAT.GPADAT) is updated with the 0x00007F00 value.

2- After realizing none of the master bits were showing up on the oscilloscope decided to monitor the register for GPIO_PORTA.GPIODATA on the Master core, the one that was supposed to be changing as seen in the code: "GPIOPinWrite(GPIO_PORTA_BASE, 0xFF, 0xFF);". It isn't being updated.

To discard any possibility of a misconfigured system/software (linker commands, build options) tried to run the blinky.c example for the Control Suite  F29m35 master folder and soon realized that although the led was blinking, the register for PORTC wasn't (also) being updated.

I missed something? The registers are being called from the menu View -> Registers.

Any suggestions are welcome.

Thank you for your time,

Rui Ventura

  • R. Ventura said:
    "GpioDataRegs.GPADAT.all = 0x0000FF00;" during debuging the address has "0x00007F00" instead of the desired 0x0000FF00 (meaning Bit 15 isn't changing or is changing outside this code).

    Rui,

    This is an oversite in the TI example.  GPIO15 is locked by default and has to be unlocked before it can be reconfigured.  This will be corrected in the next controlSUITE update.  In the meantime you can do the following to add the unlock function and see GPIO toggle:

    1) Download the attached gpio.c and gpio.h

    7167.gpio-lockunlock.zip

    2) Place these two files in your controlSUITE driverlib directory: i.e. C:\TI\controlSUITE\device_support\f28m35x\vBeta1\MWare\driverlib

    3) Import the driverlib project into CCS

     

    4) build driverlib

    5) in the M3 code, add the code in bold:

    //
    // Master Subsystem Controls GPIOA Pins
    // Control Subsystem Control GPIOB Pins
    // First unlock GPIO B 7

    GPIOPinUnlock(GPIO_PORTB_BASE, 0x90);

    GPIOPinConfigureCoreSelect(GPIO_PORTA_BASE, 0xFF, GPIO_PIN_M_CORE_SELECT);
    GPIOPinConfigureCoreSelect(GPIO_PORTB_BASE, 0xFF, GPIO_PIN_C_CORE_SELECT);

    6)  Load and run the M3 code

    7)  Load and run the C28x code

    R. Ventura said:

    2- After realizing none of the master bits were showing up on the oscilloscope decided to monitor the register for GPIO_PORTA.GPIODATA on the Master core, the one that was supposed to be changing as seen in the code: "GPIOPinWrite(GPIO_PORTA_BASE, 0xFF, 0xFF);". It isn't being updated.

    To discard any possibility of a misconfigured system/software (linker commands, build options) tried to run the blinky.c example for the Control Suite  F29m35 master folder and soon realized that although the led was blinking, the register for PORTC wasn't (also) being updated.

    I missed something? The registers are being called from the menu View -> Registers.

    The M3 data registers may behave differently than you are used to.  They actually take up 256 memory locations and the watch window is only showing the first location.  It is a bit involved to explain, so I will add a screenshot from the reference guide:

    From the above - the read is actually masked based on the offset from the base address.  If you open a memory window this will become more clear - here is the case where 0xFF was written.  Since the register window is only showing the base address, the mask is hiding the value.  I will talk to the team about this - we should probably instead show the location where the mask is 0xFF.

     

    Regards

    Lori

     

     

     

  •  

    Thank you Lori!

    I think I understand what you mean about the registers on the M3 :)
    I read the Technical Reference Manual 3.1.3 section a little too fast and miss that 3.1.3.2.2 about the registers in the M3,  as well as the 3.1.3.5 section about Commit Control, were its said that PB7 (NMI) is protected due to:

    "The GPIO commit control registers provide a layer of protection against accidental programming of critical hardware peripherals. Protection is provided for the NMI pin (PB7)."

    It doesn't explain how to remove this protection and browsing the "F28M35x Peripheral Driver Library" pdf, section 8.2 we see that there is no GPIO lock/unlock/status but in the new gpio.c and gpio.h sent by you, those functions exist:

    GPIOPinLock(unsigned long ulPort, unsigned char ucPins)
    GPIOPinUnlock(unsigned long ulPort, unsigned char ucPins)
    GPIOPinLockStatus(unsigned long ulPort, unsigned char ucPins)

    Anyhow, I now know what to do. Amazing job! Thank you for your answer!

    Rui

     

     

  • Dear Lori,

    I have the same problem with PB7 but with the UART1 peripheral,
    I did as you said and unlocked that pin but I can't seem to get interrupts on UART1.
    Any other pin for UART1 and PORTB works fine just not PB6 and PB7 (which I need for standalone mode with the concerto controlCard).

    Here is my code (It's a simple gateway between 2 uart modules - UART1IntHandler doesn't fire):

    void main(void)
    {
    // Allow writes to protected registers.
    HWREG(SYSCTL_MWRALLOW) = 0xA5A5A5A5;
    // Enable processor interrupts.
    IntMasterEnable();
    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    // Set GPIO A0 and A1 as UART pins (0 - RX, 1 - TX).
    GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
    GPIOPinConfigure(GPIO_PA0_U0RX);
    GPIOPinConfigure(GPIO_PA1_U0TX);
    // Set GPIO B0 and B1 as UART pins (8 - RX, 9 - TX).
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART1);
    GPIOPinUnlock(GPIO_PORTB_BASE, GPIO_PIN_7);
    GPIOPinConfigure(GPIO_PB7_U1RX);
    GPIOPinConfigure(GPIO_PB6_U1TX);
    GPIOPinTypeUART(GPIO_PORTB_BASE, GPIO_PIN_6 | GPIO_PIN_7);
    // Configure the UART for 460,800, 8-N-1 operation.
    UARTConfigSetExpClk(UART0_BASE, SysCtlClockGet(SYSTEM_CLOCK_SPEED), 460800,
    (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));
    // Configure the UART for 460,800, 8-N-1 operation.
    UARTConfigSetExpClk(UART1_BASE, SysCtlClockGet(SYSTEM_CLOCK_SPEED), 460800,
    (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));
    // Enable the UART interrupt.
    UARTEnable(UART0_BASE);
    IntRegister(INT_UART0, UART0IntHandler);
    IntEnable(INT_UART0);
    UARTIntEnable(UART0_BASE, UART_INT_RX | UART_INT_RT);
    UARTEnable(UART1_BASE);
    IntRegister(INT_UART1, UART1IntHandler);
    IntEnable(INT_UART1);
    UARTIntEnable(UART1_BASE, UART_INT_RX | UART_INT_RT);
    for(;;);
    }
    void UART0IntHandler(void)
    {
    unsigned long ulStatus;
    // Get the interrupt status.
    ulStatus = UARTIntStatus(UART0_BASE, true);
    // Clear the asserted interrupts.
    UARTIntClear(UART0_BASE, ulStatus);
    // Loop while there are characters in the receive FIFO.
    while (UARTCharsAvail(UART0_BASE))
    {
    long data = UARTCharGetNonBlocking(UART0_BASE);
    UARTCharPutNonBlocking(UART1_BASE, (unsigned char) data);
    }
    }
    void UART1IntHandler(void)
    {
    unsigned long ulStatus;
    // Get the interrupt status.
    ulStatus = UARTIntStatus(UART1_BASE, true);
    // Clear the asserted interrupts.
    UARTIntClear(UART1_BASE, ulStatus);
    // Loop while there are characters in the receive FIFO.
    while (UARTCharsAvail(UART1_BASE))
    {
    long data = UARTCharGetNonBlocking(UART1_BASE);
    UARTCharPutNonBlocking(UART0_BASE, (unsigned char) data);
    }
    }
    
    

    Thanks,

    Yoel