Major Bugs found in the sample code for SFO library and ePWM documents.

Bob,

The most accurate source for code examples is in the C/C++ Header Files and Peripheral examples packages (SPRC530 for 2833x/2823x devices) on the product folder websites. The user guide documentation is not always up-to-date, and can contain typos because it is documentation. All the example code offered in the example software packages has been tested without any problems. There are no bugs in the actual software. See comments below:

Addressing each of your items 1 by 1:

All of the items below are in the DSP2833x_EPwm_defines.h file in the /DSP2833x_common/include/ directory with the correct definitions (i.e. only one TZ_DISABLE (the top one), and the bottom TZ_DISABLE (under TZA and TZB bits is actually defined as TZ_NO_CHANGE). Likewise, in the software TZ_ENABLE and DISABLE are properly defined as 0 and 1 respectively.

// TZSEL (Trip-zone Select)
// = = = = = = = = = = = = = = = = = = = = = = = = = =
// CBCn and OSHTn bits
#define TZ_ENABLE 0x0
#define TZ_DISABLE 0x1
// TZCTL (Trip-zone Control)
// = = = = = = = = = = = = = = = = = = = = = = = = = =
// TZA and TZB bits
#define TZ_HIZ 0x0
#define TZ_FORCE_HI 0x1
#define TZ_FORCE_LO 0x2
#define TZ_DISABLE 0x3
// ETSEL (Event-trigger Select)

 There's 2 "TZ_DISABLE" defined!! Again, who is responsible for checking this stuff??

 Want more? In the same example code,

// CBCn and OSHTn bits
#define TZ_ENABLE 0x0
#define TZ_DISABLE 0x1

 Are reversed! Enable is "1".

-----------------

Finally, with regard to the SFO library, again, the examples are located in the header file and examples package (SPRS530 if you are using the 2833x/2823x devices - which you seem to be from your documentation references). See the hrpwm_sfo_v5 example.

With regard to the below, the first &EPwm1Regs is a dummy address, as mentioned in the documentation.

To access epwm channel 1 registers, you can use: *ePWM[1]. To access epwm channel 2 registers, you canuse: *ePWM[2], etc.  ePWM[0] is ignored.  The first &EPwm1Regs in the ePWM[0] location is a dummy placeholder - it can be 0, or any value. It is never used. This is not a bug. 

Again, PWM_CH is defined to be the actual number of PWM channels + 1 because there are entries for 0-(PWM_CH-1) in the *ePWM[] array.   Again, 0 is ignored. For instance if your device has 6 ePWM modules, you want to access ePWM's 1-6 using *ePWM[1] - *ePWM[6].  ePWM[0] is ignored. This array has 7 entries - hence defining PWM_CH as the actual # of PWM channels PLUS 1, so you can access the ePWM module you want with the array index instead of array index-1. It's a coding technique. You can also choose to use the header files themselves to access the ePWM regsiters using EPwm1Regs, EPwm2Regs, etc.  

volatile struct EPWM_REGS *ePWM[PWM_CH] which is where one of the problems is. The first element should be "0" not &EPwm1Regs, otherwise you will always need to enable one more PWM than what's actually used (in addition to setting PWM_CH to 1+ the number of channels used). This bug cost me about 1/2 a day's work in trying to figure out why my SFO code doesn't work.

---------

With regard to the below, this is a typo and the "While" should be "while". It is correct in the software example.

The other bug I found in this document is in the code shown for example 4.

for(i=1; i<PWM_CH; i++) //for channels 1-16
{
While (SFO_MepDis_V5(i) == 0); //Calls MepDis unitl MEP_ScaleFactor updated
}

 ----

Thank you for reporting the typos in the documentation. This will be corrected in the next documentation revision. Again, for the best source for tested code examples to use in development, please refer to the latest header files and peripheral examples software on the web.