Programming F28335 - Instruction asm (" ESTOP0");

i had encountered the problem of an ESTOP0 statement followed by an infinite loop. but it was in the I2C code. the ESTOP0 does have an undesirable effect on the code execution. like , in the I2C example, the ESTOP0 statement was executed before the stop bit was sent, resulting in undesirable outptut. Maybe because of this statement  the complete I2C protocol was not being executed resulting in errors.

does your code have a Pass() function?

if you are using the example code then you may have a Pass() function to check the proper execution of code which may have a ESTOP0 statement.

instead of using an ESTOP0 condition use a flag to check the proper execution of the code.

where do you encounter this statement.?

Hi Pankaj,

Thanks for answering.

I found that statement many times in the examples given for this platform. Concretely you can find it in

\c28\DSP2833x\v120\DSP2833x_common\source\DSP2833x_DefaultIsr.c

on each interrupt function. They are there to check that wathever interrupt jumped to the appropiate function. In my case is to check that the initialization values of controller and etc are correct.

I do not use the Pass() function, in fact I don't know it. What is it for?

Thanks again,

Ricardo

Richardo,

the ESTOP 0 instruction works only if you have an emulator connected to the board. If not, it behaves like a NOP (spru430e). It means that this instruction won't help you in a final code version. So what's your idea to halt the chip with this ESTOP 0?

Next, the ESTOP 0 will just stop the core of the chip, all peripherals, including ePWMs,  keep their previous states. What happens on your ePWM pins depends on the time, when you execute the estop. If you have initialized the PWMs and they are already running when you reach the estop0 instruction, they might be halted at different levels. ..

Do you have different external loads at the PWM - lines? Could it be that for some lines the internal pullup is too big?

Hope this helps.

Regards

in the example codes you may find pass function which indicates that your code was successfully executed. in that functions you may encounter ESTOP0 statements.

to avoide ESTOP0 you may use a flag so that you may halt your code as and when required.

do a step debugging of your code.

you may find pass( ) function in some of the example codes. it is used to check that your code was executed successfully.

in such function you may encounter the ESTOP0 staement.

using the ESTOP0 conditon may result in undesirable output if not used properly. take the timing considerations into account. generate the stop conditon only when the code has been executed completly

Hi Frank,

The purpose of this line in the code is this: I am implementing a stepper motor driver, which controller parameters has to be adjusted during the initialization. In order to check that those parameters are correct, I use that instruction to halt the DSP and see the parameters values in the Watch window in CCS. It is situated at the end of the initialization, just before enabling interrupts.

It will be there only during the prototyping, for the final version for sure there will not be such instructions.

Since the initialization is lineal (no possibility of interrupts or bifurcations) and the PWM are configured as I said before stopping the DSP in this way, shouldn't be the PWM outputs in high state? (I not only do that of the pull-up, I also configure the ePWM module with initial values resulting in a steady high value). There is an inital measurement with the PWM before this, but it is a function that finish leaving the configuration as I say.

The load on each PWM output should be the same: a buffer.

About the emulator, I work (for the moment, because the parallel one is not yet working) with the USB emulator integrated in the ezdsp.

If STOP0 is not a good idea for this, which one could be? A breakpoint may work but I would like to have something fixed until the moment I decide that part of the code is working fine.

Thanks for your answer.

Ricardo.

Hi Pankaj,

Could you please tell me in which example is that function used? I didn't succeed finding it.

In any case, it does at the end a STOP0, doesn't it? Then I guess the effect should be the same but in spite of that I would like to check it.

Since the initialization is lineal, I think that timing shouldn't be a problem, but maybe I am wrong. Can the program execution reach the STOP0 and halt the dsp before the previous statements are applyed to the corresponding registers?

Thanks,

Ricardo

If the SOFT/FREE bits in the ePWM configuration are set to respond to the emulation stop, then it can effect the module.  For example if you do a software sync and immediately stop the load of TBCTR is likely to be skipped.

I suggest trying to set the SOFT/FREE bits of the ePWM to ignore the emulation stop (i.e. the ePWM will still run, even though the CPU is halted).   Another option is to add some NOP's before the breakpoint.

Regards

Lori

Ricardo,

Using real-time mode for the DSP can help considerably while debugging software.  (Debug -> Real-Time mode) This will enable the watch window and any graphs to continuously refresh (if in real-time mode right-click on a graph or watch window and click "Continuous Refresh") without the need to halt the DSP. It also allows you to edit variables while the software is running.

The steps to begin running should be:
1) Compile
2) Load Program
3) Debug->Reset CPU
4) Debug->Restart
5) Debug->Real-time mode
6) Debug->Run
7) Right click on any watch windows you would like to continuously refresh.

The steps to stop should be (assuming PWMs are set to run soft and free):
1) Put any power stages into a low power (safe) state. (ie torque = low, speed = low) via the watch window
2) Debug->Halt
3) Debug->Real-time Mode
4) Debug->Reset CPU

Hi all!

Lori, that is something good to know, but unfortunately is not useful for me, since when I halt the dsp I need the driver which I am implementing to go in a safe state (maybe I just shouldn't do such stops and expect the system to behave as I'd like).

Brett, I haven't use the real time for this yet, but are you sure that it doesn't perturb the dsp performance? because I am in the limit of computational power (running two 5th order FIR plus the two controller algorithms) and I remember that touching the watch window while the dsp is running had undesired effects.

Finally, after using the PWM to do a measurement in the motor, I not only set the PWM's configuration to make them go to high state, furthermore I force by software (which I wasn't doing before), and it seems to work fine for the moment.

What I don't understand is how any PWM could stay in low level when I set all the actions to make it go to high level and waiting at least one PWM cycle. I have a couple of #define for open all the mosfets, could you please tell me if it is a good way to do it? they are the following:

// 0% 0000 0000 1010 1010  (PWM output in high state)
#define open 0x00AA

#define openallA        EPwm1Regs.AQCTLA.all=open,    EPwm1Regs.AQCTLB.all=open,    EPwm2Regs.AQCTLA.all=open,        EPwm2Regs.AQCTLB.all=open

With this, when I put "openallA;" I expect all the PWM1 and PWM2 pins to go in a high state. But sometimes it didn't work completely fine if after that I halt the dsp (even waiting a full pwm cycle) so as I said I added the software forcing after "openallA", through AQSFRC.

Thanks for your answers!

Ricardo.