V0.1 HW acceptance testing

[elsalahy]

Summary:

With the arrival of the node V0.1 PCB, we need to test the first prototype to ensure it is an acceptable prototype that can be used in the development of the device firmware.

The PCB is expected to arrive by 3rd of July and will be soldered and prepared internally for testing and development.

Why do we need this?

To ensure we have a valid HW platform that allows for application development according to the requirements in #7 & #9

What is already there? What do you see now?

• Initial HW design V0.1 (schematic and PCB routing)
• Sample WL applications from ST
• initial board support package SW and sensors integrations #15 #16 #18

What is missing? What do you want to see?

• Testing and verification of critical system components.

How do you propose to implement this?

• Provide a break-down of the components
• Devise simple acceptance tests for each system component (using available HW and SW tools)
• Plan advanced acceptance tests (that should be targeted/completed as we proceed with FW development)

Environment:

Baremetal.

Acceptance Criteria:

• Each system component must have a functional acceptance test scenario.

The acceptance test scenario can be very simple, but must meet the following criteria:

• Targets only the system component.
• Tests the targeted system component basic functionality (e.g ON-OFF, responsiveness)
• Reports all information at runtime.

What can you do yourself and what do you need help with?

Will be done by me and @azerimaker.

Below is a breakdown of the various system components.

[elsalahy]

System components that require initial acceptance testing and verification.

Add issue, PR or test code URL in x

SOC (MCU) STM32WLxx_QFN48

• [ ] SWD (flashing and debugging), covered in X
• [ ] External 32k oscillator, covered in X
• [ ] SPI bus, covered in X
• [ ] I2C1 bus, covered in X
• [ ] I2C2 bus, covered in X
• [ ] UART bus, covered in X

SOC (SX1262) STM32WLxx_QFN48

• [ ] 32MHZ TCXO, covered in X
• [ ] FE_CTRL (1,2,3), covered in X

Sensors & External

• [ ] SHTC3 (Temperature & Humidity), covered in X
• [ ] LIS2DH12 (Accelerometer), covered in X

Secure element

• [ ] ATECC608A-TNGLORAU, covered in X

External Flash

• [ ] MX25R1635, covered in X

Input/Output

• [ ] TPS22917DBV (3x Load Switches), covered in X
• [ ] Buzzer, covered in X
• [ ] RGB LED, covered in X
• [ ] Button, covered in X

Battery

• [ ] SI2323DS (Battery protection mosfet), covered in X
• [ ] Buck-Boost RP605Z283B (Battery voltage and monitor), covered in X

[elsalahy]

@azerimaker Feel free to add below as a sperate comment the components that I might have missed in the same fashion.

Remember this is acceptance testing!

[elsalahy]

Progress update:

• Tried flashing the adjusted sample LoRaWAN app that was prepared (functional and tested on Nucleo board) but the node seems to get stuck at RTC_Init, specifically in while (LL_RCC_LSE_IsReady() == 0U) This is critical and will be heavily investigated.

• LEDs and buzzer seem functional on board #2

• System reset using the debugger (openOCD or via normal flashing) is misbehaving, either pushing the reset button or removing the battery fixes the issue and boots the new application.

[elsalahy]

All can be viewed in this branch up to this commit https://github.com/TheThingsIndustries/st-node/commit/2b0dc248c87f6cd59ee9ff1807d7ed4da6e5d3b2

[elsalahy]

Also created this branch with a basic LED test to be used for observing a normal (non-RTC) running clock and will be used as base for simpler tests

[elsalahy]

ATECC608A-TNGLORA Secure Element test on board #2 is responsive 🎉 and we can successfully read the serial number Can be observed in this branch

[azerimaker]

Did a load and a current consumption tests to the BUCK_BOOST converter. Some takeaways:

• It's able to deliver up to 300mA without any issues @3V input.
• @2V (as the battery drains) current delivering capability goes down almost in half
• Quiescent current (IDLE) is impressively low (~350 nA)

[azerimaker]

• System reset using the debugger (openOCD or via normal flashing) is misbehaving, either pushing the reset button or removing the battery fixes the issue and boots the new application.

yes, this is a weird issue. I've tried various solutions but none seem to solve this. I'm suspecting that the SoC has a HW bug. Will contact ST on this.

[elsalahy]

Successfully managed to communicate with the SHTC3 temperature and humidity sensor 🎉 and retrieve readings using the pre-preprepared driver.

Can be observed in this branch. Update: This was tested on board #2

[KrishnaIyer]

Wow nice. Also SO MUCH PURPLE!

[elsalahy]

LoRaWAN application (LoRa + RTC+ ST LMN stack port) is functional on board #1 and the node joins successfully 🎉 This validates numerous internal components such as the TCXO, Antenna and the power supply design. Can be observed in this branch

[elsalahy]

The Flash seems to be responding to SFDP commands and the Macronix ID (0xc2) is reported correctly Can be observed in this branch Update: This was tested on board #1

[elsalahy]

The Accelerometer LIS2DH12 is responding on board #1 and x,y,z readings are retrieved successfully. But further investigation is needed as the I2C bus read looks unstable and sometimes when the devices is reset, the Accelerometer doesn't respond even on board #1, and on board 2 the Accelerometer is not responding

Can be observed in this branch.

[azerimaker]

@elsalahy captured some I2C packets between SHTC3 and the STM32WL. It looks like the bus is functioning normally with the clean edges and I do get some data back from the sensor, but I still can't read the accelerometer. The culprit is either the Accelerometer IC itself or the soldering joints, which I can't really see. I will resolder another IC at home and retest it.

[elsalahy]

@azerimaker Sounds good I'm happy the issue is not with the I2c bus itself, thanks for keeping me updated

[elsalahy]

Progress update:

• The reset on board #1 seems to be behaving as expected after a fix by @azerimaker
• RTC issue now exists on board #1 after the soldering of the accelerometer and the new debug interface.
• Can't seem to interface the UART pins on board #1 using the STDC14 connector of the debugger, indicating that there might be an issue with the UART pins on the board, or the virtual com on the debugger needs a specific jumper/routing config,

  Please note that the same app and same UART pins connection on the Nucleo board is functional and printing at 1152008N1.

UART branch.

[elsalahy]

ADC read of the device internal ADC_CHANNEL_VREFINT is 0x6fa which is 1786 as a raw value With calibration equation=Vdd = 3300*(*VREFINT_CAL_ADDR)/ADC_raw = (3300*1510)/1786 = 2790mv ~=2.79 Volt @azerimaker does these numbers look good, do we supply the node with ~ 2.8V?

The same application failed to read from the buck boost ADC pin PB2 (channel 4) after enabling with PB4 on board #1 Need to try this on other boards to investigate more as it might be a soldering issue of the pins, or ADC read bug in the FW

Can be observed in this branch

[elsalahy]

A small background and update on the RTC issue:

The LoRaWAN example provided by ST, uses the node external 32KH oscillator to provide real-time functionality in the example application and this is used in time stamping the events and sending the sensor data in specific intervals.

The external oscillator becomes unstable in the event of a power reset and then the system initialisation waits on the RTC to stabilise.

Current situation:

Node Number	External Oscillator 32KHZ (RTC on LSE )	Debug interface Nreset and reset button
1	❌	✅
3	✅	❌

[azerimaker]

Prototype status (continuous update):

Node #	PSU	SWD	VBAT Mon.	Load SW.1,2,3	Accel.	Temp. Hum.	Flash	Sec. Elm.	Buzzer	RTC	UART	LoRA
1	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
2	✅	✅	✅	✅	❌	✅	❗	❗	✅	⭕	✅	❌
3	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
4	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅
5	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅	✅

legend: ✅ - works well ❌ - doesn't work ⭕ - erroneous behavior ❗ - untested/unable to test

[azerimaker]

Power supply test

LoRaWAN Tx (Class A) effect on the Battery (yellow) and VDD (blue).

Some key observations:

• TX takes around 88ms
• (Fig.2) Voltage droop is only around 45mV (which shows that the Buck-Boost is pretty stable and responds quickly)
• (Fig.3) Buck-Boost regulator immediately changes switching frequency to accommodate instant jump in current.
• (Fig.4: colors swapped) it takes roughly 8ms for the Buck-boost PSU to stabilize at 2.8V (yellow trace) with soft-start function. Before even battery voltage settles (blue trace).

Fig.1: Fig.2: Fig.3: Fig.4:

[elsalahy]

We need to write a small conclusion report and attach it here to close this issue. CC: @azerimaker, can you please write-up the HW observation and the planned HW fixes/modifications. I will write-up the SW observations and bugs/issues that need to be handled.

We should close this issue by tomorrow.

[azerimaker]

Some more low power testing with following setup:

• Input voltage: 2.9V
• Est. battery capacity: 2000 mAh
• Used ST FW: v.0.4 PWR->STOP2 example
• Measurement windows: 5 seconds and 60 seconds
• Measurement tool: Atmel Power Debugger

1 min. window average for two periodic wakeups and going into STOP2 mode. Est. battery life 78 days.

Current consumption in STOP2 mode: ~600nA instant, ~2.5 μA average (periodic pulses by the Buck-Boost converter)

Est battery life if the device is always in STOP2 mode: :cool:

[azerimaker]

All the boards are tested in depth and only one board (2) is partially functional (will debug it later) other are working well.