You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by "linguini1 (via GitHub)" <gi...@apache.org> on 2025/02/12 22:37:28 UTC
[I] [BUG] Floating point issues on STM32H743 [nuttx]
linguini1 opened a new issue, #15826:
URL: https://github.com/apache/nuttx/issues/15826
### Description / Steps to reproduce the issue
I am encountering numerous strange issues on the STM32H743.
Floating point numbers seem to not work for the MS56xx driver, used on an MS5607.
```console
Mointor objects num:1
object_name:sensor_baro, object_instance:0
sensor_baro(now:18990000):timestamp:18990000,pressure:42948200.000000,temperature:21.870001
sensor_baro(now:19030000):timestamp:19030000,pressure:42948204.000000,temperature:21.809999
sensor_baro(now:19070000):timestamp:19070000,pressure:42948204.000000,temperature:21.760000
sensor_baro(now:19110000):timestamp:19110000,pressure:42948204.000000,temperature:21.760000
sensor_baro(now:19150000):timestamp:19150000,pressure:42948204.000000,temperature:21.760000
sensor_baro(now:19190000):timestamp:19190000,pressure:42948204.000000,temperature:21.879999
sensor_baro(now:19230000):timestamp:19230000,pressure:42948204.000000,temperature:21.700001
sensor_baro(now:19270000):timestamp:19270000,pressure:42948204.000000,temperature:21.750000
sensor_baro(now:19310000):timestamp:19310000,pressure:42948204.000000,temperature:21.700001
sensor_baro(now:19350000):timestamp:19350000,pressure:42948204.000000,temperature:21.809999
Object name:sensor_baro0, recieved:10
Total number of received Message:10/10
```
I am also seeing strange floating point numbers on the LIS2MDL driver and LSM6DSO32 driver. Additionally, when running `uorb_listener`, the kernel panics if I try to read from the LSM6DSO32. I had an earlier kernel panic with `ps` which I resolved by increasing stack sizes as recommended in this issue: https://github.com/apache/nuttx/issues/11463
I also cannot seem to get any information about the panic. I've enabled core dumps, scheduler and sensor error output, etc. without luck. If there are any suggestions on what I can enable or try to debug this and provide more information, please let me know. These drivers work without issue on RP2040 based boards, so I am not sure what could be the issue.
I have tried with the FPU enabled and disabled with the same results. I've increased every stack size option I could find to 4096 bytes without success.
This is the output seen before the kernel crashes:
```console
nsh> uorb_listener -n 10 sensor_accel0
Mointor objects num:1
object_name:sensor_accel, object_instance:0
lsm6dso32_activate: About to lock
lsm6dso32_activate: locked
lsm6dso32_activate: About to set odr
lsm6dso32_activate: odr set
lsm6dso32_activate: Waking up LSM6DSO32 polling thread
lsm6dso32_activate: LSM6DSO32 activated
Waited for 5 seconds withou
```
Then the output is cut off and the kernel panic status LED is activated. Some times the LED is held static, other times it blinks at 1Hz (for the same `uorb_listener` command).
### On which OS does this issue occur?
[OS: Linux]
### What is the version of your OS?
Arch Linux
### NuttX Version
master
### Issue Architecture
[Arch: arm]
### Issue Area
[Area: Drivers]
### Host information
_No response_
### Verification
- [x] I have verified before submitting the report.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "linguini1 (via GitHub)" <gi...@apache.org>.
linguini1 commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2660965140
> @linguini1 what about MS56XX stack size ? I don't see CONFIG_MS56XX_THREAD_STACKSIZE in your config, and the default 1024 may be not enough.
Sorry, I guess the config I posted didn't include this. I did try increasing it to 4096 without success. I'll try adding some more debug logs and look into adding breakpoints as well.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "linguini1 (via GitHub)" <gi...@apache.org>.
linguini1 commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2660231921
For whatever reason I cannot get the hard fault information to print over SYSLOG despite achieving a kernel crash (panic LED blinking). This is my latest configuration:
#
# This file is autogenerated: PLEASE DO NOT EDIT IT.
#
# You can use "make menuconfig" to make any modifications to the installed .config file.
# You can then do "make savedefconfig" to generate a new defconfig file that includes your
# modifications.
#
# CONFIG_MMCSD_HAVE_CARDDETECT is not set
# CONFIG_MMCSD_MMCSUPPORT is not set
# CONFIG_SPI_CALLBACK is not set
# CONFIG_STANDARD_SERIAL is not set
# CONFIG_STM32H7_DTCMEXCLUDE is not set
# CONFIG_STM32H7_USE_LEGACY_PINMAP is not set
CONFIG_ARCH="arm"
CONFIG_ARCH_BOARD_CUSTOM=y
CONFIG_ARCH_BOARD_CUSTOM_DIR="../josh-nx"
CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
CONFIG_ARCH_BOARD_CUSTOM_NAME="Josh"
CONFIG_ARCH_CHIP="stm32h7"
CONFIG_ARCH_CHIP_STM32H743VI=y
CONFIG_ARCH_CHIP_STM32H7=y
CONFIG_ARCH_CHIP_STM32H7_CORTEXM7=y
CONFIG_ARCH_INTERRUPTSTACK=2048
CONFIG_ARCH_STACKDUMP=y
CONFIG_ARMV7M_DCACHE=y
CONFIG_ARMV7M_DCACHE_WRITETHROUGH=y
CONFIG_ARMV7M_DTCM=y
CONFIG_ARMV7M_ICACHE=y
CONFIG_ARM_FPU_ABI_SOFT=y
CONFIG_BOARD_COREDUMP_SYSLOG=y
CONFIG_BOARD_CUSTOM_LEDS=y
CONFIG_BOARD_INITTHREAD_STACKSIZE=2048
CONFIG_BOARD_LATE_INITIALIZE=y
CONFIG_BOARD_LOOPSPERMSEC=43103
CONFIG_BUILTIN=y
CONFIG_COREDUMP=y
CONFIG_DEBUG_ASSERTIONS=y
CONFIG_DEBUG_ASSERTIONS_EXPRESSION=y
CONFIG_DEBUG_FEATURES=y
CONFIG_DEBUG_GPIO=y
CONFIG_DEBUG_GPIO_ERROR=y
CONFIG_DEBUG_GPIO_INFO=y
CONFIG_DEBUG_GPIO_WARN=y
CONFIG_DEBUG_HARDFAULT_ALERT=y
CONFIG_DEBUG_HARDFAULT_INFO=y
CONFIG_DEBUG_I2C=y
CONFIG_DEBUG_I2C_ERROR=y
CONFIG_DEBUG_MEMCARD=y
CONFIG_DEBUG_MEMCARD_ERROR=y
CONFIG_DEBUG_MEMCARD_WARN=y
CONFIG_DEBUG_SCHED=y
CONFIG_DEBUG_SCHED_ERROR=y
CONFIG_DEBUG_SCHED_WARN=y
CONFIG_DEBUG_SENSORS=y
CONFIG_DEBUG_SENSORS_ERROR=y
CONFIG_DEBUG_SENSORS_INFO=y
CONFIG_DEBUG_SENSORS_WARN=y
CONFIG_DEBUG_SPI=y
CONFIG_DEBUG_SPI_ERROR=y
CONFIG_DEBUG_SPI_WARN=y
CONFIG_DEBUG_SYMBOLS=y
CONFIG_DEBUG_UORB=y
CONFIG_DEFAULT_TASK_STACKSIZE=4096
CONFIG_EE24XX_FREQUENCY=400000
CONFIG_EEPROM=y
CONFIG_EXAMPLES_PWM=y
CONFIG_EXPERIMENTAL=y
CONFIG_FAT_LFN=y
CONFIG_FSUTILS_MKGPT=y
CONFIG_FS_FAT=y
CONFIG_FS_LITTLEFS=y
CONFIG_FS_LITTLEFS_BLOCK_SIZE_FACTOR=4
CONFIG_FS_PROCFS=y
CONFIG_FS_PROCFS_REGISTER=y
CONFIG_GPT_PARTITION=y
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y
CONFIG_I2CTOOL_MAXBUS=5
CONFIG_I2C_EE_24XX=y
CONFIG_INIT_ENTRYPOINT="nsh_main"
CONFIG_INTELHEX_BINARY=y
CONFIG_IRQ_WORK_STACKSIZE=2048
CONFIG_MMCSD=y
CONFIG_MMCSD_SDIO=y
CONFIG_NDEBUG=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_DISABLE_IFUPDOWN=y
CONFIG_NSH_FILEIOSIZE=512
CONFIG_NSH_READLINE=y
CONFIG_POSIX_SPAWN_DEFAULT_STACKSIZE=2048
CONFIG_PREALLOC_TIMERS=4
CONFIG_PTHREAD_STACK_DEFAULT=2048
CONFIG_PWM=y
CONFIG_RAM_SIZE=245760
CONFIG_RAM_START=0x20010000
CONFIG_RAW_BINARY=y
CONFIG_RR_INTERVAL=200
CONFIG_SCHED_HPWORK=y
CONFIG_SCHED_WAITPID=y
CONFIG_SENSORS=y
CONFIG_SENSORS_LSM6DSO32=y
CONFIG_SENSORS_LSM6DSO32_THREAD_STACKSIZE=4096
CONFIG_SENSORS_MS56XX=y
CONFIG_SPI=y
CONFIG_STACK_CANARIES=y
CONFIG_START_DAY=11
CONFIG_START_MONTH=5
CONFIG_START_YEAR=2024
CONFIG_STM32H7_I2C1=y
CONFIG_STM32H7_I2C2=y
CONFIG_STM32H7_I2C4=y
CONFIG_STM32H7_SDMMC1=y
CONFIG_STM32H7_TIM1=y
CONFIG_STM32H7_TIM1_CH3OUT=y
CONFIG_STM32H7_TIM1_CHANNEL=3
CONFIG_STM32H7_TIM1_PWM=y
CONFIG_STM32H7_USART1=y
CONFIG_SYSLOG_CHAR=y
CONFIG_SYSLOG_CHARDEV=y
CONFIG_SYSLOG_DEVPATH="/dev/ttyS0"
CONFIG_SYSTEM_COREDUMP=y
CONFIG_SYSTEM_I2CTOOL=y
CONFIG_SYSTEM_NSH=y
CONFIG_TASK_NAME_SIZE=20
CONFIG_UORB=y
CONFIG_UORB_ALERT=y
CONFIG_UORB_ERROR=y
CONFIG_UORB_INFO=y
CONFIG_UORB_LISTENER=y
CONFIG_UORB_STACKSIZE=2048
CONFIG_UORB_WARN=y
CONFIG_USART1_SERIAL_CONSOLE=y
CONFIG_USENSOR=y
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "raiden00pl (via GitHub)" <gi...@apache.org>.
raiden00pl commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2667950702
10000us is quite a huge delay, probably usleep is better here ? but remember than on the kernel side you should use `nxsig_usleep()`, not `usleep()`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "linguini1 (via GitHub)" <gi...@apache.org>.
linguini1 commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2660289675
> So, the crash is happening in the sensor kernel driver, right?
Yes. It appears I may have been able to resolve this issue by making the stack size even larger, 8192 bytes. However, all the floating point numbers are still incorrect.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "acassis (via GitHub)" <gi...@apache.org>.
acassis commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2656733150
@raiden00pl what do you think? Could it be caused by some missing config?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "raiden00pl (via GitHub)" <gi...@apache.org>.
raiden00pl commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2660777993
@linguini1 what about MS56XX stack size ? I don't see CONFIG_MS56XX_THREAD_STACKSIZE in your config, and the default 1024 may be not enough.
You could try to print RAW data and floats from sensor threads and verify if this is really problem with float point calculations or something else is broken. Or better, connect with a debugger and set a breakpoint in sensor threads to see what happens there.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "acassis (via GitHub)" <gi...@apache.org>.
acassis commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2660292518
@linguini1 that makes sense since our port to STM32H7 doesn't have LAZYFPU support, that reduces a lot the amount of saved FP registers
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "raiden00pl (via GitHub)" <gi...@apache.org>.
raiden00pl commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2667941284
@linguini1 you can use `apps/examples/calib_udelay` to calibrate `CONFIG_BOARD_LOOPSPERMSEC`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "linguini1 (via GitHub)" <gi...@apache.org>.
linguini1 commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2669894559
> 10000us is quite a huge delay, probably usleep is better here ? but remember than on the kernel side you should use `nxsig_usleep()`, not `usleep()`
I can open a PR to change this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "acassis (via GitHub)" <gi...@apache.org>.
acassis commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2660284802
So, the crash is happening in the sensor kernel driver, right?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "linguini1 (via GitHub)" <gi...@apache.org>.
linguini1 commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2656743834
This issue definitely needs more detail to be of use. Yesterday I read further about core dumps [here](https://nuttx.apache.org/docs/latest/guides/coredump.html), and it appears I should also enable `CORE_DUMP_SYSLOG`. I will do so and provide a core dump when I'm back in front of my board.
I also linked the config options being used in the PR, as well as our board support directory so there's more information.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "acassis (via GitHub)" <gi...@apache.org>.
acassis commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2660326378
The implementation is not so complex, because the hard work is done by the MCU itself. But it requires working with ARM assembly code to get it done
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "linguini1 (via GitHub)" <gi...@apache.org>.
linguini1 commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2666846725
> [@linguini1](https://github.com/linguini1) what about MS56XX stack size ? I don't see CONFIG_MS56XX_THREAD_STACKSIZE in your config, and the default 1024 may be not enough.
It appears after some debugging that the issue was that the MS56xx driver was not waiting long enough between measurement commands, so pressure was always being read at 0. I replaced the `up_udelay` calls with `usleep` calls and I'm now reading the correct pressure, 101.8kPa. I don't know if something is wrong with the `up_udelay` interface in my case and it is shorter than expected? Specifically this call: https://github.com/apache/nuttx/blob/c9a8f96aace9f63e21e7883c8774330adc4d99ff/drivers/sensors/ms56xx_uorb.c#L289
If I increase the sleep time by an order of magnitude the pressure reads correctly. Changing it to 11000us also doesn't seem to be enough, the pressure still reads as 0. I suppose this might because `CONFIG_LOOPS_PER_MILLISECOND` isn't calibrated for my board? Would it be different from other STM32H7 chips if the clock frequency is the same, 480MHz?
Is there a way provided by NuttX to calibrate loops per millisecond properly?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "acassis (via GitHub)" <gi...@apache.org>.
acassis closed issue #15826: [BUG] Floating point issues on STM32H743
URL: https://github.com/apache/nuttx/issues/15826
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "linguini1 (via GitHub)" <gi...@apache.org>.
linguini1 commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2660277192
With my own DEBUGASSERT I can get the kernel to panic and output the hard fault information, but hard faults caused by `uorb_listener` are not printing any information.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "linguini1 (via GitHub)" <gi...@apache.org>.
linguini1 commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2660309777
How difficult would it be to port LAZYFPU? I may look into that if it can help save us some space at a later date.
I believe the incorrect values are due to something external. These sensor drivers (MS56xx, LSM6DSO32, LIS2MDL) seem to work well on other MCUs. I will play with increasing stack sizes for their worker threads/HPWORK queue thread.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "linguini1 (via GitHub)" <gi...@apache.org>.
linguini1 commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2660299172
> [@linguini1](https://github.com/linguini1) that makes sense since our port to STM32H7 doesn't have LAZYFPU support, that reduces a lot the amount of saved FP registers
I see, so without LAZYFPU the floating point numbers take up more stack space due to saved registers? Any idea why the numbers themselves are incorrect?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [BUG] Floating point issues on STM32H743 [nuttx]
Posted by "acassis (via GitHub)" <gi...@apache.org>.
acassis commented on issue #15826:
URL: https://github.com/apache/nuttx/issues/15826#issuecomment-2660301527
Yes, without LAZYFPU support all registers are saved during the context switch. No idea why the values are incorrect. You can try to inspect the values to see where the conversion is messing with the values
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org