Full width TIMER_CFG_PERIODIC used to toggle a CCP0 output pin

Hello Tony,

Can you please specify which ASSERT is it failing? I don;t thin a change in ASSERT for the function was made.

Regards
Amit

Hi Amit.

The 1st ASSERT in TimerConfigure() checks that the timer base address is valid and that of course passes. It's the 2nd one that fails:

ASSERT((ui32Config == TIMER_CFG_ONE_SHOT) ||
(ui32Config == TIMER_CFG_ONE_SHOT_UP) ||
(ui32Config == TIMER_CFG_PERIODIC) ||
(ui32Config == TIMER_CFG_PERIODIC_UP) ||
(ui32Config == TIMER_CFG_RTC) ||
((ui32Config & 0xff000000) == TIMER_CFG_SPLIT_PAIR));

ui32Config in my function call is TIMER_CFG_PERIODIC | TIMER_CFG_A_ACT_TOGGLE, so it fails all the equality tests. As I say this routine worked OK a couple of months ago (though on TIMER3 not TIMER5) and waggling the relevant CCP0 pin quite happily.

Hello Tony

I understand why the check is failing but the check has been the same on both TivaWare 2.1.0 and 2.1.1

Regards
Amit

I know. Bizarre.
Is there any sample code around for a full 32 bit periodic timer toggling a CCP pin?

Hello Tony,

Yes. There are examples for timer in 32 bit mode but without CCP toggle

D:\ti\TivaWare_C_Series-2.1.1.71\examples\boards\dk-tm4c123g\timers
D:\ti\TivaWare_C_Series-2.1.1.71\examples\boards\dk-tm4c129x\timers

Regards
Amit

Hi Amit.

I have checked through the example timer code under ti\TivaWare\... and confirmed there is no 32-bit periodic pin toggle example.

Given the presence of those ASSERTs at the top of the DRL TimerConfigure(), what is the correct combination of flags in the ui32Config parameter to configure TIMER5 as a 32-bit periodic timer toggling T5CCP0?

Regards,

Tony.

Incidentally - If I comment out the 'offending' ASSERTs from the driver library file timer.c, the timer works as expected and the T5CCP0 pin waggles away quite happily.

Hello Tony,

The ASSERT condition must have a mask before checking for the timer configuration and that is the issue on the API.

Regards
Amit

Hi Amit/Tony,

Pardon - might Amit further clarify, "must have a mask?"

Are you identifying the "lack" of such mask - in both past & present API versions?
Or - are you suggesting that such mask must be created & added?

I'm not bright enough to understand "why/how" poster's past code worked - while new version stumbles...

Hi guys.

I'm also not sure what Amit means by "must have a mask". The ASSERTs seem to preclude being able to OR on a mask and still pass the second ASSERT.

As for why it used to work, all I can think is that some months ago I encountered the same problem (I recall having trouble getting this CCP0 pulse train working), and I just commented out the ASSERTs then too. I'm guessing this change was lost when I upgraded the DRL to 2.1.1.71 a month or so ago. I've checked back in our subversion repository and my timer init function hasn't changed Also, I wasn't doing release builds so the ASSERTs would have been active.

Whatever - it works now with the DRL patch. But this does still leave the question of how you use the DRL API to enable a 32-bit couter with a CCP0 output.

Regards,
Tony

Hello Tony,

Do you mean with the current ASSERT statement in Debug Mode?

By mask I mean the following

ASSERT((ui32Config == TIMER_CFG_ONE_SHOT) ||
(ui32Config == TIMER_CFG_ONE_SHOT_UP) ||
(ui32Config == TIMER_CFG_PERIODIC) ||
(ui32Config == TIMER_CFG_PERIODIC_UP) ||
(ui32Config == TIMER_CFG_RTC) ||
((ui32Config & 0xff000000) == TIMER_CFG_SPLIT_PAIR));

should be

ASSERT(((ui32Config & 0x000000ff) == TIMER_CFG_ONE_SHOT) ||
((ui32Config & 0x000000ff) == TIMER_CFG_ONE_SHOT_UP) ||
((ui32Config & 0x000000ff) == TIMER_CFG_PERIODIC) ||
((ui32Config & 0x000000ff) == TIMER_CFG_PERIODIC_UP) ||
((ui32Config & 0xff000000) == TIMER_CFG_RTC) ||
((ui32Config & 0xff000000) == TIMER_CFG_SPLIT_PAIR));

Regards
Amit

HI Amit.

Yeah, that makes perfect sense.
I'll just leave the ASSERTs commented out as we're close to delivery on this project anyway.

Thanks for investigating,
Tony.

Tony,

That's great detail - much appreciated - thank you.

Your objective is not (that) uncommon - one wonders how this could have escaped note (and correction).    You've provided a great service - in that regard.

Our small firm employs ARM MCUs from multiple vendors - if we have the time we'll review (alien) devices - see how (or if) they handle this "wide" timer mechanism.

Hello cb1, Tony,

The existing SW tests do not cover every ASSERT statement and that is a correction needed on our side. May be with the next to the current TivaWare release we may be able to fix the issue.

Regards
Amit

Hi Amit,

Indeed these new "Amit generated" Asserts appear far more logical & effective.

We realize none of the failed Asserts were your doing.  

In medicine - a patient safeguard directs, "Surgeon, do no harm."   Perhaps better to have "NO" Assert - rather than  one which "destroys" functionality - as Tony's identified...