fanat thanks... This looks more and more like an issue with the 2.5.3 release... I've tried your code on two dev 100's w/ two 5234 modules w/o success. I can run other eTPU code like the PWM module on the target pins, but not the QOM module. Thanks again for your help. I have an open ticket w/ the support guys.
fanat9:
The NB folks indicate no changes to the eTPU code base between Rel_2.5.2 and 2.5.3. Wondering if you could send the .S19 file that worked on your setup? If it works for me, then I'll know it's not my hardware, and perhaps a rebuild of the system w/different etpu sets is warranted like yours that uses etpu_set1 rather than the default NNDK_set. I loaded the exact source code that you said worked and it failed on both a current system as well as an old 2.5.2 installation, albeit one that was no longer a vanilla configuration.
Thanks
fanat9: Thanks for the .s19. Your .S19 works on my board demonstrating that the hardware/scope setup is OK.
As a next step, I rebuilt your source on 2.5.3, using the unmodified C:\nburn\MOD5234\system\ETPU\ETPUinit.cpp. It did NOT work.
Next, I edited eTPUinit.cpp to incorporate the changes that you'd mentioned:
1) Comment out line 33: //#include <NNDK_etpu_set.h>
2) add line 34: #include <etpu_set1.h>
3) edit line 126 from "uint32_t etpu_a_tcr2_freq = 9216000;" to " uint32_t etpu_a_tcr2_freq = 921600;"
4) edit line 154 from "| FS_ETPU_TCR2_PRESCALER(1)" to "| FS_ETPU_TCR2_PRESCALER(10)"
5) Rebuild all.
WOW! The QOM module worked!! However the calls to the eTPU pins do not!
6) Edit the source of my program to remove the eTPUinit call that sets all the eTPU lines up as GPIO. Replace it with code that inits unused lines as GPIO, and QOM lines as QOM. IE don't init 2X, first to GPIO, then to QOM.
So... It looks like the NNDK_set may not support QOM. Still not sure why fanat9's build worked w/the call to eTPUinit, while mine required the alternate approach... Thanks to all for the considerable help!
As a final comment on the QOM, I once again edited C:\nburn\MOD5234\system\ETPU\ETPUinit.cpp so that the ONLY changes were:
//#include <NNDK_etpu_set.h>
#include <etpu_set1.h>
This works, although you must still take care not to init pins first as GPIO, then as QOM.
In other words the previously mentioned changes to the etpu_a_tcr2_freq, and to FS_ETPU_TCR2_PRESCALER(10) were not required to get the QOM to work and suggest an issue with the NNDK_set configuration.
TCR2 prescaler changes required for slow/long pulses of QOM or low frequency PWM. And in our test we use TCR1 anyway.
I'm wondering why you should exclude QOM pins from default initalization. We know there is no eTPU related changes between 2.5.2 and 2.5.3.
What other changes from vanilla nburn you have?
ADD:
How u rebuild nburn? Do u have DEFPLATFROM set to MOD5234?
set NBDIR=C:\Projects\Software\_nburn
path=C:/Windows/system32/;%NBDIR%/gcc-m68k/bin;%NBDIR%/pcbin;%NBDIR%/gcc-m68k/msys/1.0/bin
set NBROOT=%NBDIR%
set NBROOTMINGW=%NBDIR%
set DEFPLATFORM=MOD5234
cd %NBDIR%/MOD5234/system
%NBDIR%/gcc-m68k/bin/make clean
%NBDIR%/gcc-m68k/bin/make all
cd %NBROOT%/system
%NBDIR%/gcc-m68k/bin/make clean
%NBDIR%/gcc-m68k/bin/make all
Here's some explanation of why there may be difficulties reassigning a pin when it has been previously assigned as GPIO. The Freescale AN2857 QOM appnote states in section 2.1.6 "Changing Operation Modes: In order to change operation modes on the channel while it is still running, the channel must first be
disabled. This can be done using the fs_etpu_disable function, found in file etpu_utils.h."
Not sure why this is not always the case...maybe changing the state is only a problem if there is activity on a pin, eg it's producing a pulsetrain?