Hi Dialog Users,
I'm studying the SUOTA service and its possible implementation on a DA14580 working in external processor mode (connected to an external MCU on which the application code resides).
In future projects we will need to upgrade firmware code of the DA14580, not that of the external MCU. If I correctly have understood, the SUOTA feature will instead allow us to upgrade
only the external MCU code, not the code of DA14580, unless the external MCU is able to erase/program the external SPI flash from which the DA14580's secondary bootloader expects
to find the new image it will load.
Am I correct?
Thanks for your support,
scrat75.
Keywords:
Device:
Hi scrat75,
The SUOTA will take the image that you provide from the android application and write that image to the external flash/eeprom that connects to the 580. After the SUOTA operation completes the 580 will boot from flash and run new firmware that you ve just downloaded. In case of a fully embedded solution external processor, that means that the application runs on an external MCU the SUOTA wont update the application that runs on your external MCU.
Thanks MT_dialog
Hi DIalog Support/Users,
as you have written I can interpret that the (SUOTA enabled) application task running on the DA14580 is able to erase/write the external
SPI flash and also to send/trigger (via GTL layer/UART interface) some or all of the notification events/callbacks in the application user
section running on the external MCU. Am I right?
Thanks in advance for your answer.
Hi scrat75,
The 580 can operate under 2 configurations, fully embedded (run the application implemenation over an external MCU and communicate with the 580 over GTL -a dialog's custom protocol- via UART) and fully hosted (the internal 580 MCU runs the application and the bluetooth stack). In the fully embedded mode with an external MCU the application handles the messages received from the profile section that its located in the 580. For example in the creation of the SUOTA database, the application will send a app_spotar_create_db() and this will pass to the 580 and the database will be created, then the 580 will respond with a confirmation message that the db was created and the application should catch this message in the HandleBleMsg() function and handle it via the spotar_create_db_cfm_handler() for example after the db has created start advertising or create the db for another service etc.
Thanks MT_dialog
Hi DIalog Support/Users,
Here the results of my final tests:
DA1458x_SDK_5.0.3\DA1458x_SDK\5.0.3\projects\target_apps\ble_examples\prox_reporter_extfolder.
I modified APP_DIS_SW_REV "0.0.1" define in the app.h header file and I built the project producing an
hex file that I renamed intoprox_reporter_ext.hex;
DA1458x_SDK_5.0.3\DA1458x_SDK\5.0.3\projects\target_apps\prod_test\prod_testfolder.
I built the project producing bin fileprod_test_580.bin;
Thefile ble_580_sw_version_0.hcontains the following code lines:
#define DA14580_SW_VERSION "v_5.0.3.0"
#define DA14580_SW_VERSION_DATE "2016-05-19 16:01"
#define DA14580_SW_VERSION_STATUS "REPOSITORY VERSION"
Now thefile ble_580_sw_version_1.hcontains the following code lines:
#define DA14580_SW_VERSION "v_5.0.3.1"
#define DA14580_SW_VERSION_DATE "2016-05-19 16:04"
#define DA14580_SW_VERSION_STATUS "REPOSITORY VERSION"
C:\Users\monsminc\Documents\Dialog\DA1458x_SDK_5.0.3\DA1458x_SDK\5.0.3\utilities\secondary_bootloader,
producing thesecondary_bootloader.hex; converted in binary format running the following command:
hex2bin secondary_bootloader.hex
mkimage multi spi secondary_bootloader.bin prox_reporter_ext.img 0x8000 prod_test_580.img 0x13000 0x1F000 da14580.bin
to produce a dual image that I have burned in the external SPI Flash using SmartSnippet (I did not make bootable
the image because if I correctly understood themkimage.exemakes automatically that operation);
in theDA1458x_SDK_5.0.3\DA1458x_SDK\5.0.3\projects\host_apps\windows\proximity\reporterfolder.
I executed the resultinghost_proxr_sdk.exepassing it at the command line the COMM number
of the Virtual Com Port seen when I attached the DA14580 Development Kit to my PC.
and copying in theNexus 9\Internal storage\Suotafolder another img files result of previous experiments.
the resulting next screen shown me the exact Firmware revision and Software revision that I set. Clicking on the
update devicebutton of the SUOTA app let me obtained the next screen page where I selected the
image bank to upgrade; I selected the second one (image bank was set to 2) telling to the app to reprogram the SPI
flash memory mapped on the P0_0 (sck), P0_3 (cs), P0_5 (miso) and P0_6 (miso). The SUOTA correctly download the new
image that I selected (I saw the downloading progress both on the screen app and in the console of the
host_proxrproject.
also I terminated the running console program of thehost_proxrproject. Then I compared
the choosen image present on the Nexus 9 (the one that I downloaded with the SUOTA app) against the file
upgrade_image2.imggenerated by the console program (present in
DA1458x_SDK_5.0.3\DA1458x_SDK\5.0.3\projects\host_apps\windows\proximity\reporter\host_proxr_sdkfolder:
they are of the same size and differ only in one byte (byte 33th - I used cmp -l -b file1.img file2.img to compare the two images).
to read its contents before and after the tests exposed above and compared against to see if they differ. They match.
这s means that in the external mode (also called Fully Embedded) the SUOTA app allows to update the firmware
of the external MCU, not the one burned in the SPI Flash.
So my question is: Is there a way to update also the SPI Flash from which the DA14580 boots in the presence of External Mode configuration?
Thank in advance for your attention
Hi scrat75,
外部接近记者中的示例s the file that from SUOTA and stores it on the disk. So since the file is located at your external processor you have the option to download the firmware on your 580 directly. Since you dont want to download the firmware directly and you want to burn the flash with the image i can think of two options.
1) The external processor to share the SPI flash with the 580, so directly burn the image to the corresponding memory address of the SPI (the tricky part in this is to ensure that there is no chance that both MCU are trying to access the flash, you can try to keep the 580 in reset state while the external MCU downloads the binary).
2) You can download the fw to the flash through the 580, in this case you can alter the flash_programmer (the utility that the Smart Snippets uses), download the flash_programmer to the 580 and then provide the new suota image so that the 580 will burn it to the flash (this requires implementation from the host side of the MCU).
Thanks MT_dialog
Hi DIalog Support,
Is there a documents in the User Manual or in the Application Note folders that explains the protocol the external Main MCU and theflash_programmer
both must implement and to follow to exchange data and to correctly program the external SPI Flash. I know that I can obtain it making the reverse engineering of the
flash_programmer's code project, but I think that if you can point me to an official document, that it's better..
Thanks in advance for your reply
Hi scrat75,
The implementation explained above isn't implement by Dialog and there is no document explaining the function of the flash programmer. Flash programmer's main purpose is to be used only in smart snippets and not by an external MCU in order to burn the flash through the 580, but is the only available example for your case since you would like to follow this option.
Thanks MT_dialog