How to upgrade a custom firmware over the air with DFU process (Help wanted)

[ghost]

👉 NOT AN ISSUE. ONLY NEED A SUPPORT

Hi all, first, thank you for your jobs! My Pinetime runs Infinitime v1.0.0 and to play with it, I would like to flash a custom firmware over the with Nordic DFU service.

1) I modificated a display app title (icon) inside the applications lists: ("3" instead of "2")

std::unique_ptr<Screen> ApplicationList::CreateScreen2() {
  std::array<Screens::Tile::Applications, 6> applications {{
    {Symbols::paintbrush, Apps::Paint},
    {Symbols::paddle, Apps::Paddle},
    {"3", Apps::Twos},  // MY MODIFICATION => "3" instead of "2"
    {"", Apps::None},
    {"", Apps::None},
    {"", Apps::None},
  }};

2) I configure CMake with this following line:

cmake -DARM_NONE_EABI_TOOLCHAIN_PATH=/usr -DNRF5_SDK_PATH=/home/asuju/Work/InfiniTime/deps/nRF5_SDK_15.3.0_59ac345 -DUSE_JLINK=1 -DNRFJPROG=/usr/bin/ -DBUILD_DFU=1 ../

3) I build the pinetime-mcuboot-app:

make -j pinetime-mcuboot-app

4) I flash my new firmware using the zip archive and nRF Connect app and its DFU service.

At the end of transmission, the bootloader confirms the validity and the Pinetime reboots. The firmware loading process (green pine) stops at about 95%, the Pintetime resets and the firmware loading process starts again and completes after few seconds.

Unfortunately, my modification doesn't appears 😢

Can you help me to identify my mistake?

In advance thank you.

Julien

PS : I tried also to increase the version, 1.0.1 without success.

💁 v1.0.0 is always displayed below the pine green during the firmware loading process.

[nlfx]

The firmware loading process (green pine) stops at about 95%, the Pintetime resets and the firmware loading process starts again and completes after few seconds.

This means that there was a problem with your modified firmware (crash or infinite loop for instance), and the bootloader reverted to the previous working one. Basically, if there is a reset before you can go in the "Firmware" menu to manually validate it, the bootloader will revert the firmware to the previous version.

But if you only modified the name of the game, and nothing else: except checking that you don't have any error during compilation, I really don't know how you would debug this with a sealed watch.

PS : I tried also to increase the version, 1.0.1 without success.

tipping_hand_person v1.0.0 is always displayed below the pine green during the firmware loading process.

This part is normal. The version you see on the pine cone is the version of the bootloader, not the one of the application firmware. It comes from this image in the JF002/pinetime-mcuboot-bootloader repository.

[ghost]

Hi @nlfx,

This means that there was a problem with your modified firmware (crash or infinite loop for instance), and the bootloader reverted to the previous working one. Basically, if there is a reset before you can go in the "Firmware" menu to manually validate it, the bootloader will revert the firmware to the previous version.

Yes, I agree and I know this nominal behaviour of a bootloader.

But if you only modified the name of the game, and nothing else: except checking that you don't have any error during compilation, I really don't know how you would debug this with a sealed watch.

I doesn't have any error during the build. I just to want to get familiar with the ecosystem and DFU process. This is the reason of my small and only modification. Changing title game ("3" instead of "2").

This part is normal. The version you see on the pine cone is the version of the bootloader, not the one of the application firmware. It comes from this image in the JF002/pinetime-mcuboot-bootloader repository.

Thank you for information.

[nlfx]

Hi @pur-jus

Here is a version I compiled with your change: pinetime-mcuboot-app-dfu-1.0.0-modif.zip

If it does not work, there is either:

• A problem with your OTA DFU software? I use Siglo from my PinePhone so I have no experience with nRF connect.
• A problem with your PineTime hardware? But if you can flash and the bootloader can revert the firmware, I would guess that your SPI flash is working correcly, so I really don't know.

If it works, then it's a problem with your compilation environment. I'm using the gcc/g++ 10.2.0 ARM cross-compiler available on Fedora 33. But building using the Docker image should work fine.

If none of the above helps, hopefully someone else more familiar with the PineTime and InfiniTime has a better idea of what could be the problem.

[Avamander]

I'd suspect a hardware (register) misconfiguration, power cycle the watch before a new DFU attempt and after the DFU is successful (before first boot) and see if the issue persists.

[ghost]

Hello @nlfx

Thank you for your allocated time. Your image works...

Currrently, I develop on Ubuntu 20.10 inside a virtual machine based on Windows 10. Bellow the version of my toolchain:

ju@jubuntu:~$ arm-none-eabi-cpp --version
arm-none-eabi-cpp (15:9-2019-q4-0ubuntu1) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

And just now... I see that my version is too older regard to the recommendations 😢 (I installed it with ´´apt install´´)

Therefore, I will try to update my toolchain and test again. If the result is negative, I will use the Docker solution.

I keep you informed.

@Avamander It seems that isn't due to a HW misconfiguration.

[ildar]

that could be a similar artifact I found: sometimes the resulting image has an offset of 64 while the linker script implies 32. check the hex file to know for sure. Or you can upload the generated files somewhere so that ppl can analyze them.

[ghost]

Hi all,

With a recent version of GCC ARM toolchain (gcc-arm-none-eabi-10-2020-q4) it works 🍾 Thank you for your support!