Using other FTM Channel and Hsync pin not working

[codelamana]

Hey, Im working with a T3.6 and currently try to get the hsync signal on pin 35 with FTM_CH3.

I changed the default values for hsync_ftm and hsync_ftm channel to (3,4) in uVGA.h and uploaded. Compiled flawlessly. But im not getting any signal on my screen. Works with (0,0) as default on pin 22 though. So basically not a problem with my screen and wiring. When using (3,4) im not getting a signal on 22 either, so the code probably doesnt reset the hsync values to default. Pin 35 is working properly as GPIO pin, tested that as well with a simple blink. Im using the Mandelbrot example as it is.

Any ideas? or am i overlooking something Thanks, Jakob

[FrankBoesing]

You change a program and ask why it doesn't work anymore.. right? You need to take a look at the Reference Manual for Teensy 3.6.

[codelamana]

I dont see the point, why changing the default values in uVGA.h : uVGA(int dma_number = 0, int sram_u_dma_number = 0, int sram_u_dma_fix_number = 0, int hsync_ftm_num = 3, int hsync_ftm_channel_num = 4, int x1_ftm_channel_num = 6,int vsync_pin = DEFAULT_VSYNC_PIN, int graphic_dma = DMA_NUM_CHANNELS - 1); should affect the working of the code. I didnt change the code otherwise. (3,4) for pin 35 is also listed as valid pair for the hsync pin in the documentation. So I would expect it to work just fine?

[qix67]

Hi,

can you try to replace your uVGA.cpp by the one attached to this post. uVGA.cpp.gz

If your combination of parameters is valid, on serial output, you should have

hsync_ftm: 3
hsync_ftm_channel: 4
x1_ftm_channel: 6

(3,4) for pin 35 is also listed as valid pair for the hsync pin in the documentation

This doesn't mean all combinations of parameters are valid. If uVGA detects a conflict between parameters, it silently replaces faulty parameters by valid ones. If you set hsync_ftm_channel_num to 5 (6), FTM will use channel 5 and 6 (6 & 6) which conflicts with x1_ftm_channel_num = 6.

However, a bug may exist.

I just re-read the function and I think line 227 (x1_ftm_channel = x1_ftm_channel_num ) should be removed as a duplicate of line 202. On a valid combination of parameters, there is no problem but if x1_ftm_channel is invalid, parameter fix is discarded by line 227.

[codelamana]

I tested it with your attached code. Gives me hsync_ftm = 0 but hsync_ftm_channel = 4. I added some more Serial prints at the points where the ftm channel possibly is set to 0. Turned out, FTM3_ADDR is set to NULL. Some further research lead me to the following forum post from pjrc and therfore to uVGA_FTM.h with the following from line 72:

#if 0
//defined(FTM3_SC)
#define FTM3_ADDR ((FTM_REGS_t*)(&FTM3_SC))
#else
#define FTM3_ADDR NULL
#endif`

I tried to compile with the first line as #if defined(FTM3_SC) but as the forum post suggested, that it isn't done with replacing the line, i get an error during compilation:

In file included from lib\uVGA-master\uVGA.h:30:0,
                 from lib\uVGA-master\uVGA.cpp:22:
lib\uVGA-master/uVGA_FTM.h:73:32: error: operator '*' has no right operand
 #define FTM3_ADDR ((FTM_REGS_t*)(&FTM3_SC))
                                ^
lib\uVGA-master\uVGA.cpp:322:5: note: in expansion of macro 'FTM3_ADDR'
 #if FTM3_ADDR == NULL

In the forum post someone found a solution but it's rather a dead end because nobody posted a solution. The thing i dont really get, is that addresses for ftm0-2 can be set without any issues, but there is a problem with ftm3.

[qix67]

#if 0
//defined(FTM3_SC)

was there due to an unknown problem.

FTM3_SC is defined in teensyduino's kinetis.h in the same way as FTM[012]_SC and I don't understand why it triggers a compilation error in uVGA_FTM.h.

After 2 years, I took a new look and modified 2 files. Can you try them and tell me if it works.

uVGA.cpp.gz uVGA_FTM.h.gz

I don"t understand why, on teensy 3.2, teensyduino declares FTM3_SC but not DMAMUX_SOURCE_FTM3_CH0. It is perhaps not possible on this µCPU.

If the new files work, I will push them on github.

[codelamana]

The new files work. I'm now getting the hsync signal straight on pin 35. Thank you!

[qix67]

Great.

I pushed the fix and now close this issue.