EVM430-FR6043: Ultrasonic sensing (USS) library: Interrupt during measurement causes sporadic resets

Philipp Burch

Part Number: EVM430-FR6043
Other Parts Discussed in Thread: MSP430FR6043,

Tool/software:

Hi all,

we're designing an OEM gas flow meter as replacement for a sensor based on hot wire measurement. Power consumption during measurement is not a primary concern, but the measurement rate should be as high as possible to reduce measurement dead time and allow for averaging to reduce standard deviation of measurement values.

Development is done using the EVM430-FR6043, containing the MSP430FR6043 with its integrated USS_A module. The application itself is simple: An I²C interface to start/stop measurement and read out measurement results and of course the two ultrasonic transducers for the actual flow measurement.

The firmware is roughly based on the example code, which performs measurements in a loop and output results using a UART. We've modified this to take measurements as fast as possible in the main while(1) loop (no timer anymore) and replaced the UART by an I²C interface. This all works, but now we're seeing random resets of the MCU when the measurement is running and values are read out using I²C at a high rate.

Observations:

Having the measurements running at full speed (~160Hz) without I²C communication does not cause the issue.
Having the measurements stopped while running I²C transactions at the maximum rate does not cause the issue either.
The "resets" only happen when measurements are taken AND I²C communication takes place.
The issue only shows up sporadically; with 160Hz measurements and 200Hz I²C transactions (100kHz bit clock), it usually happens a couple of times per minute.
Those crashes do not always cause a real PUC, sometimes the MCU appears to only go through parts of the initialization code.
The reset cause (SYSRSTIV) after such a restart is often 0x16 (watchdog timeout), but (for testing) I've put `WDTCTL=WDTPW|WDTHOLD` at the beginning of the loop body, so unless the USS code enables the WDT somewhere, it's certainly not in use.
It happens that after the MCU restarted and is at the beginning of main(), SYSRSTIV is 0x00.
Increasing the stack size from the default 512 bytes to 1k or even 2k doesn't help.
Having I²C interrupts disabled around the calls to USS_startLowPowerUltrasonicCapture() AND USS_runAlgorithms() seems to effectively avoid the issue, but heavily slows down I²C traffic, with clock stretching events lasting several milliseconds (the full duration of a measurement and calculations).
Disabling the interrupts only for one of the two calls doesn't help, the crashes can still be observed.
The I²C ISR doesn't directly access any USS data structures, only data that is defined and handled in main.c.
The I²C ISR mostly takes 5us to execute, but 50us occasionally, when it needs to prepare the data for emission.
The issue shows up even if all access to shared data is removed from the while loop, leaving there only the two USS function calls.

I'm quite out of ideas by now about what could cause those issues.

My question: Are there any constraints in regard to interrupts while USS functions are running? Like maximum execution times, certain modules or memory regions which may not be used, etc.?

Thanks and best regards,
Philipp

1 month ago

0 Philipp Burch 1 month ago

Prodigy 40 points

Problem solved. To achieve the shortest possible conversion time, I set the DCO to 24MHz, which supplies MCLK. And obviously I didn't carefully check the datasheet, because the FR6043 has a specified maximum MCLK frequency of 16MHz. That partially explains the weird behavior with no real pattern, although it's quite funny that the issue showed only when using the USS and I²C, but not when using only either one. Anyway, problem solved and lesson learned.

0 Philipp Burch 30 days ago in reply to Philipp Burch

Prodigy 40 points

There's a bit more to mention. I could have discovered this frequency problem much earlier, as I've actually once tested reducing the MCLK frequency and the crashes didn't go away. However, it now shows that I actually faced two bugs at the same time, with almost identical symptoms:

An excessive MCLK frequency leading to random MCU crashes as described above, and
having interrupts globally enabled when entering USS_startLowPowerUltrasonicCapture(), which would also lead to random crashes (or rather hangs) of the MCU if I²C interrupts are requested while the function runs.

So my fix was very simple in the end:

            /* Disable interrupts globally around capture function. This
             * seems to be required, as otherwise random crashes happen
             * when there is I2C traffic. Since the capture is mostly
             * about waiting in an LPM, interrupts are mostly enabled
             * anyway, so this is not too bad for latency.
             */
            __disable_interrupt();
            code = USS_startLowPowerUltrasonicCapture(&gUssSWConfig);
            __enable_interrupt();

I just checked the documentation again and found no hint about the requirement of having interrupts disabled upon enter. Given that some care has been taken in the library functions to disable and restore the interrupt flag where appropriate, I think this is rather a bug than an omission in the documentation, but unless it is fixed, I think that this requirement should be prominently noted in the library docs.

In fact, I just found a response of user "Cash Hao11" in another thread stating that "the interrupts does not impact the USS capture process.": https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1379232/msp430fr5043-water-demo-in-ccs-scale-factor-in-resultsfixpoints/5270922#5270922

Who knows, may I just had bad luck...

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

EVM430-FR6043: Ultrasonic sensing (USS) library: Interrupt during measurement causes sporadic resets