After flashing to ruuviTag a NFC example from Nordic sdk, modifying makefile, sdk_config.h and main.c to be ready for ruuvitag device It is not possible to reflash teh device anymore.
It seems to be in bootlader foerever as I can see ruuviBoot in nrf Toolbox & nrd Connect, but with the Red led flashing once per second more or less. In this situation I have not been able to reflash the device anymoore.
Is anybody in the same situation? Is it something related with the primary bootlader? I really don’t know what to do…
The execution starts at bootloader and tries to proceed to application after verifying the application. It might be that your application crashes, forcing RuuviTag back to bootloader. Have you tried keeping the “B” pressed to keep tag in bootloader mode?
Thanks for the explanation. I detected 2 behaviours that I can differenciate:
Red led flashes once a second when battery is low–> Solved!. Once battery is recovered the flashing process works as expected and finishes.
Once the flashing process finishes the device keeps in bootloader mode for some reason. Red led on foerever an ruuviBoot detectedin nRF Connect tool, I tried pressing B button while flashing but the application does not start neither. Tested with weather station and Eddystone firmwares.–> NOT SOLVED. Still seeing RuuviBoot device and not RuuviTag!!! Can somebody give a hint on that?
Let me give more info that can clarify the issue:
The issue appeared after flashing trough DFU the ruuviTag with the nordic DSK record_uri example as I wanted to use the NFC antenna; I modified the board files, sdk_config.h, makefile and main.c to use the Port th e nordic example from the development kit to the ruuvitag.
The device is flashed correctly using DFU but It does not enter in application mode and keeps itself in bootloader mode forever.
I thik the issue could be related with the mapping of the flash --> something that the record_uri example from nordic have overwritten into flash memory that doesn’t let the weather station default application starts.
Does Ruuvi team has some zip file to use trough DFU to map all the flash memory to default values? Maybe this will solve the issue.
Could you please send me the original DFU package with NFC as well as the makefile? I’ll send you my email through private message. You could also ask for invite to our slack channel by sending mail to info@ruuvi.com so we can communicate faster.
It is possible to create an application hex which will cause CRC calculation of bootloader to fail even on valid application. This in turn causes valid application being rejected, leaving the bootloader in unusable state.
As a workaround, a new bootloader which ignores CRC error can be uploaded to RuuviTag, and a valid application can then be uploaded.
Hi @otso, it seems like I also have messed up my bootloader. Even applications that previously worked now sets the bootloader i never ending loop, i.e. it does not exit and start the application.
Is it possible to DFU a new bootloader that ignores CRC? Could you detail that out for me please and point to where I can get hold of that bootloader.
Upload the rescue.zip to your RuuviTag. This “flushes” the corrupt application from first flash bank, however the application will still be corrupted. It also replaces the softdevice and bootloader. Softdevice is valid, but bootloader might have issues in future.
Enter bootloader again. Verify that bootloader is now named “DFUTARG”.
Upload Weather station to DFUTARG. As the corrupt application is now flushed out of the flash, you’ll get properly functioning Weather station.
Could you please email the faulty DFU packet to me (otso@ruuvi.com)? I’d like to check how the bootloader got corrupted.
Nordic just released an update to SDK12.3, which might have the proper fix for bootloader issues. I’ll verify the new bootloader ASAP and if it does not get bricked anymore with known problematic packages, I’ll update the rescue bootloader.
I’m not exactly sure which DFU packet that was the faulty one because I first thought it was just an error in the code so I made a few variants. I’ll try to locate the initial one responsible for the crash.
Thanks for the fix, it worked but I had to restart nRF Connect to see the “DFUTARG”, it still showed the “RuuviBoot” before restarting. Sometimes I wonder if the nRF Connect could be part of the problem. For instance I have noticed that after DFU it sometimes does not disconnect properly.
I tested the DFU packets you sent with new (SDK12.3) bootloader, this time the bootloader works as expected. However, one of the packets created by Apamies still hang the bootloader. I’ll create an update packet with fixed updated bootloader early next week.
I think any future DFU packet should contain both bootloader + application: This way update should be safe to any tag “out in the wild”, even if it’s running 12.2 version of bootloader. This of course causes uploads to take some extra time, and developers with updated bootloaders can use application-only packets while developing as long as “release” version of packet contains the updated bootloader just in case.
The leds+button are specific for RuuviTag, however the bootloader can be used on PCA10040 (and any other board which has button on same pin and LEDs do not cause conflicts)