C
You can reset the devnonce on TTN (or even set it to be ignored). Go to the end devices section on TTN, open the end device affected, go to settings and scroll down all the way to join settings and click expand.
The devnonce is stored in the nvs partition, which is normally not erased when just flashing a firmware update. But if the board is erased completely then the last devnonce used is also erased.
Hello @Pauleera , yes the board can still be used, the documentation is available here: https://docs.pycom.io/
The Pybytes platform however is no longer online, and old Pycom products are not supported on the SG Wireless Cloud platform.
To modify the functionality of J102, which is the USB OTG peripheral of the esp32s3, you need to modify ext/micropython/ports/esp32/usb.c
The REPL on UART0 is enabled by default, you cannot just re-assign the UART peripheral, which is why the board crashes.
If you want to disable the REPL on UART0, you can modify https://github.com/sg-wireless/sg-sdk/blob/40dbabba63db543aeeaa9a313fc00faebd0169cb/src/platforms/F1/sdk-main/micropython/mpconfigboard.h#L7
Hi @jandls, to add to @wilsonto, we do have direct support in MicroPython to interact with the BQ27441. Please note that it is only powered when a battery is connected.
https://github.com/sg-wireless/sg-sdk/blob/main/src/platforms/F1/comps/fuel-gauge-if/fuel_gauge.md
Yes, J102 is connected to the USB OTG peripheral of the esp32. I can be used in host or device mode depending on the application requirements. The MicroPython firmware configures it in device mode with serial REPL support.
Please note that the starter kit cannot be powered via J102.
Updated in regards to powering connected devices
These are the defaults when using SPI mode according to the MicroPython source code ext/micropython/ports/esp32/machine_sdcard.c
if (is_spi) {
// SPI interface
#if CONFIG_IDF_TARGET_ESP32S3
STATIC const sdspi_slot_config_t slot_defaults[2] = {
{
.gpio_miso = GPIO_NUM_36,
.gpio_mosi = GPIO_NUM_35,
.gpio_sck = GPIO_NUM_37,
.gpio_cs = GPIO_NUM_34,
.gpio_cd = SDSPI_SLOT_NO_CD,
.gpio_wp = SDSPI_SLOT_NO_WP,
.dma_channel = 2
},
SDSPI_SLOT_CONFIG_DEFAULT()
};
Hello @jandls,
Please see the following from the MicroPython documentation:
Please note that on the Starter Kit, only 1 of the data pins is connected to the ESP32-S3 as anything else would require a hardware license from the SD Association. You would have to populate R506, R508 and R510 with 0Ohm resistors to connect the GPIO pins and if necessary R500-R502 for the pull-ups.
On the starter kit, you can mount a FAT formatted SD Card like this:
import machine
sd = machine.SDCard()
os.mount(sd, '/sd')
os.listdir('/sd')
The pins are hard coded but can be changed here: https://github.com/sg-wireless/sg-sdk/blob/main/src/platforms/F1/mpy-hooks/patches/machine_sdcard.c.patch on custom designs.
I discussed this with the 1NCE commercial team. If you (already) have a business relationship with them, we can transfer the SIM card to your account. We are also looking into solutions to integrate SIM card management on our CTRL platform. I will let you know when I have more details to share.
There are no F1 specific modules in the machine module. You can find the documentation for the machine library here: https://docs.micropython.org/en/v1.19.1/library/machine.html
The mode means operating mode of the currently running LTE modem firmware. If you switch between CAT-M and NB-IoT mode, the modem will change the operation mode and will reset to load the firmware for the new mode. If it returns 0 it means it is running the CAT-M firmware, if it returns 1 it means it is running the NB-IoT firmware.
The device automatically enabled the LTE connection in order to provision the device on our cloud platform using the bundled 1NCE SIM car. In order to communicate with the cloud platform, it will use PPP (point to point) protocol. In the mode, the modem exchanges data with the host (the esp32-s3 running MicroPython) using a binary protocol. When this is active, it is currently not possible to send AT commands to the modem.
Sorry, the board does not support Sigfox at this time. We used the old Pycom documentation as a base and it seems there are instances where the team did not remove Sigfox properly. We will review and remove all mentions to Sigfox. We may support Sigfox again in the future but no decision has been made at this point.
Hello everyone,
I have created an introduction video for the F1 kit:
Feedback is greatly appreciated. Please let me know what you would like to see in future installments.
I haven’t tried this yet, but there is preview support in MicroPython.
Please check https://docs.micropython.org/en/v1.19.1/library/machine.I2S.html and let us know if this works for you.
This tutorial explains the setup required to enable Secure Boot & Flash encryption in the firmware. Please first follow the tutorial Building the firmware from source to make sure the firmware can be built on your system and all necessary tools and frameworks are installed.
It is also advised that you review the Espressif Tutorials about Secure Boot, Flash Encryption and NVS encryption. Enabling security features on your board is permanent and cannot be undone. If done improperly, you can permanently loose access to your device! We highly recommend you book a 1h free consultation with us as part of the Starter Kit purchase. Please get in contact with your sales channel to book your free consultation.
Flash encryption will not encrypt the nvs partitions. Instead, all nvs variables will be erased during the encryption process. Flashing encrypted nvs data is outside the scope of this tutorial.
Step 1: Checkout this branch of the source SDK: https://github.com/sg-wireless/sg-sdk/tree/security
cd sg-sdk
git remote update
git checkout security
Step2: Create the Secure Boot signature (make sure you backup this signature. You will not be able to sign firmware for your device without this file!):
. ext/esp-idf/export.sh
espsecure.py generate_signing_key --version 2 secure_boot_signing_key.pem
Step3: Clean and build the firmware:
./fw_builder.sh --board SGW3501-F1-StarterKit clean
./fw_builder.sh --board SGW3501-F1-StarterKit build
Step4: Erase the board and then do a full-flash in order to flash the bootloader and firmware
./fw_builder.sh --board SGW3501-F1-StarterKit erase --port /dev/ttyUSB0
./fw_builder.sh --board SGW3501-F1-StarterKit full-flash --port /dev/ttyUSB0
It is important to use the full-flash command to flash the new bootloader with secure boot enabled onto the device. The IDF build system does not flash the bootloader by default when secure boot is enabled!
IMPORTANT: After your device is flashed, the system will encrypt the partitions on the device. Due to the large flash size (16MB) and the large file system (8MB), this takes several minutes, where the device appears to be unresponsive! DO NOT INTERRUPT / RESET the board. Please wait at least 5 minutes after flashing before investigating!
When flashing the first board, it can be helpful to enable bootloader debugging. This can be done by modifying the file src/platforms/F1/configs/sdkconfig.board
# Uncomment for additional bootloader debugging
CONFIG_BOOTLOADER_LOG_LEVEL_INFO=y
CONFIG_BOOTLOADER_LOG_LEVEL=3
You can also find the secure boot and flash encryption settings in the file:
# SECURE BOOT SETTINGS
CONFIG_SECURE_SIGNED_ON_BOOT=y
CONFIG_SECURE_SIGNED_ON_UPDATE=y
CONFIG_SECURE_SIGNED_APPS=y
CONFIG_SECURE_BOOT_SUPPORTS_RSA=y
CONFIG_SECURE_TARGET_HAS_SECURE_ROM_DL_MODE=y
CONFIG_SECURE_SIGNED_APPS_RSA_SCHEME=y
CONFIG_SECURE_BOOT=y
CONFIG_SECURE_BOOT_V2_ENABLED=y
CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES=y
CONFIG_SECURE_BOOT_SIGNING_KEY="../../../secure_boot_signing_key.pem"
CONFIG_SECURE_BOOT_ENABLE_AGGRESSIVE_KEY_REVOKE=y
# CONFIG_SECURE_BOOT_INSECURE is not set
# FLASH ENCRYPTION SETTINGS
CONFIG_SECURE_FLASH_ENC_ENABLED=y
# CONFIG_SECURE_FLASH_ENCRYPTION_AES128 is not set
CONFIG_SECURE_FLASH_ENCRYPTION_AES256=y
# CONFIG_SECURE_FLASH_ENCRYPTION_MODE_DEVELOPMENT is not set
CONFIG_SECURE_FLASH_ENCRYPTION_MODE_RELEASE=y
CONFIG_SECURE_FLASH_CHECK_ENC_EN_IN_APP=y
# CONFIG_SECURE_DISABLE_ROM_DL_MODE is not set
CONFIG_SECURE_ENABLE_SECURE_ROM_DL_MODE=y
# CONFIG_SECURE_INSECURE_ALLOW_DL_MODE is not set
As you can see, the file is configured for “release” level encryption, with on-board generated random keys that are unique per device. You can use less secure options with pre-generated keys that will allow you to re-flash the device using esptool.
When using the configuration as above, you cannot flash the device with esptool again. The only way to update the firmware on the device is via an OTA update. An example to flash a new firmware OTA is (this example assumes a WiFi or LTE connection in PPP mode is already establed):
import fuota, urequests
fuota.start()
req = urequests.get('http://10.0.221.8:8000/application.bin')
fuota.write(req.content)
fuota.finish()
import machine
machine.reset()
The application.bin file can be found at ./build/sdk-default/F1/SGW3501-F1-StarterKit/micropython/application.bin
Please note that the application.bin file needs to be signed with the secure boot signature created in step 2 above. Trying to flash a firmware without valid signature will revoke your secure boot signing key and may permanently disable your device!
We will be at Embedded World in Nuremberg from 11 – 13.3.2025 and are giving away free tickets for the exhibition.
Please reply to let us know if you’re interested in attending and what you’re most looking forward to at the exhibition, and we’ll send you a free voucher code.
If you’re there, please visit us at Hall 3, Stand 3-501!
