TMS320F28335: Problem with the GPIO output

I will loop in the expert on this device.

Nima

Hello,

I see the code that's tested, but I have a few questions. When it says "50ns delay between two GPIO", is this measuring time between the rise of both GPIO, or how long it takes for the GPIO to rise? If it's the former, this could be because of a number of reasons, the most significant being where the code is compiled. If the code is running on FLASH, there is at least 5 wait states per cycle, which can lag the time between instructions. If the code is running on RAM, you can show the disassembly to maybe help clarify what's happening on the CPU level.

The code with the while loop will inherently be longer because of the way the code is run, where the pipeline needs to be flushed if the conditional is not met, etc. This is C code, and inherently will not be as optimized as assembly. Please let me know if you discover what the timing of 50 ns and 150 ns refers to.

Omer

Hi Omer,

Please see the response from our customer:

It refers to the measuring time between the rise of both GPIO, which could be found in the attachment. In addition, I can briefly describe my demands for DSP, that I need to control PWM according to two input pulses shown in the attachments. Therefore, I am very cared about the delay for GPIO input captures and output generations. It seems that there are delay problems for both GPIO input and output. I know the interruption ways to detect GPIO and generate PWM will be more time-consuming. If possible, is there any best solution to realize the fast GPIO detection and generation?

Regards,
Carlo

Hi Omer, 

Thanks a lot! I have checked the code and GPIO again according to your advice. There are several further questions:

ePWM:

1. Although ePWM is the best way to control PWM which I have also used normally, it can't deal with the practical situation I encounter now, where the PWMH and PWML period are both determined by the input pulse, shown in the previous figure. So do you think ePWM has such kind of capability to generate PWM only based on input trigger signal?  

Code time:

2.1 The maximum rise/fall time 8ns has no effect on the 50ns delay, because the time I measured is based on the start point where the GPIO begins to rise or fall, shown in the previous figure;

2.2 I have checked the disassembly, the code 'GpioDataRegs.GPACLEAR.bit.GPIO5 = 1' takes 4 system clocks measured by CCS, which includes two pieces of assembly code. Therefore, it seems to take 4*6.3ns.

2.3 I am confused about 'If the code is running on FLASH, there is at least 5 wait states per cycle', so do you mean there are 5 more system clock to be consumed for every piece of assembly code? If so, that will be very wired.

Hello Wang Lei,

1. I can loop in an ePWM expert to better answer this question.

2.1 I'm not sure what I'm communicating is clear, so I've inserted a diagram below that shows what I mean. The rise/fall time is supposed to be a maximum of approximately 8 ns according to the F2833x datasheet (see the section and page number listed, also depicted below). If this is what you're doing, please show me the oscilloscope image where this transition is taking 50 ns. It says nothing about the time T in the diagram, as this depends on how/where the code is compiled (the toggling time listed below is the time to toggle a single GPIO, not turning one high and another low).

2.2 The line 'GpioDataRegs.GPACLEAR.bit.GPIO5' is the most optimized instruction for clearing a GPIO bit, as you've seen, but this still requires more than 1 cycle because of the instruction set.

2.3 Yes, running code on FLASH is inherently slower. Looking at the datasheet for the device, this is what I found (see table 7-4 in section 7.9.7.5 of the datasheet, on page 95); at a frequency of 150 MHz for the system clock, there are 5 page/random wait-states.

Let me know if there are further question about this, and I will make sure to loop in the ePWM expert to help answer your first question.

Best regards,

Omer Amir

Hi Wang Lei,

Wang Lei said:

1. Although ePWM is the best way to control PWM which I have also used normally, it can't deal with the practical situation I encounter now, where the PWMH and PWML period are both determined by the input pulse, shown in the previous figure. So do you think ePWM has such kind of capability to generate PWM only based on input trigger signal?  

Unfortunately, there is no inherent way to change the output of the PWM based on an input pulse. You would need to implement a work-around to change the PWM output based on the pulses themselves. Another option for this is implementing external interrupts for these GPIOs and then within the ISRs do an action qualifier continuous software force  or trip zone software force to alter the PWM output. 

Best Regards,

Marlyn

Thanks for your verifications. As I expected before, there is no such function for the embedded ePWM. As for the way of interrupts, it will lead to an apparent delay for the PWM triggered by input pulses.

Best Regards,

Lei

1. Thanks for your passional manner, patient answer.

2. I have reclarified that below:

3. Yes. The maneuver of GPIO registers seems to be slower than that of other registers. 

4. I think the wait-states are not followed by every instruction, otherwise the DSP running on Flash will be very slow. In general, is the code running on Flash slower than that on ROM, am I correct? 

Thanks a lot. After a discussion with you, it seems that I have to use FPGA or CPLD. I really appreciate your help, you can close the case now.