Updating the application image

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

(Using standard BCM943341 Evaluation Board, with WICED 3.1.1).

I want to be able to re-flash the application area and reboot with the new firmware.  I already would have the new application .elf file available in a large buffer (having received it eariler via a serial connection).

Now, I know that there is the 'ota_fr' example and I've studied this in some detail (including its connection to the 'waf' routines to work with the on-board flash memory).  However, it uses a full blown HTML script and the WICED web server.  I just want to update (erase/write) the current application that I already have waiting in a buffer.

Does anyone have a sample piece of code to do this?

-- Robert

0 Likes
9 Replies
Anonymous
Not applicable

Hi,

The OTA server is just a helper to grab the new version. However in its core it is using wiced_framework_apps APIs. These are a set of APIs that allows you to read, write and erase applications. For an example of this  have a a look libraries/daemons/ota_server/wiced_ota_server.c, This include calls to set size of application and write it and even set the boot to use the new file. Also have a look at wiced_framework.h which explains how to use the APIs.

Regards,

Bassem

0 Likes
Anonymous
Not applicable

hi bassem_dawood,

Is it safe to OTA application images built with different SDK version?

We may release our application image built with SDK-3.1.1 to our

customers. We will migrate to newer SDK latter.

I'm wondering if it's safe to OTA to new application image that is built

by newer SDK (e.g. 3.1.2 or 3.1.3).

The OTA only update application image so we need to know if all other

parts are compatible to images built by new SDK.

Thanks.

0 Likes
Anonymous
Not applicable

Yes, no problem in this. (as long as all applications are built with  WICED 3.1.1 or later)

0 Likes
Anonymous
Not applicable

Bassem:

   Thanks for your hints about the wiced_ota_server.c and wiced_framework.h files!

   Can you tell me if there is an illustration somewhere that shows the memory map of the Internal Flash?

   Cheers, Robert

0 Likes
Anonymous
Not applicable

Internal flash map depends on the platform. Each platform has its own MCU and flash. your best approach would be to look at the linker scrip files in the MCU. This can be found under the WICED/platform/MCU folder. for example to have a loot at STM32F437 memory map, see:

WICED/platform/MCU/STM32F4xx/GCC/STM32F437/memory_with_bootoloader.ld

same goes for other platforms.

Regards,

Bassem

0 Likes
Anonymous
Not applicable

QUESTION: Aside from using the full Eclipse WICED IDE, is there a stand-alone way (via command line) to flash a Broadcom target, given a stripped ELF file?  So, I want to perform the same action as double-clicking on the "target" with "download run", but without being within the Eclipse environment.

Cheers, Robert

0 Likes
Anonymous
Not applicable

Hi,

you can run the make command from the command line, the IDE is just there to help browsing and debugging. So if for example your make target is "snip.scan-BCM943362WCD4 download run" , then:

- open a command line and go to the wiced root folder

- type your command: "make snip.scan-BCM943362WCD4 download run"

that's about it.

Happy holidays,

Bassem

PS: sorry for the late reply because of the new years break.

0 Likes
Anonymous
Not applicable

Bassem:

   That does work!  Now, I have a related question: If I have all the proper files (stripped elf file, etc.) are available, can I 'flash' the Broadcom part from the console without all the 'make' processing being involved?  Or is the only way to load a new application to the part is to use the 'make <target>' command line?

Cheers, Robert

0 Likes
Anonymous
Not applicable

Hi,

The formal way to do it is just to issue make again, the first call to make, will build the applications and download the code. After that all the subsequent calls to make, will just do downloading, because the binaries are all built. So in theory next makes are just download commands.

The other way, is to issue an openOCD command manually. you can find a sample of those commands in tools/makefiles/standard_platform_targets.mk, you can have a look at the download_bootloader target for example (here is  a sample):

$(call CONV_SLASHES,$(OPENOCD_FULL_NAME)) -f $(OPENOCD_PATH)$(JTAG).cfg -f $(OPENOCD_PATH)$(HOST_OPENOCD).cfg -f $(OPENOCD_PATH)$(HOST_OPENOCD)-flash-app.cfg -c "flash write_image erase $(BOOTLOADER_OUTFILE).stripped.elf" -c "shutdown"

offcourse a lot of these are in Make variable to account for different make targets, but the idea is to issue a "flash write_image erase xxx.stripped.elf" following by shutdown command. For more details have a look at OpenOCD command line options.

Also note that the actual make download is downloading 3 programs: Bootloader, DCT and Application, so if you are going to do downloading manually, you need to repeat the previous step 3 times (one for each stripped image). There is currently ongoing work to produce a combined imaged that can be used to write the 3 images at once, but it won't be released until next version.

Regards,

Bassem

0 Likes