LAUNCHXL-F280049C: SCI not working after power cycle

Hi Alessandro,

Flash_initModule() is the InitFlash() function.  

Are you able to execute your code (SCI functionality) fine from RAM and not from flash? 

Thanks and regards,
Vamsi

Dear Vamsi,

Thanks for your reply.

Yes, I can successfully run and debug the sci_ex3_interrupts_fifo with the LED blinking.

.

Thanks for your support

Kind Regards,

Alessandro

Hi Alessandro,

For the sci_ex3_interrupts_fifo example in C2000Ware, did you simply choose the flash build configuration and compile it?  OR did you make any changes apart from that?  

How are the boot mode pins configured on the board?  Hope they are set for flash boot - please confirm.

Also, please take a look at the below FAQ and see if it can help:  

How to modify an application from RAM configuration to Flash configuration?: https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/878674 

Thanks and regards,
Vamsi

Hi Vamsi,

Thanks for your reply and the link. The following is the boot configuration on my launchpad:

I confirm the sci_ex3_interrupts_fifo was not modified. Just to be 100% sure, I opened CCS in a new workspace and I started everything from scratch in a folder called tmpC/ccs as it follows:

1. I activated the TMS320F280049C_LaunchPad.ccxml targetConfig (The JTAG DR Integrity scan-test succeded when testing the connection)
2. I built and debugged the applications (both CPU1_LAUNCHXL_RAM and CPU1_RAM). Everything did work as expected.
   

   

3. I set the CPU1_LAUNCHXL_FLASH build configuration, and I compiled.
   
4. I closed CCS and I opened Uniflash, I selected the proper binary
   
5. I loaded and verified the image successfully:
   
6. As soon as the image is loaded,  I can see the message on putty (which I never closed)
7. As soon as the image is verified, the application restart, I can see the message on putty (which I never closed)
8. If I press the reset button on the launchpad, the application restart, I can see the message on putty (which I never closed)
9. At this point, I assume the flashing procedure was correctly done. Can you confirm, please?
10. I removed the USB cable from the laptop, putty disconnects (here the power cycle starts)
    
11. I closed putty 
12. I plugged the USB cable (here the power cycle is completed)
13. I opened putty (which does not report any error about the serial connection)
14. Even if a type 2 characters, there is no response from the launchpad
15. I pressed the reset button and I got the message below as expected
    

Initially, my assumption was that the application was not running. For that reason, I merged the LED blinking example.
As the LED did blink, my current assumption is that the SCI is not active after the power cycle. It wakes up only after a reset. Is this the normal behaviour? By digging into the code, my understanding is that the SCI peripheral should be enabled and powered up. Could you comment on this, please?

Sorry for the long post.

Thank you in advance for your support

Hi Alessandro,

Looks like GPIOs are configured for boot to flash.

#9. Since the Uniflash successfully loaded the code, flashing should be considered done.

SCI peripheral should be enabled as you can see below enables in the InitPeripheralClocks():

CpuSysRegs.PCLKCR7.bit.SCI_A = 1;
CpuSysRegs.PCLKCR7.bit.SCI_B = 1;

If you have further questions on SCI, I can assign to our SCI expert - let me know.

Thanks and regards,
Vamsi

Hi Vamsi,

Yes, please, if you could put me in contact with your SCI expert, that would be great. 

Wishing you a good start of the week
Thank you again for your support
Kind Regards,

Hi Alessandro,

I will assign this to our SCI expert. 

Thanks and best regards,

Vamsi

Thank you

Kind Regards,

Hi Alessandro,

Thanks for the detailed walkthrough of the steps you took. I think part of the issue might be in these steps I have quoted here (I'll explain after the quote). Below the quote I have also bolded and underlined three requests (for easier reading).

Alessandro Galassini said:

• I closed putty 
• I plugged the USB cable (here the power cycle is completed)
• I opened putty (which does not report any error about the serial connection)
• Even if a type 2 characters, there is no response from the launchpad

Between the first line I have quoted (#11 in original) and the third line (#13 in original), I believe the code may actually be running and outputting to the TX pin. The issue is that it is not possible to connect putty before the program has completed.

1. We can verify this by doing the following: can you take a scope capture or logic analyzer capture of the TX line at the time the USB is plugged in?

2. Now the last bullet mentioned is more concerning, in that there is no response. I would like to verify this by taking a scope/logic analyzer capture of the TX and RX pins during and after PuTTY transmission.

3. Please also provide the SCI initialization code. Even if this is unmodified, I want to see if it was a different version of the example (should not be, but want to be certain).

Please let me know if you have any questions on the above three requests.

Regards,

Vince

Dear Vince,

Thanks for your email.

I connected a Tektronic oscilloscope to the Tx and Rx pins.
Channel 1 in yellow is capturing data from Putty to the Launchpad.
Channel 2 in blue îs capturing data transmitted from the Launchpad to Putty.

I can confirm that after the power cycle, the welcoming message is transmitted from the Launchpad to Putty.
However, after restarting Putty, two characters are sent to the Launchpad, but the Launchapd does not reply. 

Below, you can find the captures:

1. I flashed the Launchapad and I opened Putty.
2. I set the trigger on Channel 2 and I pressed the reset button
   
   As exptected the welcoming message is sent to Putty
3. From Putty, I sent to characters:
   
   The application is replying as expected
4. I did a power cycle by disconnecting and re-connecting the USB cable:
   
   As exptected the welcoming message is sent to Putty (good news).
5. At this point, I restarted Putty which previously disconnected from the COM port and 
   I switched the trigger on Channel 1 in yellow.
   
   Two characters are sent from Putty to the Launchpad, but no reply is sent back (bad news).
6. After a reset via the S1 button (XRSn signal), the application works as expeted:
   

The code I am using is unmodified, I set up a workspace from scratch.
Unfortunately, attachements are not allowed here. I am not sure what you mean with SCI initialisation code.
The following is the main function from the example sci_ex3_interrupts_fifo:

void main(void)
{
    //
    // Configure PLL, disable WD, enable peripheral clocks.
    //
    Device_init();

    //
    // Disable pin locks and enable internal pullups.
    //
    Device_initGPIO();

    //
    // GPIO28 is the SCI Rx pin.
    //
    GPIO_setMasterCore(DEVICE_GPIO_PIN_SCIRXDA, GPIO_CORE_CPU1);
    GPIO_setPinConfig(DEVICE_GPIO_CFG_SCIRXDA);
    GPIO_setDirectionMode(DEVICE_GPIO_PIN_SCIRXDA, GPIO_DIR_MODE_IN);
    GPIO_setPadConfig(DEVICE_GPIO_PIN_SCIRXDA, GPIO_PIN_TYPE_STD);
    GPIO_setQualificationMode(DEVICE_GPIO_PIN_SCIRXDA, GPIO_QUAL_ASYNC);

    //
    // GPIO29 is the SCI Tx pin.
    //
    GPIO_setMasterCore(DEVICE_GPIO_PIN_SCITXDA, GPIO_CORE_CPU1);
    GPIO_setPinConfig(DEVICE_GPIO_CFG_SCITXDA);
    GPIO_setDirectionMode(DEVICE_GPIO_PIN_SCITXDA, GPIO_DIR_MODE_OUT);
    GPIO_setPadConfig(DEVICE_GPIO_PIN_SCITXDA, GPIO_PIN_TYPE_STD);
    GPIO_setQualificationMode(DEVICE_GPIO_PIN_SCITXDA, GPIO_QUAL_ASYNC);

    //
    // Disable global interrupts.
    //
    DINT;

    //
    // Initialize interrupt controller and vector table.
    //
    Interrupt_initModule();
    Interrupt_initVectorTable();
    IER = 0x0000;
    IFR = 0x0000;

    //
    // Map the ISR to the wake interrupt.
    //
    Interrupt_register(INT_SCIA_TX, sciaTxISR);
    Interrupt_register(INT_SCIA_RX, sciaRxISR);

    //
    // Initialize SCIA and its FIFO.
    //
    SCI_performSoftwareReset(SCIA_BASE);

    //
    // Configure SCIA for echoback.
    //
    SCI_setConfig(SCIA_BASE, 25000000, 9600, (SCI_CONFIG_WLEN_8 |
                                             SCI_CONFIG_STOP_ONE |
                                             SCI_CONFIG_PAR_NONE));
    SCI_resetChannels(SCIA_BASE);
    SCI_clearInterruptStatus(SCIA_BASE, SCI_INT_TXFF | SCI_INT_RXFF);
    SCI_enableFIFO(SCIA_BASE);
    SCI_enableModule(SCIA_BASE);
    SCI_performSoftwareReset(SCIA_BASE);

    //
    // Set the transmit FIFO level to 0 and the receive FIFO level to 2.
    // Enable the TXFF and RXFF interrupts.
    //
    SCI_setFIFOInterruptLevel(SCIA_BASE, SCI_FIFO_TX0, SCI_FIFO_RX2);
    SCI_enableInterrupt(SCIA_BASE, SCI_INT_TXFF | SCI_INT_RXFF);

#ifdef AUTOBAUD
    //
    // Perform an autobaud lock.
    // SCI expects an 'a' or 'A' to lock the baud rate.
    //
    SCI_lockAutobaud(SCIA_BASE);
#endif

    //
    // Send starting message.
    //
    msg = "\r\n\n\nHello World!\0";
    SCI_writeCharArray(SCIA_BASE, (uint16_t*)msg, 17);
    msg = "\r\nYou will enter a character, and the DSP will echo it back!\n\0";
    SCI_writeCharArray(SCIA_BASE, (uint16_t*)msg, 62);

    //
    // Clear the SCI interrupts before enabling them.
    //
    SCI_clearInterruptStatus(SCIA_BASE, SCI_INT_TXFF | SCI_INT_RXFF);

    //
    // Enable the interrupts in the PIE: Group 9 interrupts 1 & 2.
    //
    Interrupt_enable(INT_SCIA_RX);
    Interrupt_enable(INT_SCIA_TX);
    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP9);

    //
    // Enable global interrupts.
    //
    EINT;

    for(;;)
    {
    }
}

I hope this clarify the issue.

Thanks for your support

Kind Regards,

Alessandro

Hi Alsessandro,

Thanks again for the detailed walkthrough of the issue! So I think the issue is actually in this image:

As you can see, the C2000 devices beginning transmission, meaning SCI is running. However, as you can see at the top, the RX pin of the C2000 device is low. This means that during that time, the device is receiving a "BRKDT" error (breakdetect). This happens when the RX is pulled low for a certain amount of time (see TRM for the details on exact situations that cause it).

So basically, I think the issue is that the SCI module is being started (taken out of SCI reset) too soon (before the pull-up is enabled on the pin). Can you try adding a delay before the SCI initialization starts?

Basically, I would like to see all the Blue line communications to happen after the Yellow line goes high, because this means that both the TX and RX pull-ups are enabled (pin is ready).

Regards,

Vince