• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 40 subscribers
  • Views 373 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-CC3235SF: Having a rough time with LaunchXL board and loading uart2echo example.

Marc Yaxley
Expert 1105 points
Part Number: LAUNCHXL-CC3235SF
Other Parts Discussed in Thread: CC3235SF, CC2642R, SYSCONFIG

I have a stock new CC3235SF_LAUNCHXL board, jumpers in place as delivered.  I am using CCS 12.6.0.00008 on Linux OS.

I am trying to run the stock "uart2echo_CC3235SF_LAUNCHXL_tirtos7_gcc" example from the Resource Explorer.

A few questions I have on this setup, which is new to me.  I have lots of experience with same setup and the CC2642R MCU and CCS.

1) On this newer MCU I see it has an external 4MB sFLASH part and evidently it boots from that, or at least comes up and if the MCU itself

doesn't have code in the XIP FLASH it will program that from the sFLASH and then run.  I think this is correct?

2) If there is code in XIP then the boot loader skips reFLASHing the XIP and starts up directly. Correct?

3) When using CCS to debug, this is where I get foggy.  It appears I can compile and run with the the "hammer icon" which now has two

options (vs. the older MCU, just 'debug').  Now I have the choices: 1: Debug, or 2: MCU+Image, Question, is this described somewhere?

4) When I wish to debug, and click the "green bug" to build and load, it appears I don't always get the latest code I built w/changes in it, what up?

5) Very often, and more times than not, the flashing operation after a build (either 1 or 2 in the 'hammer') fail due to some new thing I"m not

familiar with, I'll put the error text here:

**** Build of configuration MCU+Image for project uart2echo_CC3235SF_LAUNCHXL_tirtos7_gcc ****

/home/marc/ti/ccs1260/ccs/utils/bin/gmake -k -j 8 all -O 
 
gmake[1]: 'uart2echo_CC3235SF_LAUNCHXL_tirtos7_gcc.out' is up to date.
Building secondary target: "syscfg/uart2echo_CC3235SF_LAUNCHXL_tirtos7_gcc.sli"
Invoking: Image Creator
"/home/marc/ti/simplelink_cc32xx_sdk_7_10_00_13/source/ti/drivers/net/imagecreator/bin/SLImageCreator" syscfg create_image --sdk_path "/home/marc/ti/simplelink_cc32xx_sdk_7_10_00_13" --json "/home/marc/workspace_v12/uart2echo_CC3235SF_LAUNCHXL_tirtos7_gcc/MCU+Image/syscfg/ti_drivers_net_wifi_config.json" --file "/home/marc/workspace_v12/uart2echo_CC3235SF_LAUNCHXL_tirtos7_gcc/MCU+Image/syscfg/uart2echo_CC3235SF_LAUNCHXL_tirtos7_gcc.sli" --mcu "/home/marc/workspace_v12/uart2echo_CC3235SF_LAUNCHXL_tirtos7_gcc/MCU+Image/uart2echo_CC3235SF_LAUNCHXL_tirtos7_gcc.bin"
INFO:root:FTDI not detected, trying XDS
INFO:slbootloader.slbootloader:Connecting to device
INFO:slbootloader.slbootloader:Power off
INFO:slbootloader.slbootloader:Set break signal
INFO:slbootloader.slbootloader:Power on
makefile:167: recipe for target 'syscfg/uart2echo_CC3235SF_LAUNCHXL_tirtos7_gcc.sli' failed
Traceback (most recent call last):
  File "<string>", line 5262, in <module>
  File "<string>", line 5258, in main
  File "<string>", line 5228, in cmdline
  File "<string>", line 4653, in command_sysconfig_create_image
  File "<string>", line 2498, in create_image_from_sysconfig
  File "<string>", line 1567, in connect_device
  File "/home/user/Downloads/sl_image_creator_gen3/slbootloader/slbootloader.py", line 409, in connect_with_reset
  File "/home/user/Downloads/sl_image_creator_gen3/slbootloader/slbootloader.py", line 271, in _expect_ack
  File "/home/user/Downloads/sl_image_creator_gen3/slbootloader/slbootloader.py", line 300, in _read_data
  File "/home/user/Downloads/sl_image_creator_gen3/venv_ic/lib/python2.7/site-packages/serial/serialposix.py", line 475, in read
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
SLImageCreator returned -1
gmake[1]: *** [syscfg/uart2echo_CC3235SF_LAUNCHXL_tirtos7_gcc.sli] Error 255
gmake[1]: Target 'secondary-outputs' not remade because of errors.
gmake: *** [all] Error 2
makefile:149: recipe for target 'all' failed

**** Build Finished ****

I have been hung up on this and not found clear documentation on what is attempting to occur to program the part.  It usually takes pressing the

reset button on the LaunchXL that is right next to the USB connector or/and unplug the USB and plug back in to get the thing to work again!

I have scanned dozens of pages of Forum posts for similar symptoms and there are a few but none related to using a stock LaunchXL and MCU

setup to simply run the examples and demos TI provides.  I did run the 'out of box' WIFi and that worked but also suffers from the same FLASH

loading problems but did load and run ok a few times (could access via. a browser from my PC, etc.).

I'd love to entertain any tips and tricks or help TI has on getting this to be reliable as I have to do some benchmark tests on the MCU as it does

not have a FPU vs. the older MCU which did.  Evaluate how much slower it will be with out the FPU to do calculations,etc..

Cheers, Marc

  • +1
    Expert 1105 points

    On #5 in my post, I moved to a Windows computer and installed and it works way better than on the Linux PC.  Since it works better I am able

    to see what is going on to load/debug code.  Sort of tough when hardware is new, and IDE does new things to know what is working and if

    it isn't working what could be an issue.  So there appears to be issues with Linux Mind and that image creator downloaded utility as I see it?

    The LaunchXL JTAG part works and tests ok in the 'verify' button in project settings, just craps out on various tasks randomly?

    Any one else have Linux issues? 

    Another ugly thing is the serial port to print through appears as various "/tty/ACMx" ports, always different which is a hassle for sure!.

  • +1 in reply to Marc Yaxley
    TI__Guru 63006 points

    1. basically you are right. It will also check if there is a difference between the XiP Flash image and the content of the external flash and will reprogram the XiP flash in case of differences (which is useful for OTA update).

    2. if the XiP image is the same as the one in the external flash.

    3. "Debug" will just build the ".out" in debug mode which will allow the CCS Debugger to download (through jtag directly to the XIP flash) and execute it (note upon MCU reset the bootloader will overwrite this with a content from the external flash if such exists). 

    The " MCU+Image" will convert the ".out" file to binary (.sli) that you will be able to  flash to the external flash (see the "flash" button - typically to the left of the "hammer icon"). In order to use the SLI for development - it needs to include a specific MAC address in side which it tries to read from a connected device. This is the reason for the failure you see (in 5). You need that the device will be connected and that the COM Port will be available. You can the "image.syscfg" to configure the content of the SLI file - e.g. adding certificate/user files and updating the service pack or certificate catalog. For more details refer to "<SDK>/docs/simplelink_mcu_sdk/sysconfig_imagecreator.html"

    4.  not sure. i'm not aware of such issue.

    5. see (3).

  • 0 in reply to Kobi Leibovitch
    Expert 1105 points

    Ok, thanks Kobi for the confirmation and hints as to how this works.  Seems each new technology

    MCU has it's own new doings that initially confuse one if one is used to the 'old ways'...

    So:

    On #1, then I have that correct and understood.

    On #2, the sFlash will be copied on boot to the XIP if they differ.

    On #3, debugging will flash the XIP for that session until reboot when it reverts to what

                      what is in the sFlash since they will differ. That really 'got me' for hours.

    On #4, the comments in #3 help, I was confused to run some debug on a build then reboot and

                      see the old code that was in the sFlash come up again...dang....

    On #5, having now tested the same setup under Windoze 10 and it works way better so I would

                      assume there is some Linux OS issue with the USB and it's use as two functions

                      (IDE-JTAG and SerialPort) under Linux as it get confounded and needs a full power cycle

                      to get working again.  Not sure if this is my Linux Mint 21.0 problem or all Linux OS that

                      are out there.   As Kobi says there might be a MAC address issue, right now I don't really

                      want the WiFi stuff in my test shell.  I see most or all of the examples have WiFi code.

                      However, the exact same setup/use I moved over to Win10 works fine with what ever

                      MAC issue might be there?  Will deal with  this later I guess when I get on to the WiFi

                      part of the application.

    I'm running with W10 so I can do my benchmarks today.  I am working fine under Linux with the

    same CCS version but with the CC2642R MCU and it's SDK, working well for a couple of years.

    So at some point I either stay with Windoze 10 or figure out the debugger probe issue in Linux.

    Experience is always from the past and hard earned, but is the ultimate knowledge!

    Again, thanks for the helping hints and comments!

    Marc

  • +1 in reply to Marc Yaxley
    TI__Guru 63006 points

    If you are still facing the Linux issue , please provide more details (or even open a new thread).

    I'm typically working with Windows and I'm not aware of a known Linux issue. 

    We'll need to take it with our tools team.

  • 0 in reply to Kobi Leibovitch
    Expert 1105 points

    Will do when I start the actual project next month, can't stand Windoze at all...so getting the new

    MCU debug setup working on Linux is a must have for me...

    Thanks, Marc