Compiler/TM4C1230H6PM: TM4C1230 Delay function SysCtlDelay() Problem

user1909792

Part Number: TM4C1230H6PM

Tool/software: TI C/C++ Compiler

I use delay function SysCtlDelay() to delay millisecond, the function is implemented as follows:

void SleepMillisecond(u16 u16milisecond)
{
    SysCtlDelay(SysCtlClockGet() / 3000 * u16milisecond);//1ms
}

void
SysCtlDelay(uint32_t ui32Count)
{
    __asm("    subs    r0, #1\n"
                "    bne.n   SysCtlDelay\n"
                "    bx      lr");
}

Under normal circumstances, It's work fine. But when I change some Precompiled Macro (define by myself), This function will output double delay time. I'm so sure that Precompiled Macro do not affect this code.

I use oscilloscope to check Clock is OK. I also check anothter function execution time, however Precompiled Macro is change, execution time is same, except function SysCtlDelay().

I step into this function to debug disassembly, the executed number of assembly instructions in both cases are the same. So I really don't understand why it has different result with same code and same clock?

Compiler Environment: IAR Embedded Workbench 7.0

over 6 years ago

0 Ralph Jacobi over 6 years ago

TI__Guru*** 133705 points

Hello,

I think I am missing a key piece of information here to understand what is going on.

You have posted the driverlib code, but you also mention when you change the precompiled macro by defining it yourself. Can you post what you changed, how you defined it, and explain what file(s) the change applies to?

Also on a related note, what benefit are you trying to get from re-defining the macro? I am not clear why you would even need to do this, can you explain the problem you are seeking to solve by re-defining the macro?

0 user1909792 over 6 years ago in reply to Ralph Jacobi

Prodigy 130 points

I probably made wrong expression in my question, it should be compiler switch instead of precompiled marco which is the tag to distinguish the store version and product version.

As showed in following picture, the delay function has right result when I enable STORE_VERSION && disable PRODUCT_VERSION, however

the delay function has wrong result when I disable STORE_VERSION && enable PRODUCT_VERSION.

Here is how I use compiler switch in project:

#ifdef PRODUCT_VERSION
    /* code */
#endif

#ifdef STORE_VERSION
    /* code */
#endif

PRODUCT_VERSION and STORE_VERSION exist in following file, however the delay function has wrong result(

the time doubled) when it is invoked in Iot_Sound.c and Iot_Sleep.c,

So in my opinion compiler switch would not affect the result of delay function.

0 user1909792 over 6 years ago in reply to Ralph Jacobi

Prodigy 130 points

I changed SysCtlDelay() to ROM_SysCtlDelay() , this issue is solved. But I really really do not know why?!!!

0 cb1_mobile over 6 years ago

Guru 117855 points

To begin - it is believed that you are (really) pressing against the bounds of, 'Vendor MCU Support.' (your highly unusual use circumstance - has 'over-challenged you' - thus perhaps 'unfair' to burden the vendor - as well...)

Your code: 'SysCtlDelay(SysCtlClockGet() / 3000 * u16milisecond); //1ms'

especially the part, 'SysCtlClockGet()' invites 'vulnerability' - does it not? (hard coding your value - rather than employing the (far more) cumbersome 'SysCtlClockGet()' - proves to your advantage - does it not?)

It is expected - due to the "integral multiple' of the duration of 'SysCtlDelay()' - that your 'failing (doubling) mode' has someway/somehow - enabled such (possible) 'double calling' of 'SysCtlDelay().' Would it not prove useful for you to call 'SysCtlDelay()' ... 'back to back' - noting then - if such 'doubling of function duration' - persists? If that 2nd call - harvests 'normal' duration - then it is assured that your 'failing mode' has 'predisposed' SysCtlDelay() to its 'doubling fate.'

As a sailor - we're taught to seek, 'Any port in a storm.' It is (almost) guaranteed that your use of 'one of the many, MCU Timers' (instead) - would, 'Avoid this issue - completely!'

0 Ralph Jacobi over 6 years ago in reply to user1909792

TI__Guru*** 133705 points

Hello,

Unfortunately I am leaning towards agreeing with cb1 in that this seems difficult for me to explain or comment with the information provided.

Are you saying that the code of

void SleepMillisecond(u16 u16milisecond)
{
    SysCtlDelay(SysCtlClockGet() / 3000 * u16milisecond);//1ms
}

Gives different results based on using either PRODUCT_VERSION or STORE_VERSION?

Have you checked the result of SysCtlClockGet for both cases?

If using the ROM_ command works, another thing you may need to look at is optimization and other compiler settings. Unfortunately with IAR, I am not knowledgeable about any possible 'gotchas' regarding such settings.

0 cb1_mobile over 6 years ago in reply to Ralph Jacobi

Guru 117855 points

Mr Jacobi, (i.e. Ralph)

Utter Blasphemy - 'gotchas' - induced under a longer existing - far more deployed - REAL (ALL ARM MCUS Invited) PRO IDE! HIGHLY UNLIKELY - and far more evident w/in those 'lesser versions' - claiming low price (free) as their (sole) 'raison d'etre.'

And causing GREAT Pain & Suffering - when client users GROW - and wish to evaluate ANY 'Leapfrogging ARM MCU!' (there are multiple - BTW...)

Middle of the night - last night - I devised a method to 'tease out' this poster's issue:

Systematically Remove - ONE at a TIME - each of the functions w/in his 'failing" CASE. It is expected that few (mainly just one) function will 'Cause Poster's Issue!' Armed w/that clearly 'KISS Based' finding - such HIGH FOCUS - best ENABLES SUCCESSFUL TROUBLESHOOTING! (Never achieved via the 'grand mess' - of 'ALL at ONCE!"

Arm-based microcontrollers

Arm-based microcontrollers forum

Compiler/TM4C1230H6PM: TM4C1230 Delay function SysCtlDelay() Problem