RTOS/EK-TM4C129EXL: How to re-activate a (previously-activated) Crypto Connected Launchpad on exosite?

Hello LouEEEE,

The "Readme.txt" file (that is part of the secure_iot project) says the following. Have you followed this step?

Thanks,

Sai

Sai,

Again, thanks for your quick response. I am well beyond all that, though...

Key part of my message was the 're-' bit. I've long since created an account and registered the device. Out-of-Box, it all worked...

I have since deleted the device, recreated it, and would now like to re-activate it using its new CIK (per my message above).

Can't find any clear help on the exosite, other than the missive: 'Please activate your device or confirm the device RID and try again'

I can't find any place to enter the device's CID, for example - while the device EEPROM CID is clearly displayed in the debugger - and it's obvious this doesn't match the new CID exosite has now assigned to the device.

Ideas?

Hello LouEEEE,

Can you see the MAC address of the board (that is running the secure_iot application) under "Devices"?

If yes then click on the device and "Re-Enable" it (follow instructions under "Re-Enable Device"). The CIK value will change. Now restart the board or alternatively run the "activate" command from the command line. The board should automatically detect that the CIK has changed and acquire the new CIK. Note: If the CIK was acquired once then Exosite will reject subsequent requests to acquire the CIK, unless the CIK has changed.

If no, then add the device and restart the board.

Thanks,
Sai

Have repeated the Re-Enable/Restart or Reset cycle several times already - no joy!

Have also tried cold reboot of the board, as well as reset.

Board does connect:

Connected to Exosite server.
CIK found in EEPROM 51a681cf7f3d2478fe21159e4e16d98539a8a8a7
CloudTask: Bad response, ecode: -103,  socket error: 0 during : 2 action.
Resetting connection.
Failed to resolve host name. Check proxy server settings. Ecode: -106.
CloudTask: Bad response, ecode: -103,  socket error: 0 during : 4 action.
Resetting connection.

Again, there is no proxy in the mix, and the board has already verified NTP time by this point.

> activate command appears to do nothing; just 'hangs'.

Which of the sample programs illustrates EEPROM write? Maybe it's time to just try changing CID manually on the board?

Hello LouEEEE,

The error code "-103" implies that the HTTPClient module of TI-RTOS was unable to send to the remote host. This error means that no HTTP request was sent to the Exosite server. That is really surprising especially since you said that the application worked for you after rebuilding the first time.

Could you try to change "BIOS.heapSize" to "80920" in "secure_iot.cfg" file and try? Maybe the newer TI-RTOS requires more heap size than before.

Thanks,
Sai

Yes, this is interesting. With: BIOS.heapsize = 70920

Using MAC address in flash
Starting BIOS
Service Status: DHCPC    : Enabled  :          : 000
Service Status: DHCPC    : Enabled  : Running  : 000

	Welcome to the Crypto Connected LaunchPad's,
		Secure Internet of Things Demo.

MAC Address: <Correct MAC address>
Network Added: If-1:10.0.0.107
Service Status: DHCPC    : Enabled  : Running  : 017
Resolving IP address of time.nist.gov...
NTP IP resolved to 216.229.0.179
Connecting to NTP server
Current Date/Time is Thu May 18 19:38:11 2017

Connecting to server...
Connected to Exosite server.
CIK found in EEPROM 51a681cf7f3d247...<etc>
ti.sysbios.heaps.HeapMem: line 361: out of memory: handle=0x2001e16c, size=1664
CloudTask: Bad response, ecode: -103,  socket error: -353 during : 2 action.
    Resetting connection.
Connecting to server...
Connected to Exosite server.
CIK found in EEPROM 51a681cf7f3d247...<etc>
CloudTask: Bad response, ecode: -103,  socket error: 0 during : 2 action.
    Resetting connection.
Connecting to server...
Connected to Exosite server.
CIK found in EEPROM 51a681cf7f3d247...<etc>
CloudTask: Bad response, ecode: -103,  socket error: 0 during : 2 action.
    Resetting connection.
Connecting to server...
Connected to Exosite server.
CIK found in EEPROM 51a681cf7f3d247...<etc>
CloudTask: Bad response, ecode: -103,  socket error: 0 during : 2 action.
    Resetting connection.
Connecting to server...
 ----- repeats a couple of times -----
    Resetting connection.
00013.644 getaddrinfo: Error: couldn't resolve host name "m2.exosite.com"

Failed to resolve host name. Check proxy server settings. Ecode: -106.
CloudTask: Bad response, ecode: -103,  socket error: 0 during : 4 action.
    Resetting connection.
Connecting to server...
Connected to Exosite server.

However, with BIOS.heapsize = 80920

Using MAC address in flash
Starting BIOS
Service Status: DHCPC    : Enabled  :          : 000
Service Status: DHCPC    : Enabled  : Running  : 000

	Welcome to the Crypto Connected LaunchPad's,
		Secure Internet of Things Demo.

MAC Address: <correct MAC address>
Network Added: If-1:10.0.0.107
Service Status: DHCPC    : Enabled  : Running  : 017
Resolving IP address of time.nist.gov...
NTP IP resolved to 216.229.0.179
Connecting to NTP server..........
Failed to Sync time with NTP server after 10 seconds
-- and then nothing more ---

( this is output from the Stellaris in-circuit debugger - which they've clearly named after you! )

LouEEEE,

LouEEEE! said:

ti.sysbios.heaps.HeapMem: line 361: out of memory: handle=0x2001e16c, size=1664

Clearly heap size of 70920 is not sufficient. The increased heap size should give you better result.

I have never seen a scenario when the NTP server did not sync time after connecting. For now please try to re-run the code and see if you go past this NTP server not syncing.

LouEEEE! said:

( this is output from the Stellaris in-circuit debugger - which they've clearly named after you! )

Or the other way around :)

Thanks,

Sai

Sai,

It's getting better. with BIOS.heapsize - 80920 ( and after several cold reboots/resets/rebuilds, etc. ), card is running and connecting to exosite:

Connecting to server...
Connected to Exosite server.
CIK found in EEPROM c67f36be65f07688...<etc>

Still things are not quite right, though. LED D1 doesn't behave properly. Interface reports device 'Failed to update'. ( and LED status doesn't change. )

Debug interface also ends at CIK found in EEPROM; no output after that. ( Will have to check code to know if this is normal 'endpoint'? )

LouEEEE,

The CIK looks different. Can you check if this CIK matches the one that is assigned by the Exosite portal? You can look at the CIK assigned by Exosite using the following steps

• Log into ti.exosite.com
• Click on "Devices" section on the left side of the screen
• Click on the device being used. This opens a new window that should have the CIK (in fine print).

LouEEEE! said:

Debug interface also ends at CIK found in EEPROM; no output after that. ( Will have to check code to know if this is normal 'endpoint'?

After the CIK information:

• Nothing prints on the terminal unless there is an error.
• LED D2 blinks continuously as long as the board is communicating with the Exosite server.

LouEEEE! said:

Still things are not quite right, though. LED D1 doesn't behave properly. Interface reports device 'Failed to update'. ( and LED status doesn't change. )

If LED D2 is blinking continuously, you should be able to control LED D1 from the dashboard on the Exosite server.

Thanks,

sai

Hello Sai,

 

Stellaris Sai said:

The CIK looks different. Can you check if this CIK matches the one that is assigned by the Exosite portal?

No, CIK is perfect - EEPROM CIK a match for the stored CIK on exosite. CIK is not the problem here.

With BIOS.heapSize = 80920, board has been running successfully, connected to exosite since our last communication. I am concerned that this seems to be a surprise fix, or a kludge.

Stellaris Sai said:

If LED D2 is blinking continuously, you should be able to control LED D1 from the dashboard on the Exosite server.

LED D2 is blinking continuously; yes, board is communicating with exosite. It's sending Junction Temperature continuously. ( D3 also blinking; indicates 'traffic'? )

But things are definitely still not right.

LED D1 or Alert Email result in "Failed to update. Please check your device status or try again." - with no result on the board.

One thing I'd like to try?: I'd like to bring xdctools-(latest) into the mix here. How to change XDC_CG_ROOT in the project's Linked Resources. It's un-editable in CCSv7 interface.

I'm just not feeling confident about the food chain here.

Goal was to begin the real work we had in mind - our own code - for the TM4C129 family by now, not to be struggling with what should be the simplest one-hour exercise of the Out-of-Box demo.

Hello Sai,

And thanks again for your help on this...

As I've mentioned elsewhere, your suggestion to increase BIOS.heapSize = 80920 works, at least in terms of successful build and connect to exosite.

However, there remain issues ( in the http communication? ) with the exosite dashboard interface. Neither the LED D1 toggle nor the Alert Email can be modified from the dashboard.

I'd love to have a solid code baseline upon which to build.

Hello LouEEEE,

Sorry for the delay in getting back. I was trying to recreate the issue that you are facing. The following is what I had tried:

• Download Secure IoT Demo from:
• Download the patch file from:
• Extract the content of the patch file into the "Secure IoT Demo" installation folder.
• Follow the instructions in "PatchReadme.txt" (included with the patch) to apply the patch.
• Follow the instructions in "Readme.txt" (in the "secure_iot" folder) to set-up the various tools, build the secure_iot demo project and run it.

The following are the packages that I used:

• TI-RTOS v 2.16.01.14
• wolfSSL v3.10.2
• CCS v7.1.0
• XDCTools 3.32.01.22

With the above mentioned packages, I did not face any issues. I did not have to increase BIOS.heapSize either.

When I used the XDCTools v3.50.01.12, I faced some of the issues that you had mentioned. The following are the different combinations I tired with this package:

Used XDCTools v3.50.01.12 to build wolfSSL libraries and "secure_iot" application.

• wolfSSL libraries build without any errors or warnings.
• secure_iot application does not build.

Used XDCTools v3.50.01.12 to build wolfSSL libraries and XDCTools 3.32.01.22 to build "secure_iot" application.

• wolfSSL libraries build without any errors or warnings.
• secure_iot application build without any errors or warnings.
• When secure_iot application is executed, the execution stops with hardware exception fault, which based on the error looks like is due to heap issue.
• When I increase the heap size, I still get the same error.

Used XDCTools 3.32.01.22 to build wolfSSL libraries and "secure_iot" application.

• wolfSSL libraries build without any errors or warnings.
• secure_iot application build without any errors or warnings.
• When secure_iot application is executed it makes connection to the cloud server, led D2 blinks every second, led D1 can be controlled from the Exosite Portal (at ti.exosite.com), able to send alert messages.
• Ran this test for about 3 hours without any problem.

Based on the above results, it looks like the XDCTools v3.50.01.12 is not compatible with "secure_iot" application. Until I find out what the exact problem with XDCTools v3.50.01.12 is, please refrain from using it, even to build the wolfSSL libraries.

If you have used XDCTools v3.50.01.12 to build wolfSSL Libraries, can you please clean-up the build and use XDCTools 3.32.01.22. Also in the project settings of "secure_iot", please select the same XDCTools version (3.32.01.22).

To modify the XDCTools version in the project, click on "Project->Properties" menu to open the "Properties" window for "secure_iot" demo. Then click on "General"  section on the left of this window and click on the "RTSC" tab as shown in the image below.

Thanks,

Sai

Edit: Forgot to mention that I was behind a proxy server when I ran the tests, but I don't anticipate this to cause any major difference in behavior.

Sai,

Again, tks for your reply.

First, a couple of things jump out:

( First, all this on macOS 10.12.4 )

Code Composer Studio Version: 7.1.0.00016

XDCtools 3.32.0.06*  -- different to yours

TI-RTOS 2.16.08  -- different to yours.

TM4C ARM Cortex-M4F MCU  2.13.156

WolfSSL 3.8.0 ( built cleanly against above XDCtools )  -- different to yours!

I will reproduce my steps ( then try to synchronize with versions you're using ) and get back to you shortly on this...

*If I recall correctly, I believe I was not able to build with any newer version of XDCtools. Will backtrack, and verify.

No Proxy Server, but EK-TM4C129EXL is chatting via a DHCP-offering AP behind our firewall.

To be clear about run vs. build: I'm sure I ran the original firmware, as shipped on the board, without issue. I'm not so sure we were able to build it ground up, however ( weeks ago, apologies... )

Hello LouEEEE,

We have never tested this application on a non-windows environment. CCS and XDS-Tools are built to work on MAC OSx but TI-RTOS releases this support as beta. Wondering if that could be a problem.

Not sure what you mean by "TM4C ARM Cortex-M4F MCU 2.13.156". You should not be using any other package.

I have tested this application on the TI-RTOS, XDCTOOLS and WolfSSL versions that you have mentioned before on CCS v6.1.2 and don't anticipate it to be an issue with CCS v7.

As long as XDCTools v3.50.xx is not used, I don't think there is a problem with using the version of the tools that you have mentioned.

The installation of the "Secure IoT" application comes with the binary file in the folder <Secure Iot installation>/ek-tm4c129exl/secure_iot/Debug. You could use this binary to test if your set-up is working fine.

Thanks,
Sai

Sai, Thanks for sticking with this - it's getting even more interesting.

Quick summary: Seeing the same ( erroneous ) behavior in our environment with either our own builds OR the pre-packaged spmc022-1.0.0.7/Debug/secure_iot.bin.

STEP 1, overview of steps to reproduce your test harness...

Built WolfSSL-3.10.2 - PERFECT!:

# ======== products.mak ========

XDC_INSTALL_DIR = /Applications/ti/xdctools_3_32_01_22_core
BIOS_INSTALL_DIR = /Applications/ti/tirtos_tivac_2_16_01_14/products/bios_6_45_02_31
NDK_INSTALL_DIR = /Applications/ti/tirtos_tivac_2_16_01_14/products/ndk_2_25_00_09
TIVAWARE_INSTALL_DIR = /Applications/ti/tirtos_tivac_2_16_01_14/products/TivaWare_C_Series-2.1.1.71b

ti.targets.arm.elf.M4F = /Applications/ti/ccsv7/tools/compiler/ti-cgt-arm_17.3.0.STS
iar.targets.arm.M4F =
gnu.targets.arm.M4F = /Applications/ti/ccsv7/tools/compiler/gcc-arm-none-eabi-4_9-2015q3

export XDCTOOLS_JAVA_HOME = /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home

#=============================

CCSv7 Settings:

CCS General/RTSC/XDCTools version: 3.32.1.22_core - OK
ARM Compiler/Include Options: /Users/drlou/ti/wolfssl-3.10.2/tirtos
ARM Linker/File Search Path/
...path-to-wolfssl-3.10.2/.../wolfssl_tm4c_hw.aem4f
...path-to-TivaWare_C_Series-2.1.1.71b...ccs/Debug/driverlib.lib
...path-to-TivaWare_C_Series-2.1.1.71b...ccs/Debug/usblib.lib
C/C++ General/Paths and Symbols/Assembly/Includes:
/Applications/ti/xdctools_3_32_01_22_core/packages

SAME RESULT with either:
secure_iot.cfg:BIOS.heapSize = 70920 -- OR -- 80920;

COMPILER TESTING:
TI v17.0.1.LTS
Occasional: Failed to connect to server, ecode: -102.
- some timeouts, but always connects.

Same findings - if somewhat variable connection behavior - on older compilers:

TI v16.9.3.LTS
TI v16.9.1.LTS

ERRORS: In ALL cases, neither LED D1 toggle nor Alert eMail entry capability.

STEP 2: Direct upload of spmc022-1.0.0.7/Debug/secure_iot.bin using UniFlash

SAME findings!

Do you know if an earlier version of this firmware is available - perhaps our test board was shipped with a spmc022-1.0.0.0 version of the binary? - Do you know where I might get it? I'm now curious to test with this earlier version of the bin, if it's still available...

Our network? EK-TM4C129EXL is connected to an access point on its own subnet. Given our security setup, I cannot get closer to the firewall. We do not have any Proxy Server in play here.

Nonetheless, I'm quite sure the demo ran as shipped on the EK. I remember we were able to set the LED D1, for example.

Hello LouEEEE,

That is very strange. I just programmed an EK-TM4C129EXL Launchpad with the pre-packaged binary for Secure IoT Demo Version 1.0.0.7 (./ti/ek-tm4c129exl/secure_iot/Debug/secure_iot.out) using Uniflash version 3.4.1.00012. the application works as expected, can control LedD1 from the browser and send alert emails.

Could this be a board problem - never seen such an issue? Do you have a second Launchpad to try this on? The pre-packaged binary (Secure IoT Demo v 1.0.0.7) should work without any problem.

Getting the pre-packaged binary to work should be the priority.

Thanks,
Sai

Stellaris Sai said:

The pre-packaged binary (Secure IoT Demo v 1.0.0.7) should work without any problem.

Indeed it should. Could not agree with you more...

Have uploaded ...ek-tm4c129exl/Debug/secure_iot.bin ( I assume you meant 'bin'? ) from a freshly-decompressed copy of demo 1.0.0.7 several times now. Behavior is the same...

Card connects, sends Junction Temperature to web interface.

But LED D1 and Alert Email do not respond.

Stellaris Sai said:

Could this be a board problem - never seen such an issue? Do you have a second Launchpad to try this on?

I do not have a second Launchpad to try this on. Prospect of a defect seems weird, especially as the board performed well out-of-the-box. I am reliant on normally very high TI Quality Control ! Network config has also remained consistent since that first test.

( Do we have to purchase/wait for another card just to test this code? )

Does below all seem consistent with bin you are using?

secure_iot.bin: 188,120 bytes
$ openssl md5 secure_iot.bin
MD5(secure_iot.bin)= 78c7f45f5e3e4986b5a1f3cb935ce3d0

UniFlash 4.1.1.450 (macOS)

secure_iot.bin is verified by UniFlash before upload to card.

Is there a backchannel mechanism by which you can send me the exact bin you are testing with?

Good grief - what a story... (exhausts just sitting/reading)

While the (claimed) forum "upgrade?" bans - it must be noted: "Stellaris SAI" (so musical/distinctive) "TEN LIKEs." Lou "2.5 LIKEs" for the follow up... Exosite (based upon hearsay - as here reported) - "TEN DISLIKES" (although their commentary IS invited.)

Might it prove wise - before "sampling this Kool-Aid" - to express (some) curiousity as to why such difficutly, " appears uniquely presented" - and "not" more "universal?"    (as the "issue" would appear to plague many - and has been "rarely" noted & reported!)        Such is (likely) confirmed by this long - yet "two poster only" thread!      (when the "multitudes of similarly suffering others" would feel compelled to "chime in" - yet (all) remained (strangely) silent...)