physical-computation / warp-firmware Goto Github PK

Cleanup of warnings in build.

HDC1000 temperature & humidity readings show 0x00 or --- in hex mode.
Firmware version:
parent e1b54ce commit 42d8caf

Cleanup use of tagString in boot.c

Describe the bug
From experience I expect to see more variation in the output of these sensors.

To reproduce
Take a look at any file in: https://github.com/physical-computation/Warp-data-stream/tree/master/data

Expected behavior
Some random oscillation of values around some non-zero value.

Clean up abuse of return types in RV8803C7.c

1. Remove any changes to SSSupply in the 'z' case statement.
2. Use 'a' command and datasheets to get a list of which sensors work at which voltages.
3. Use the list to adapt the 'z' command to only read from the sensors that work at a given supply voltage.
   Phillip could you advise a neat way to do this ? My current idea is to have a if statement for each supply voltage and use that to only print headers for + request data from sensors that operate at the current voltage. Does this sound like a good approach ?

Cleanup for FRDM build variant. More cleanup will arrive via #53.

Current driver for device IS25xP is not very useful. It would be helpful to expand on this implementation and provide some helper functions for reading from and writing to the flash device.

The datasheets for Warp are currently in Warp-hardware.

j command reading the BMX055 only produces valid values the first time around. The second time I try to run it I get dashes instead of the numbers that I expect. Resetting the Warp board resolves the issue but only for one round of samples.

This should not be the case and needs to be investigated

An issue for the creation of a branch of the private Warp-firmware repo.

Inside the sensor device drivers, menuI2cPullupValue variable has non-matching type declarations in different functions.

Example from devMMA8451Q.c :

WarpStatus
configureSensorMMA8451Q(uint8_t payloadF_SETUP, uint8_t payloadCTRL_REG1, uint8_t menuI2cPullupValue)

and

WarpStatus
writeSensorRegisterMMA8451Q(uint8_t deviceRegister, uint8_t payload, uint16_t menuI2cPullupValue)

Describe the bug
We currently only read 2 hex bytes from register 0x06 on the CSS811 and print them with the z command.
The datasheet suggests that there are four bytes (two for vref anf two for a negative temperature coefficient sensor) to be read and all of them are needed to calculate the temperature see page 20: https://cdn.sparkfun.com/assets/learn_tutorials/1/4/3/CCS811_Datasheet-DS000459.pdf

To reproduce
See only two hex bytes printed in: https://github.com/physical-computation/Warp-data-stream/tree/master/data

Expected behavior
All four bytes should be printed to allow temperature calculation

For example, the values we use for setting the ctrl_meas register for the BME680

For example, the literal constant 0b00000001 in

should be named constants (e.g., kWarpDevBME680HumidityOversampling1x or something better, to be defined in the corresponding driver header file).

printSensorDataXXX should by default print a special "erasure" character/token if read fails to enable easy processing of the resulting CSV in the z command result. One option would be to add a verbose mode as argument, and to trigger the non-verbose mode from the z menu.

Print error for first data set when running JLinkRTTLogger. Measurement number anomaly and possible shift of sensor readings in fields.
Firmware version:
parent e1b54ce commit 42d8caf

Initialize the kWarpPinKL03_VDD_ADC, write routines to read the VDD and temperature.

Build fail from commit/bbadcf9db2dc6d462d6076fa8db33e47a89b6b92
Undefined reference to devMAX11300 (line 2077) of warp-kl03-ksdk1.1-boot.c.obj

Describe the bug
Sensor output values from the "z" command are wrong.
Some sensors always output 0. For example the HDC1000 sensor always outputs 0x00 in registers 0x00 and 0x01. Same output when looking specifically at that sensor using the "j" command.

To reproduce

1. Run ./build.sh in build/ksdk1.1/
2. Then run JLinkExe -device MKL03Z32XXX4 -if SWD -speed 100000 -CommanderScript and JLinkRTTClient
3. Running the following set of commands to dump all sensor values
   b 0300
   r
   g 3000
   n
   z

Expected behavior
I got the following output
BME680 Calibration Data: 0x40, 0xFB, 0x66, 0x03, 0xFF, 0x95, 0x8C, 0x59, 0xD7, 0x58, 0xFF, 0x90, 0x1E, 0x81, 0xFF, 0x22, 0x1E, 0x00, 0x00, 0x48, 0xF9, 0x60, 0xF4, 0x1E, 0x01, 0x3F, 0x94, 0x2E, 0x00, 0x2D, 0x14, 0x78, 0x9C, 0x53, 0x65, 0xF4, 0xDD, 0xE0, 0x12, 0x23, 0x00

Measurement number, RTC->TSR, RTC->TPR, AMG8834 0, AMG8834 1, AMG8834 2, AMG8834 3, AMG8834 4, AMG8834 5, AMG8834 6, AMG8834 7, AMG8834 8, AMG8834 9, AMG8834 10, AMG8834 11, AMG8834 12, AMG8834 13, AMG8834 14, AMG8834 15, AMG8834 16, AMG8834 17, AMG8834 18, AMG8834 19, AMG8834 20, AMG8834 21, AMG8834 22, AMG8834 23, AMG8834 24, AMG8834 25, AMG8834 26, AMG8834 27, AMG8834 28, AMG8834 29, AMG8834 30, AMG8834 31, AMG8834 32, AMG8834 33, AMG8834 34, AMG8834 35, AMG8834 36, AMG8834 37, AMG8834 38, AMG8834 39, AMG8834 40, AMG8834 41, AMG8834 42, AMG8834 43, AMG8834 44, AMG8834 45, AMG8834 46, AMG8834 47, AMG8834 48, AMG8834 49, AMG8834 50, AMG8834 51, AMG8834 52, AMG8834 53, AMG8834 54, AMG8834 55, AMG8834 56, AMG8834 57, AMG8834 58, AMG8834 59, AMG8834 60, AMG8834 61, AMG8834 62, AMG8834 63, AMG8834 Temp, MMA8451 x, MMA8451 y, MMA8451 z, MAG3110 x, MAG3110 y, MAG3110 z, MAG3110 Temp, L3GD20H x, L3GD20H y, L3GD20H z, L3GD20H Temp, BME680 Press, BME680 Temp, BME680 Hum, BMX055acc x, BMX055acc y, BMX055acc z, BMX055acc Temp, BMX055mag x, BMX055mag y, BMX055mag z, BMX055mag RHALL, BMX055gyro x, BMX055gyro y, BMX055gyro z, CCS811 ECO2, CCS811 TVOC, CCS811 RAW ADC value, HDC1000 Temp, HDC1000 Hum, RTC->TSR, RTC->TPR, # Config Errors

0, 1451692821, 20372, 0, 9, 10, 14, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 8, 0, 0, 0, 0, 0, 9, 8, 0, 0, 8, 0, 0, 0, 0, 0, 4, 0, 12, 12, 12, 13, 12, 12, 12, 10, 13, 14, 13, 14, 14, 14, 14, 13, 14, 9, 14, 9, 16, 10, 16, 7, -510, 0, 0, 2, 1, 2, 0, -508, 8, 132, 694, -3938, -2083, 1879, 1737, 12, -91, -444, -137, 7, 524288, 524288, 32768, -91, 174, 995, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 43, -40, ----, 1451692821, 21505, 6
1, 1451692821, 24753, 0, 12, 8, 6, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 8, 0, 0, 0, 0, 0, 9, 8, 0, 0, 8, 0, 0, 0, 0, 0, 4, 0, 12, 12, 12, 13, 12, 12, 12, 10, 13, 14, 13, 14, 14, 14, 14, 13, 14, 9, 14, 9, 16, 10, 16, 7, -510, 0, 0, 2, 1, 2, 0, -508, 8, 162, 664, -3966, -2081, 1876, 1740, 12, -64, -375, -147, 7, 359136, 496256, 18242, -84, 167, 1001, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 92, ----, 0, 1451692821, 25883, 6
2, 1451692821, 29134, 0, 13, 12, 2, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 8, 0, 0, 0, 0, 0, 9, 10, 0, 0, 10, 0, 0, 0, 0, 0, 4, 0, 10, 10, 11, 11, 11, 11, 10, 8, 11, 11, 11, 11, 12, 11, 12, 10, 10, 7, 11, 8, 12, 8, 11, 5, 5, 8, 8, 8, 8, 9, 7, 5, 8, 132, 688, -3930, -2082, 1874, 1751, 12, -52, -349, -146, 7, 359136, 496288, 18232, -70, 177, 997, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 92, -40, ----, 1451692821, 30267, 6

The sensor readings seems to be wrong and to be disagreeing with one another.
And I always see 4/6 Config Errors. Is this expected?

Screenshots and hardware pictures


I am using the latest version of the firmware

Host OS (please complete the following information):

• OS: Ubuntu 18.04.3
• Browser: Chrome
• Version (e.g., 22).
• J-Link Commander V6.56a

You local changes (please complete the following information):

• Output of git diff.
  diff --git a/tools/scripts/jlink.commands b/tools/scripts/jlink.commands
  index e0d59ab..d449d69 100644
  --- a/tools/scripts/jlink.commands
  +++ b/tools/scripts/jlink.commands
  @@ -1,5 +1,5 @@
  exec EnableRemarks
  unlock kinetis
  -loadfile /build/ksdk1.1/work/demos/Warp/armgcc/Warp/release/Warp.srec
  +loadfile /home/vimuth/projects/warp/Warp-firmware/build/ksdk1.1/work/demos/Warp/armgcc/Warp/release/Warp.srec
  r
  go
  \ No newline at end of file

• Output of git remote -v.
  origin [email protected]:physical-computation/Warp-firmware.git (fetch)
  origin [email protected]:physical-computation/Warp-firmware.git (push)

Additional context
I have set the switches for "Power from USB and Sensors Enabled" as in - https://github.com/physical-computation/Warp-hardware/tree/master/revB
all switches in S3 is set to off

Describe the bug
Variables for I2C pull up resistance appear in various places with different type and semantics.

Variable menuI2cPullupValue in main functions is uint16_t and intended to be the I2C resistance value in Ohms.

Variable pullupValue in configureI2Cpins function is uint8_t and corresponds to the tap positions of the ISL23425 DCPs.

Required changes

1. There are currently two ISL23425 DCPs which are configured with the same tap position value using configureI2Cpins function. We should modify the function to be able to take two values.
2. A similar approach for menuI2cPullupValue, since there are two DCPs.
3. We should add a function to map the menuI2cPullupValue Ohms value to ISL23425 DCP tap position.

Minimal build for Glaux revA hardware. Samples the BME680 every minute with sleep in between. All other sensors disabled.

Investigate low-power pin states.

When printing out sensor output values, it should look like 12345678@14bits to indicate how many effective bits there are for the output.

Currently, the i2c address for AMG8834 is set as 0x3A. The sensor talks with an address of 0x68.

When attempting to compile Warp on my Ubuntu 18.10 virtual machine I get the print out found in compile.txt.

The output from running gcc -v can be found in gcc.txt.

compile.txt
gcc.txt

Measurement number starts higher than 0 (e.g. >800).

Describe the bug
The switch statement of the Warp menu is missing the break command at the end of the case block for cases R, F, and P. This results in the execution of code in cases below the active one in a waterfall manner.

To reproduce
Steps to reproduce the behavior:

1. Start firmware
2. Press "R" at Warp menu.

Expected behavior
The firmware should not execute code outside the selected case.

Host OS (please complete the following information):

• OS: Linux 5.15.6-arch2-1 x86_64 GNU/Linux

To integrate the MLX thermal camera firmware to Warp, first, data from AMG8833 needs to be collected properly.

Read through data sheets and determine how to interpret the hex values from each sensor to preserve sign and produce c code that maps the raw hex value to an unsigned integer from 0 to 2^n. For example for at +- 2g value of 16 bits -2g should be mapped to 0 and 2g should be mapped to 65536. this would lead to 0 g being mapped to 65536/2

KL05 Support.

Currently, the sensor output is read in one-register-after-another fashion, in order to speed up, use the burst mode (auto-increment register pointer) instead. This applies to other sensors capable of providing burst-read mode as well.

Column headings in output of z menu should have units of measure.

Implements changes to the pin assignment needed for Revision B hardware.

Describe the bug
When editing config.h such that
#define WARP_BUILD_ENABLE_DEVBMX055 1
or
#define WARP_BUILD_ENABLE_DEVHDC1000 1

you get compiler errors that state that you are trying to call a function that takes two arguments with three arguments.
To reproduce
set #define WARP_BUILD_ENABLE_DEVBMX055 1
or
#define WARP_BUILD_ENABLE_DEVHDC1000 1
and then compile with make warp

Expected behavior
Compiler errors complaining about calling a function with more arguments than it is defined to have.

Currently, MMA8451Q will be masked out if WARP_BUILD_ENABLE_DEVADXL362 is not defined, it should instead be WARP_BUILD_ENABLE_DEVMMA8451Q

This doesn't actually seem to cause any problems though I suspect if compiled in debug mode this would cause crashes due to trying to write to unallocated memory. I just spotted this when looking at the code.

The number of bme680 calibration constants:

These constants are used here:

I believe the fix is to set this:

Hopefully I haven't just completely misunderstood something here.

The functions are given names in devAS7262.c as LedOnAS7262() and LedOnAS7262(), whereas in devAS7262.h we have LEDonAS7262 and LEDoffAS7262, causing implicit function declarations.

For sensors such as MAG3110, if we would like to use its burst mode (with auto increment, multiple bytes read), the master by the end of the read should send a NAK to the slave. See MAG3110 datasheet page 12 diagram as an example.

However the API function i2c_status_t I2C_DRV_MasterReceive() does not handle this situation, i.e. no NAK is sent by the master when doing a block read.

A possible fix could be as follows, at line 778 and onwards in fsl_i2c_master_driver.c

        /* Dummy read to trigger receive of next byte in interrupt. */
        I2C_HAL_ReadByte(baseAddr);
        SEGGER_RTT_printf(0, "\r\n\trxSize is %d.\n\n", rxSize);

        while((rxSize--))
        {
            /* Wait for the transfer to finish.*/
            I2C_DRV_MasterWait(instance, timeout_ms);
            SEGGER_RTT_printf(0, "\r\n\trxSize is %d.\n\n", rxSize);
            if (rxSize == 0)
            {
                I2C_HAL_SendStop(baseAddr);
            }
            if (rxSize == 1)
            {
                I2C_HAL_SendNak(baseAddr);
            }
        }

This gives a correct i2c ACK and NACK behaviour, however it would not return kStatus_I2C_Success after the change has been made.

See KSDK API v2.0 as this version takes care of the rxSize value and sends the needed NAK at the end of the receiving operation, in fsl_i2c.c.

status_t I2C_MasterReadBlocking(I2C_Type *base, uint8_t *rxBuff, size_t rxSize)
{
    status_t result = kStatus_Success;
    volatile uint8_t dummy = 0;

    /* Add this to avoid build warning. */
    dummy++;

    /* Wait until the data register is ready for transmit. */
    while (!(base->S & kI2C_TransferCompleteFlag))
    {
    }

    /* Clear the IICIF flag. */
    base->S = kI2C_IntPendingFlag;

    /* Setup the I2C peripheral to receive data. */
    base->C1 &= ~(I2C_C1_TX_MASK | I2C_C1_TXAK_MASK);

    /* If rxSize equals 1, configure to send NAK. */
    if (rxSize == 1)
    {
        /* Issue NACK on read. */
        base->C1 |= I2C_C1_TXAK_MASK;
    }

    /* Do dummy read. */
    dummy = base->D;

    while ((rxSize--))
    {
        /* Wait until data transfer complete. */
        while (!(base->S & kI2C_IntPendingFlag))
        {
        }

        /* Clear the IICIF flag. */
        base->S = kI2C_IntPendingFlag;

        /* Single byte use case. */
        if (rxSize == 0)
        {
            /* Read the final byte. */
            result = I2C_MasterStop(base);
        }

        if (rxSize == 1)
        {
            /* Issue NACK on read. */
            base->C1 |= I2C_C1_TXAK_MASK;
        }

        /* Read from the data register. */
        *rxBuff++ = base->D;
    }

    return result;
}

Update SEGGER RTT header files to match newest SEGGER RTT version, modified to size RTT buffer appropriately for KL03 memory constraints combined with Warp firmware typical RTT output needs.

Add a function that will test the flash (and driver) by writing to it and reading back. (Potentially other operations, too.)

Perhaps it would make sense to organize this as a separate build of the firmware that a definition in config.h controls. E.g., WARP_BUILD_ENABLE_SELFTEST. This way the self-test code will not take up important space in production builds.

Use a menuTargetI2Caddress like menuTargetSensor to remove unnecessary case checking code

Currently some of the files have windows style line endings. This will need to be normalised acorss the project to either CR+LF or LF

All CCS811 readings show 0xFD 0xFD for ECO2, TVOC & RAW ADC
Firmware version:
parent e1b54ce commit 42d8caf

z command incorrectly converts most sensor register values across the sensor types.

For example,

When the magnetometer data sheet register map is:

So the conversion for the hall sensor data should be:

readSensorRegisterValueCombined = ((readSensorRegisterValueMSB & 0xFF) << 6) | (readSensorRegisterValueLSB >> 2);