About the reset of F28027 launchpad

Hello,

If you clear the interrupt flag in the beginning of the program (before main loop), will it work?

Best regards,

maria

Hello,

which level of interrupt's flag do u mean? The peripheral frame , pie or CPU. To sci, the interrupt flag(rarely/brkdt) is automatically handled, and I have cleared the pieifr and ifr(CPU) before the main loop.

best regards,

lee

What I mean is PIEIFR and IFR.

This makes me wondering. I will try simple SCI + its interrupt in my C2000 LP and let you know what I find.

Best regards,

Maria

I think I have clear PIEIFR and IFR before the main loop.

Actually, as I have said before, the program runs normally after I reset the CPU(press the rst button,XRS signal). Only at the first time when the board is powered up, the program runs with problem.

It seems that at the first start, the interrupt initial program is not excuted, because i set a gpio high before the main loop, but at the first start the gpio is low. Does that means the program is not excuted or there is something wrong with the initial program? Is there any initial sequence i should follow or this is just the hardware problem?

By the way, the C2000 LP has a factory program, maybe we can try that program, to see whether it works at the first power up(Unfortunately i have erased that).

Best regards,

Lee

Hello Lee,

I got the same behaviour like yours. The interrupt doesn't work after power ON, but works after reset button is pressed.

I tried also without interrupt (echoback example) and the same behaviour occurs (need to reset in order to make the code works).

I am not sure whether this is hardware case or other.

Maybe this is hardware case which is GPIO28-GPIO29 connected to FTDI chip.

Can you try to use another pins and see whether this problem still occurs?

About the C2000 LP original code, you can find it in controlSuite.

C:\TI\controlSUITE\development_kits\C2000_LaunchPad\f2802x_examples\C2kLaunchPadDemo

Best regards,

Maria

Maria,

Thank you so much for your help here : )

I will try the demo program to see whether there is the same problem. And may I ask what do you mean by "use other pins", do u mean to change the hareware connection(GPIO28-29)?

Best regards,

Lee

Hello Lee,

Actually it is not that easy to test another SCI pins because we need to connet it to another TTL chip for SCI/UART (for example MAX232) and then connect it to Serial Port of our PC (if our PC has any).

But if you can, I recommend you to do it.

However as sharing, previously I have made custom board based on C2000 launchpad and use SCI for Modbus communication (I use RX interrupt in my Modbus code) and this behavior doesn't appear. I can start the SCI communication without pressing any reset button (there is no reset button in my board) after repowering it.

In this board, I don't connect SCI pins to FTDI. I use chip for Modbus.

So if you want to continue to use SCI, I think you don't need to worry about this behavior. But to make sure better test it first.

Best regards,

Maria

Hello Maria,

I will try other SCI pins if I have time, and I think this is not a very serious problem. Maybe it is the hardware characteristic because u have met the same problem and I cannot find any software problem.

so thank u very much for your help again.

Best regards,

Lee

Hello Lee,

What is the position of S1 switches when you power up the LP? Is switch 3 in up/ON position (most likely will be in this position, since this allow you to debug using ccs through the usb connection) ?

Have you try running/power up the launchpad with S1 switch 1 & 2 ON/up and switch 3 OFF/down? (This will force the microcontroller to boot directly from flash provided you didn't mess with the OTP_KEY and OTP_BMODE)

I don't have 28027LP to try this, but seeing that the problem only happen when you power up, the only thing i can see from the schematic is the FTDI chip is pulling up the TRST pin briefly during power up (when its doing its own init, i.e. reading the EEPROM for configuration) so the microcontroller goes to emulation boot mode, and once FTDI chip is initialized the TRST pin is at logic low, so when you press reset button the microcontroller boot from flash, hence your program ran properly after pressing the reset button. This is just my guess though :)

Cheers,

Adi

Hello Adi,

I have try diffierent positions of S1 when I power up, and there is no difference in program running(SCI interupt isnt functional). I dont think it is the boot problem, because the first time 2000LP is powered up, other functions run normally(GPIO, CPU Timer interupt), this means the program is runing.

I think it is more likely to be the hardware problem(FTDI) in powering up, but I havent found it, what do u think?

Best Regards,

Lee

Hello, i am newcomer and i have  question: in controlSuite examples for tms320f28027 there are several versions of program:

C:\ti\controlSUITE\device_support\f2802x\v127:

void main(void)
{

// Step 1. Initialize System Control:
// PLL, WatchDog, enable Peripheral Clocks
// This example function is found in the DSP2802x_SysCtrl.c file.
   InitSysCtrl();

and 

C:\ti\controlSUITE\device_support\f2802x\v220

// Initialize all the handles needed for this application

  CPU_Handle myCpu;
PLL_Handle myPll;
WDOG_Handle myWDog;
void main(void)
{
myClk = CLK_init((void *)CLK_BASE_ADDR, sizeof(CLK_Obj));
myCpu = CPU_init((void *)NULL, sizeof(CPU_Obj));
myFlash = FLASH_init((void *)FLASH_BASE_ADDR, sizeof(FLASH_Obj));
myGpio = GPIO_init((void *)GPIO_BASE_ADDR, sizeof(GPIO_Obj));
myPie = PIE_init((void *)PIE_BASE_ADDR, sizeof(PIE_Obj));
myPll = PLL_init((void *)PLL_BASE_ADDR, sizeof(PLL_Obj));

myWDog = WDOG_init((void *)WDOG_BASE_ADDR, sizeof(WDOG_Obj));
//   InitSysCtrl();

----

Why in the in the newer version v200 function InitSysCtrl() not used? Instead, it uses (This is done for clarity?)

WDOG_disable(myWDog);
CLK_enableAdcClock(myClk);
(*Device_cal)();
//Select the internal oscillator 1 as the clock source
CLK_setOscSrc(myClk, CLK_OscSrc_Internal);
// Setup the PLL for x10 /2 which will yield 50Mhz = 10Mhz * 10 / 2
PLL_setup(myPll, PLL_Multiplier_10, PLL_DivideSelect_ClkIn_by_2);
// Disable the PIE and all interrupts
PIE_disable(myPie);
PIE_disableAllInts(myPie);
CPU_disableGlobalInts(myCpu);
CPU_clearIntFlags(myCpu);
---

Hi vladimir ,

Its always good if you start your own thread for a new query! Please start a new one and you'll get an answer immediately.

Regards,

Gautam

Hello Lee,

Sorry it took me long time to reply, I've been very busy this last couple of weeks.

If disconnecting TRST from the FTDI (by setting S1=ON,ON,OFF) doesn't solve the issue, it makes me think that its not the FTDI chip that cause the problem.

Also you mention that pressing reset will make your program works, looking at the schematic, the reset button is only connected to XRS pin of the microcontroller, which mean it only reset the microcontroller not the FTDI chip, this makes me think the issue is around the microcontroller.

An easy check you can do to see if the FTDI is working from the start is looking at the TX led(D8) and RX led(D7), you mention that function 1 of your program works at first power up, so RX led should blink every second (your function 1 send char every sec), and when you send a char from computer the TX led should blink once. This confirm that the FTDI is receiving char from the micro (rx led blink) and sending char from computer (tx led blink). If you have an oscillscope handy you could further check if the FTDI is actually sending out signal from its tx pin :).

On one of your post you also mention that when you set a gpio high before the main loop it does not work (this also happen at first power up only i assume), its like the microcontroller gets the wrong entry point but only during first power up, very odd. Does function 1 send the character correctly at first power up (i.e. correct baud rate hence you receive the character correctly in the computer and correct repetition rate i.e. every second)?

You might want to check your initialization code and make sure everything is done correctly, here are few things you can check,
 - is your code entry point set up correctly? check your linker cmd file and linker option.
 - if you use the PLL to increase your system clock, have you follow the correct procedure to set it up?
 - have you initialize the flash? (this maybe not be relevant for you since you are running your code from ram)

hope that helps :), if I have time I will try to see if i can replicate the issue on my experimenter kits, although i doubt it since I never had an issue with the serial on that board.


Cheers,

Adi

Hello vladimir,

Like Gautam said its probably better if you start your own thread if you have a new query, however I will try to see if I can answer your question since you already posted here.

The newer version (v200 and above) examples use Software Driver Model, hence the handle objects, it also put all the initialization calls in main(), the older version use Direct Register Access Model and put all the initialization call/code in InitSysCtrl(). So its basically doing the same thing.

I guess like you said its for clarity and to show the Software Driver Model being used. You could if you want move the initialization code to a function call and then just call it from main().

For more detail about the Software Driver Model and Direct Register Access Model you could read the documentations, in your case you probably will find it in C:\ti\controlSUITE\device_support\f2802x\v220\doc\, its called f2802x-DRL-UG.pdf

Hope that helps.

Cheers,

Adi

Hello Adi,

Thank you very much for your recommendation.

First I will check the FTDI TX by an oscillscope to see if the FTDI works normally, it is a good way to see whether it is the FTDI's problem.

And at first power up, the sending function works, means the c2000lp sends a char every sec to the computer. I use a uart test software to receive and send , and it receives a char/sec. So I think the software entry has no problem. But in case i will check the cmd file again.

By the way,my code runs from flash not ram, because if it runs from ram, the code has to be loaded by ccs, so there won't be any problem. Only when runs from flash there is the first powerup problem.

Best Regards,

Lee

Hello Lee,

I was working on my project using experimenter kits earlier and I thought i gave it a try to see if I can replicate your issue, as I was writing the receive interrupt handler when I realize there is a condition that I didn't consider before that can cause issue with the receive interrupt if not handled properly, its when the receiver detect a break condition (often not handled or ignored since it rarely happened).

Looking at the schematic of 28027LP if one of the few scenario (that I can think of) does happen then the SCI receiver could detect a break every time at first power up. And since RXINT is generated whenever RXRDY or BRKDT is observed, if break condition not handled (i.e. BRKDT flag not cleared) then RXINT will always be generated.

Did you check for break condition? If not and this is the issue then detecting break flag and clearing it would solve it. In my case I add these code in the receive interrupt handler:

SCI_Obj *sci = (SCI_Obj *)mySciHandle;  //mySciHandle is my global handle for SCIA replace it with your handle.
if (sci->SCIRXST & SCI_SCIRXST_BRKDT_BITS){
    SCI_reset(mySciHandle);  // Clear all error flag using SW RESET
    SCI_enable(mySciHandle);
}

Or if you use direct register access style (like in my older code) this will do it:

if (SciaRegs.SCIRXST.bit.BRKDT){
    SciaRegs.SCICTL1.bit.SWRESET = 0;  // Clear all error flag using SW RESET
    SciaRegs.SCICTL1.bit.SWRESET = 1;
}

Cheers,

Adi

Hello Adi,

Sorry to reply late because I haven't been in my work place these days:)

I think the break condition configuration you said is a possible problem. Actually I have configured the break condition but I just set it as default followed by the user guide and I haven't considered it carefully. So I will look into it to see whether the problem is happening here.

Do you mean that at the first power up, there may be an error happen, and I haven't clear the error flag, so the RXINT keeps generating which cause the UART receiving can't work normally. Is my understanding right?

Best regards,

Lee

Hello Lee,

Yes you are right.

If for some reason at first power up the RX pin (GPIO28) got pulled low for more than 20 bits time the microcontroller will set BRKDT flag and if not cleared it will keep generating RXINT and cause UART receiving not to work properly.

Also I forgot to mention on the previous post, without the code to detect and clear BRKDT flag, by simulating break condition (i.e. I diliberately connect rx pin to ground before powering up), I actually manage to create similar situation on my experimenter kit, that is I have to reset the microcontroller to make UART receiving works after power up.

Anyway try to detect and clear BRKDT flat and see if that works for you :)

Cheers,

Adi

Hello Adi,

I have tried your solution and it works, but still there are some questions.

I add your code below in the main loop:

if (SciaRegs.SCIRXST.bit.BRKDT){
    SciaRegs.SCICTL1.bit.SWRESET = 0;  // Clear all error flag using SW RESET
    SciaRegs.SCICTL1.bit.SWRESET = 1;
}

and the sci recieving function works normally at the first power-up. But in the UG it says the error and break condition cause an receive interrupt, so I suppose that I should reset SCI in the receive interrupt function so I add the code there. But it seems that the interrupt doesnt happen, the interrupt function is not processed. So why there is a break condition and the interrupt function is not running? I think the standard handle process is to reset the SCi in the interrupt function.

Best Regards,

Lee

Hello Lee,

Thats great, at least we now know it was caused by break condition.

Yes the best practice is too add the code in the receive interrupt handler (or function) as per UG recommendation, and thats where i put the code normally.

Thats odd if it doesn't work when you put the code in the receive interrupt function, do you have FIFO enabled? With FIFO enabled the effect of the interrupt flags to interrupt generation are slightly different (see SCI Reference Manual pg21). Break condition doesn't generate interrupt(RXINT) if you don't enable the RXERR interrupt (i.e. set the RXERRINTENA in SCICTL1 Register), so its possible there is a break but no interrupt being generated.

If you are using FIFO and enable the RXERR interrupt then you also have to handle other error (e.g. frame error, parity error, and overrun error) because RXERR interrupt will be generated for any of those errors not just for break condition. The easiest way to handle it is clear all error flag when any error happens, so instead of detecting BRKDT flag we detect RX ERROR flag and clear all error flag when this happens.

I would add this code on the SCI Initialization to enable RXERR interrupt

SciaRegs.SCICTL1.bit.RXERRINTENA = 1;  // Enable RXERR interrupt

And this in the receive interrupt function (same as previous code except we check for RXERROR here):

if (SciaRegs.SCIRXST.bit.RXERROR){
    SciaRegs.SCICTL1.bit.SWRESET = 0;  // Clear all error flag using SW RESET
    SciaRegs.SCICTL1.bit.SWRESET = 1;
    // You can add more code here for debugging/error reporting, e.g. count # of error
}
else
{
    // Put your normal receive interrupt function code here
}

Hope that helps.

Cheers,

Adi

Hello Adi,

Thank you for your advice, but I think I haven't enabled the FIFO.

So this is really strange to me. Maybe I have to check the SCI initialization carefully to see what reason causes the interrupt function not working.

Beast Regards,

Lee