EVM430-FR6043: Avoid USS_initAlgorithms() delay in subsequent boots, cache configuration data in FRAM

Hi Philipp,

1. No idea what is saved in 0x1860. It could be a hidden register but I do not know what it is. 

2. Oh, yes. There is some change in the system RAM. I only focus on the RAM shared with LEA before. So, the init function do changes some parameters in RAM. 

3.  gUSSAlgObject starts from 0x21A0 to 0x22AC

gHilbertFilterConstant starts from 0x4F68 to 0x4F80

Best regards,

Cash Hao

Hi Cash Hao,

thanks for the inputs. I've now managed to get a working setup with this code:

/*
 * A replacement for USS_initAlgorithms() that only runs the
 * full initialization during the first boot and then caches
 * the results in FRAM for faster subsequent boots.
 *
 * NOTE: The internal workings of the USS library are not
 * really documented and it needed some reverse engineering
 * to get this to work:
 * 1. Take full memory dump before USS_initAlgorithms()
 * 2. Take full memory dump after USS_initAlgorithms()
 * 3. Find differing data
 * 4. Use linker map file to find out to which symbols the
 *    differences belong.
 * 5. Use `nm -S USS_SW_CCS_large_code_large_data.lib` to find
 *    the size of each of these symbols.
 * For this reason, the implementation is rather fragile and
 * may fail if USS parameters are changed, as these may cause
 * other symbols to become relevant.
 *
 * See also: 
 * https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1507600/evm430-fr6043-avoid-uss_initalgorithms-delay-in-subsequent-boots-cache-configuration-data-in-fram/
 */
extern void USS_lea_init(void);
extern void *gFilterConstant;
extern void *gHilbertFilterConstant;
extern void *gUSSAlgObject;
typedef struct uss_init_buffer_ {
    uint8_t gFilterConstant[0x28];
    uint8_t gHilbertFilterConstant[0x18];
    uint8_t gUSSAlgObject[0x116];
} uss_init_buffer_t;
#pragma PERSISTENT(persist_uss_init_buffer)
static uss_init_buffer_t persist_uss_init_buffer = {0};
static void uss_init_quick(void) {
    if (gUssSWConfig.validationKey != CONFIG_VALIDATION_KEY) {
        USS_initAlgorithms(&gUssSWConfig);
        /* Store initialized data to nonvolatile memory (FRAM). */
        memcpy(persist_uss_init_buffer.gFilterConstant, &gFilterConstant, sizeof(persist_uss_init_buffer.gFilterConstant));
        memcpy(persist_uss_init_buffer.gHilbertFilterConstant, &gHilbertFilterConstant, sizeof(persist_uss_init_buffer.gHilbertFilterConstant));
        memcpy(persist_uss_init_buffer.gUSSAlgObject, &gUSSAlgObject, sizeof(persist_uss_init_buffer.gUSSAlgObject));
        /* Take the shortcut on next boot. */
        gUssSWConfig.validationKey = CONFIG_VALIDATION_KEY;
    } else {
        USS_lea_init();
        /* Initialize LEA hardware, but otherwise just restore precalculated
         * data from nonvolatile memory. */
        memcpy(&gFilterConstant, persist_uss_init_buffer.gFilterConstant, sizeof(persist_uss_init_buffer.gFilterConstant));
        memcpy(&gHilbertFilterConstant, persist_uss_init_buffer.gHilbertFilterConstant, sizeof(persist_uss_init_buffer.gHilbertFilterConstant));
        memcpy(&gUSSAlgObject, persist_uss_init_buffer.gUSSAlgObject, sizeof(persist_uss_init_buffer.gUSSAlgObject));
    }
}

Unfortunately, I've only now figured out that I made a mistake during my initial profiling. USS_initAlgorithms() takes its time, but only a few 100us. The really substantial delay comes from USS_configureUltrasonicMeasurement() and more specifically, from the calculation of the transmit pulse patterns in commonConfigureMultiTone(). But at least "fixing" this is fairly easy: Since the results are stored in the persistent USS configuration data, it is enough to put an "if" around the slow code:

#if defined(__MSP430_HAS_SAPH_A__) && (USS_PULSE_MODE == USS_PULSE_MODE_MULTI_TONE)
USS_message_code commonConfigureMultiTone(USS_SW_Library_configuration *config)
{

    USS_Pulse_Multitone_Configuration* multConf;
    int32_t i,f1Freq,f2Freq,pulseCenterFreq, pulseBandwidth;
    uint32_t fSinInc, pPGFreq;
    _iq30 iq30Btemp;
    _iq23 iq23B;
    _iq18 iq18FIncrease;
    _iq12 iq12PulseDurFreq, iq12pPGCycles;
    _iq10 iq10FIncreased;
    uint16_t *pCurrArray;
    int16_t dmaCycles, xCycles,eCycles, stopAddr,pPGCycles;
    uint8_t ehperIndex, elperIndex, xhperIndex, xlperIndex,currentState;
    int8_t currentValue, previousValue;

    multConf =
            (USS_Pulse_Multitone_Configuration*) config->measurementConfig->pulseConfig->pToneConfig;

    /* The calculation of the pulse streams takes a considerable amount of
     * time (approx. 400ms), but the results are going into FRAM, and are
     * persistent anyway. So it is fine to just skip the calculation except for
     * the first boot after a firmware download. */
    if (config->validationKey != CONFIG_VALIDATION_KEY) {

        // Note: It is assumed that f1Freq<f2Freq
        f1Freq = (int32_t)config->measurementConfig->pulseConfig->F1Frequency;
        f2Freq = (int32_t)config->measurementConfig->pulseConfig->F2Frequency;

        // Calculate the excitation pulse bandwidth
        pulseBandwidth = (f2Freq -f1Freq);

        // ... more code ...
        
        }


        privatePadMultiToneConfig(config, multConf);
    }  // End of skipping for faster boots, the remaining code must stay.


 /*
  * Configure e-pulses and x-pulses RAM memory
  */

    eCycles = (multConf->numOfTrillcycles);
    xCycles = (multConf->numOfTrillcycles) -1;
    dmaCycles = eCycles + xCycles;
    stopAddr = (xCycles)*6+3;

    // ...

Now our sensors start providing data after about 30ms. Still not instant, but much more reasonable than half a second.

Thanks again!

Best regards and have a nice weekend,
Philipp