SUOTA外部processore(如果/ UART)

8 posts / 0 new
Last post
scrat75
Offline
Last seen:4 years 11 months ago
加入:2016-05-03 09:53
SUOTA外部processore(如果/ UART)

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.

Device:
MT_dialog
Offline
Last seen:2 months 4 weeks ago
Staff
加入:2015-06-08 11:34
Hi scrat75,

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

scrat75
Offline
Last seen:4 years 11 months ago
加入:2016-05-03 09:53
Hi DIalog Support/Users,

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.

MT_dialog
Offline
Last seen:2 months 4 weeks ago
Staff
加入:2015-06-08 11:34
Hi scrat75,

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

scrat75
Offline
Last seen:4 years 11 months ago
加入:2016-05-03 09:53
Hi DIalog Support/Users,

Hi DIalog Support/Users,

Here the results of my final tests:

  1. I loaded in KEIL uVision IDE theProximity Reporter External Modelocated in the
    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;
  2. I ran the commandhex2bin prox_reporter_ext_0.hexto produce the corresponding binary fileprox_reporter_ext.bin;
  3. I loaded in KEIL uVision IDE theProduction Testlocated in the
    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;
  4. I ran the commandmkimage single prox_reporter_ext.bin ble_580_sw_version_0.h prox_reporter_ext.jmg;
    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"
  5. I ran the commandmkimage single prod_test_580.bin ble_580_sw_version_1.h prod_test_580.jmg;
    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"
  6. I loaded and built in the Keil uVision IDE the secondary bootloadet project located in the
    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
  7. I ran the command:
    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);
  8. I loaded and built in Microsoft Visual Studio C++ 2010 edition the projecthost_proxrlocated
    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.
  9. Next I installed on a Nexux 9 running Androind 6.0.1 the Dialog SUOTA app, attaching the Nexus to the PC via USB
    and copying in theNexus 9\Internal storage\Suotafolder another img files result of previous experiments.
  10. I launched the SUOTA app that successfully discovered my DA14580 Development Kit; then I made a connection to it;
    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.
  11. At the completion of download I answered no to the boot request and I disconnect from my development board;
    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).
  12. To be sure that the SUOTA app did not modify the external SPI Flash connected to the DA14580 I used the SmartSnippets
    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

MT_dialog
Offline
Last seen:2 months 4 weeks ago
Staff
加入:2015-06-08 11:34
Hi scrat75,

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

scrat75
Offline
Last seen:4 years 11 months ago
加入:2016-05-03 09:53
Hi DIalog Support,

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

MT_dialog
Offline
Last seen:2 months 4 weeks ago
Staff
加入:2015-06-08 11:34
Hi scrat75,

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

Topic locked