This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Not all Exosite IOT integer conversions to string values update properly when they are directed to the Print All tStat function.

Guru 56398 points

Have issue with certain integer values during conversion to a string randomly gain in value or refuse to follow the originating variable changes as the tStat is being printed. The local variable is reading the correct integer value but the value being sent into the Cloud is not the same and or intermittently follows the local variable suggesting the integer conversion function is breaking down.

This is isolated to integers of type short (s16) or (ucChar8) that go amuck during conversion possibly in ustrtoul().

When trying to add code to zero the two idle tStat values in UARTprintf() as to NULL the stuck integer tStat values, the pseudo tStat name value directly effects the value of the exported variable back into the sending variable data. That ain't supposed to happen in the real world.

The CCS compiler is linking s16 and uChar8  typedef stuct pseudo names data (bidirectional) to the original integer pointing to the local host exported variable name in (*.h). It is possible to zero the typedef struct by using it's pseudo name that is linked to the local variable being printed. That infers the typedef struct integer conversion routines may be causing the problem.

Other integer values such as  ul32 or ui32 do not have this problem as does s16 or ucChar8.

Pseudo named tStat:
tStat g_sMotorAmps =
	{"Motoramps", &g_sMotorCurrent, "motoramps", INT, WRITE_ONLY};

tStat g_sMotorStatus =
 {"Motorstatus", &g_ucMotorStatus, "motorstatus", INT, WRITE_ONLY};   

Do some INT conversions:

    else if((psStat->eValueType == INT) ||
            (psStat->eValueType == HEX))
    {
        StatIntVal(*psStat) = ustrtoul(pcInputValue, NULL, 0); //was 0 auto radix

    }

    else if((psStat->eValueType) == INT)
    {
        //
        // If this is an integer value, just print the value as text into the
        // destination string.
        //
        usprintf(pcValueString, "%i", StatIntVal(*psStat)); //was %d

       /* Zero the value of the previous usprintf integer passed to UARTprintf(). /*
        StatIntVal(*psStat) = 0x00000000; //6.13.2015
    }

Print the integer values that have been converted into strings:

    //
    // Loop over all statistics in the list.
    for(ui32Index = 0; psStats[ui32Index] != NULL; ui32Index++)
    {
    	//UARTprintf("\n");

        if(psStats[ui32Index]->pcName)
        {
            // For each statistic, print the name and current value to the UART.
            pcStatName = psStats[ui32Index]->pcName;
            StatPrintValue(psStats[ui32Index], pcStatValue);

            UARTprintf("> %25s= %4s\n", pcStatName, pcStatValue);

        }


 

  • Hello BP101

    Did you try changing ustrtoul to strtoul from C library? If the ustrtoul is printing the correct value, it must transmit as well the correct value.

    Regards
    Amit
  • Hi Amit,

     "If the ustrtoul is printing the correct value"

    The correct value only prints intermittently otherwise more often a very large number is being returned in the conversion. 

    Otherwise values of the pseudo (alias) name do not relate to the originating variables value in 8t-char or us-shorts being passed into the alias.

    BTW:

    All declared integer values only start at zero if the compiler optimization is set inter procedural level 3, speed 4 and or floating point is set relaxed.

  • Hello BP101,

    Is it because the size of the value is overflowing the s16 or uc8?

    Regards
    Amit
  • Hi Amit,

    That would  make it far to easy, wouldn't it (sarcasm). :(

    The same input value being displayed in real time (widget scope) never ever indicates a jump in the trace. The printed excessively high integer value remains stuck never returning to zero when the input value returns to zero.  Have to kick input several times by asserting several quick start/stop input values to get printed output value to sometimes return to zero. During kicks the widget trace reports for the same input integer value remain correctly in queue.

  • Don't know that (sarcasm) serves you best - not too many have risen to your aid.

    As far as, "too easy" - my sense was identical to Amit's...   The overflow he suggested - indeed could account for that which you report.    Frustration is understandable - unkindness to those assisting - perhaps not...

  • Conversion below fixes  the problem so indeed ustrtoul() has issues as stated with integer conversion.

    Hurried programmers not fully testing functions to work with all values simply assumed all if fine when in fact it is not.

    /* The IOT tStat value */
    g_ulMotorCurrent = (long)g_sMotorCurrent;

  • As we've discussed - when you attempt to stop (or greatly slow) your heavily loaded motor - does not the direction of current flow reverse?   (i.e. the motor becomes a generator)

    We note your earlier post employed a "signed" motor current - seemingly in accommodation of both positive & negative currents.

    Does your conversion really fix your issue?

  • This case the (s) infers integer value is short (uint16), changed lots of those during migration to Tivaware.

    Evident in the current formula conversion of all three low side phases read into one long variable [concatenated] then dumped into a short.
    None the less both integers are now working.

    Perhaps ustrtoul() and strtoul() requires some tweaking order to handle all lengths of variables and it may but fails to get the job done.
  • With my knowledge of your "super/exotic" BLDC motor - and what it is driving - I'd expect a, "Brake" or sudden slow down (deliberate or otherwise) to yield high reverse currents - which may quickly raise your Motor Bus Voltage - exceeding safe/rated levels.

    You may consider techniques to sense that V_Bus rise - and "clamp/limit it' - as/when required - to prevent serious component damage...
  • All very good advice yet LP at this time ADC channels are open inputs simulating analog rising steps driven by residual AXi input gate E charging (Csh), (Rsw) internal resistor and capacitor. Must point out none of that added motor discussion has to do with a software integer bug being found. There are plenty of those bugs in the undiscovered country as they say.

    Some math and support documents explain the ADC input behavior is right on queue. And to all that reassuring ADC actually works quite well indeed.

    AXi:  E=1/(Rsw * Csh) in this case AXi=1/2piRC, time constant RC for derived frequency indicative of the SSIO converted analog voltage step.

    Great TI read how ADC convert analog to digital, interface techniques.

    TI precision ADC seminar.pdf