Issues with the FTM GPT driver

[durga_choudhury]

MCU: S32K148

I need help with several issues with the FTP GPT driver that comes with RTD 3.0.0.

Issue 1: Upon enabling FTM 1 CH0 as a GPT interrupt source, the interrupt is not automatically enabled by the code generator. However, doing identical things in FTM0 CH0 does enable the interrupt. This is the case that is used in the example Ftm_Gpt_Example_s32K148. Manually adding the line 

#define FTM_1_CH_0_CH_1_ISR_USED

in Ftm_Gpt_Ip_Cfg_Defines.h in the generated/include/ directory does work.

Issue 2: I cannot find a way to configure the upper count limit (the value of the 'MOD' register for a FTM) in the driver. There is a function, but that is internal to the driver (declared static). In the earlier "Processor Expert' based code, both the initial and final values were configurable as shown in the screenshot below:

Issue 3: Using the RTD public API

Ftm_Gpt_Ip_StartTimer()

I can set the initial count (but not the final count, please see above). However, I see something strange with this API:

Using a start count of anything other than 0, it counts from the start count to 0xFFFF. If I connect a scope probe to a GPIO line that is driven by the ISR, I see a square wave with a frequency that varies smoothly and as expected with the start count. However, with a start count of 0, I get a frequency that suggests that it is counting up to ~1024. Is this expected? If so, where is it documented? I can send you code to reproduce this behavior, but this is just a slightly modified version of the Ftm_Gpt_Example_S32K148 code.

Issue 4: (This is not an FTM related question). The voltage swing I see from the GPIO line is 5V. I was expecting to see 3.3V. Which document has more information about the GPIO I/O voltage and current sourcing/sinking characteristics?

[Senlent]

Hi@durga_choudhury

1. I'll confirm with the internal design team whether your first question is a bug.

2 & 3. The RTD driver and the SDK driver are completely different.

RTD doesn't provide this feature. For RTD, you only need to consider the required timing duration, i.e., the input parameter of “Ftm_Gpt_Ip_StartTimer”.

Entering COUNTER_VALUE as 0 is invalid.

4. Check your Jumper settings. The S32K148EVB can select either 3.3V or 5V power supply.

[durga_choudhury]

Hi @Senlent 

Thank you for the update, but I have follow up questions:

1. On issue #1, please let me know what you find. Since the code is safety critical, we are not allowed to put in 'hacks' like the way I did for testing, but if you confirm this to be an issue with the current release of the RTD, I can leave this hack in if it is a known issue.

2. On issue #2 and #3, so what you are saying is that the FTM GPT will *always* count to 0xFFFF, there is no way to change the end count; you adjust the timer frequency by just adjusting the *start* count. Please confirm/deny my understanding.

3. A related question to the above is about the 'overflow-reload' ISR. Choosing the FTM1_Ovf_Reload_IRQn vector in the interrupt controller and the same function as the 'notification' does not cause the notification function to be called, but choosing the FTM1_Ch0_Ch1_IRQn vector *does* call the notification. Looking at the RTD code, I don't see any mechanism for invoking the 'Overflow-Reload' vectors, and yet that is what we used in the legacy 'Processor expert' based code that I am porting from. In fact, the PE based examples use the 'Overflow-Reload' ISR. How does one use the 'Overflow-Reload' ISR?

4. A start count value of 0 to Ftm_Gpt_Ip_StartTimer() is invalid, based on what you are saying. Why is that? So if I want to get the full count range of 0x0000 - 0xFFFF, (as opposed to 0x0001 - 0xFFFF) that is not possible?

[durga_choudhury · Accepted solution]

Hello @Senlent 

Thanks for the update. There are several different issues in this thread, so I am taking them up one at a time.

Issue 1:

If I understand your response, what you are saying is that:

(a) You have reported this issue to the tools development team.

(b) If I configure FTM0 *AND* FTM1 as GPT then the issue will not occur (i.e. ISR code will be generated for FTM1 as well). Unfortunately, the design I am creating is basically a port of an earlier working design that was coded in S32DS v2.2 and in there FTM0 is used for PWM and FTM1 as a GPT. As long as you are aware of the issue and I have a work around this is not a blocking issue for me. I look forward to a fix in a future tools release.

2. I still don't understand why the counter cannot begin from 0 to give it the full 16 bit resolution of 0x0000 - 0xFFFF. But that's not something that will hold me back; I have enough bits left to get the resolution I want; that's just a curiosity question.

3. So the 'overflow interrupt' is moved to a new module altogether (which I was not aware of and not including in my project). That is OK, because I have a workaround. However, what I will voice a concern about is making many APIs that were public in earlier release are private in the RTD. In your own screenshot, you show that Ftm_Ocu_Ip_SetTimerOverflowInterruptEn() as static. I can think of use cases where the application developer would need access to these calls. To give you a real example, the equivalent of

 Lptmr_Gpt_Ip_GetTimerEnableStatus(uint8 instance)

was a public API in the PE based SDK and our older application used it. In the RTD it is internal (i.e. static), making me reinvent the wheel in some cases. My suggestion would be to not take away functionality, but add to it.

Thanks again for all your support.

[Senlent]

Hi@durga_choudhury

SDK: A low-level, hardware‑oriented driver set that directly interfaces with the MCU and is mainly used for simpler, non‑AUTOSAR applications.

RTD: A unified, modern driver framework that integrates AUTOSAR and non‑AUTOSAR drivers, offering higher abstraction, safety compliance, and a standardized interface for S32K automotive platforms.

I simply reminded them not to use the same mindset as when using an SDK to use an RTD. These are completely different drivers. SDKs are more compatible with the underlying hardware, while RTDs abstract the hardware, and users only need to focus on the implementation of the functions.

[Senlent]

Hi@durga_choudhury

1.This is a bug in the SCT configuration tool. If you configure it this way, this problem won't occur. (We have already report it to the software team.)

2.Refer to "Ftm_Gpt_Ip_Init();"

3.Regarding "FTMx_Ovf_Reload_IRQn", the SC->TOIE is disabled by default.

4.The FTM period when using up counting is (MOD – CNTIN + 0x0001) × period of the
FTM counter clock.