search

zephyriot / zephyr-issues

0 stars 0 forks source link

CC3220 executable binary format support #2411

Closed nashif closed 7 years ago

nashif commented 7 years ago

Reported by Siwei Xu:

I tryed to flash zephyr demo to CC3220SF/CC3220R device via serial port, but it's always failed.

My operation steps:

  1. compile the hello_wrold/blinky demo;
  2. use Uniflash/ImageCreator to create a SFLASH image, which use zephyr.bin as "MCU image", and generate SFLASH image;
  3. programming the generated image to CC3220SF/CC3220R device via serial port(using uniflash/ImageCreator);
  4. reset SOP state and reset device;

after all of those steps done, and even the flash image successfully programmed to device, the zephyr demo always cannot running.

Does anyone can help me?

Thanks~

(Imported from Jira ZEP-2581)

nashif commented 7 years ago

by Siwei Xu:

As the document: https://www.zephyrproject.org/doc/boards/arm/cc3220sf_launchxl/doc/cc3220sf_launchxl.html

programming CC3220SF use a ELF file, so I guessed that is it any problem in linker script for CC3200 ?

nashif commented 7 years ago

by Gilbert Pitney:

Hi Siwei:

Can you please follow the Flashing instructions for Linux, and try dslite.sh command line utility?

% dslite.sh -c $ZEPHYR_BASE/boards/arm/cc3220sf_launchxl/support/CC3220SF.ccxml \ -e -f zephyr.elf

In particular, it's also important to follow step 6:

  1. Ensure CONFIG_XIP=y is set
nashif commented 7 years ago

by Siwei Xu:

Hi Gilbert Pitney ,

I tried to use dslite.sh to flash CC3220SF LaunchPad as the instructions, and set CONFIG_XIP=y and CONFIG_CC3220SF_DEBUG=y in boards/arm/cc3220sf_launchxl/cc3220sf_launchxl_defconfig.

But there always has a problem that the flashed program seems not persist over subsequent reboots.

nashif commented 7 years ago

by Siwei Xu:

Gilbert Pitney , why don't use uniflash/dslite.sh programming zehpyr.bin to device via UART ? Is it any problem in zephyr.bin cased by linker script ?

nashif commented 7 years ago

by Gilbert Pitney:

Regarding CONFIG_XIP issue, I verified it still works, and provided some clues on the separate email which was started with TI.

Regarding zephyr.bin, the TI SDK builds its output file differently than Zephyr's Makefile. I'm not sure what magic is required to load a zephyr.bin file using dslilte.sh, but you can certainly load the .elf file instead.

I recommend using the zephyr.elf file.

I see Zephyr Makefile builds zephyr.bin as:

    $(OBJCOPY) -S -O binary -R .note -R .comment -R COMMON -R .eh_frame $< $@;      \

TI SDK builds a .out file, using :

LNK = "$(GCC_ARMCOMPILER)/bin/arm-none-eabi-gcc" LFLAGS = -Wl,-T,../gcc/CC3220SF_LAUNCHXL_NoRTOS.lds "-Wl,-Map,$(NAME).map" "-L$(SIMPLELINK_CC32XX_SDK_INSTALL_DIR)/source/ti/display/lib" -l:display.am4g "-L$(SIMPLELINK_CC32XX_SDK_INSTALL_DIR)/source/ti/drivers/lib" -l:drivers_cc32xx.am4g "-L$(SIMPLELINK_CC32XX_SDK_INSTALL_DIR)/source/third_party/fatfs/lib" -l:fatfs.am4g -eresetISR "-L$(SIMPLELINK_CC32XX_SDK_INSTALL_DIR)/kernel/nortos/lib" -l:nortos_cc32xx.am4g "-L$(SIMPLELINK_CC32XX_SDK_INSTALL_DIR)/source/ti/devices/cc32xx/driverlib/gcc/Release" -l:driverlib.a -march=armv7e-m -mthumb -nostartfiles -static -Wl,--gc-sections "-L$(GCC_ARMCOMPILER)/arm-none-eabi/lib/thumb/v7e-m" -lgcc -lc -lm -lnosys --specs=nano.specs

$(NAME).out: $(OBJECTS) @ echo linking... @ $(LNK) $(OBJECTS) $(LFLAGS) -o $(NAME).out

nashif commented 7 years ago

by Gilbert Pitney:

Separate email thread by reporter indicated success flashing the CC3220SF after some clarifications of instructions.

See: https://github.com/zephyrproject-rtos/zephyr/pull/1335