v1.1.0

Note: Due to a bug in the LWM2M operation in this version of firmware, all devices should be immediately updated to the newest available version. Any users of previous firmware can skip this version and move directly to a newer one.

New Hardware

This version provides compatibility with the new nRF9160 hardware revision. The Skywire Nano devices will begin using the new hardware with the -C variant from NimbeLink.

This version retains backwards compatibility with existing -B Skywire Nano hardware.

Non-Secure Callable ABI Change

There was a one-time move of the Non-Secure Callable APIs from their previous flash locations to a new, final RAM location. This will require a one-time recompilation of Non-Secure applications. There are no additional plans to move the Non-Secure Callable APIs in the future.

The previous stack firmware ABI can still be used with the new "legacy" Nano board in the NimbeLink SDK. This will require stack firmware version v1.0.1 or older, and will not be available in the new -C hardware variant.

Non-Secure Firmware Resources

Non-Secure firmware gets an additional 16K of RAM, going from 64K to 80K.

Fixes/Changes from v1.0.1

General Usage

Kernel logging of AT%CMNG will now hide the command's arguments and responses
LWM2M now includes an LTE_READY event that will indicate the network connection is ready to be used by the application without the risk of being disconnected by LWM2M
A failure to parse an AT command will now result in NOT_FOUND instead of the previous INCORRECT_PARAMTERS
Modem firmware DFU operations can now be performed more readily than before

Previously, a Skywire Nano would need to have its LWM2M module reach either the DEFERRED or READY states before a modem DFU could be performed. With this update, the modem DFU can generally be performed at any time, given the availability of any necessary network or UART resources to perform the DFU. The exception would be if the LWM2M is currently performing a modem DFU operation.
Kernel logging has been improved and now includes module color coding in addition to color coding the log level
Fixed potentially leaving firmware updates in swap partition when image's dependencies aren't met

AT Commands

Changed AT command handling to use a more standard approach to line endings, with \r being the only character that is considered when entering a command and \r being echoed, when echo is on. Previously, we would only echo a single \r character and we would also eat a \n character if it was entered just after the \r.

Previously, this is how a command would have been handled with echoing on:
```
Send:       AT\r
Receive:    AT\r\n
            OK\r\n

Send:       AT\r\n
Receive:    AT\r\n
            OK\r\n
```
And, with echoing off:
```
Send:       AT\r
Receive:    OK\r\n

Send:       AT\r\n
Receive:    OK\r\n
```
Now, the \n will not be considered as part of the command being entered, and the \r in the original command will be echoed (when on) in addition to the \r\n shown after the command is run.

Now, with echoing on:
```
Send:       AT\r
Receive:    AT\r\r\n
            OK\r\n

Send:       AT\r\n
Receive:    AT\r\r\n
            OK\r\n
            \n
```
And, with echoing off:
```
Send:       AT\r
Receive:    OK\r\n

Send:       AT\r\n
Receive:    OK\r\n
```
Notice that, with echoing on, the additional \n character will be handled and echoed after the command is handled. Thus, the \n is treated like any other additional input characters.
Fixed echoing AT command prompt input data when echo is disabled
Fixed swallowing a \n character as the first byte in a dynamic payload

For example:
```
AT#XTCPSEND=1\r
\n<data>^Z
```
Previously, the \n would have been considered as a \r\n for entering the AT command and not included as a part of <data>.
Addressed issues with sending binary data in AT#XTCPSEND and AT#XUDPSENDTO
Bumped maximum AT command parameter count to 10
Fixed missing quotation marks in test output for AT#XMQTTCONN, AT#XMQTTSUB, and AT#XMQTTPUB
Fixed not displaying AT+CMGS reference value and RP-ACK PDU
AT#LWM2M no longer has the ability to manually set the Verizon URI
AT#XFOTA will return TEXT_STRING_TOO_LONG for host+file strings that are too large
The AT interface UART can now be disabled using AT#UART=1,0

This will allow both the kernel logging and AT interface UARTs to simultaneously be turned off. Each can be resumed by sending a character to the UART. The kernel logging UART does not process input, and will simply resume transmitting logging as before. The AT interface will return an "OK" indication when it resumes operation.

Asynchronous URCs on the AT interface will result in the UART being temporarily turned on to send the URC and then being turned back off.
AT#DEBUGLOCK? can now be used to check if the Non-Secure debug lock has been set
Updated GPS URCs to be less human-readable and to more easily identify date/time URCs

Previously, some GPS URCs were formatted to have units for each field in the URC itself, whereas now they can be referenced using the documentation. Additionally, special parsing was needed to differentiate some URCs, whereas now the satellite status and date/time URCs have prefixes identifying them:
```
#GPS: tracking <x> using <y> unhealthy <z>  ->      #GPS: SAT,<x>,<y>,<z>
#GPS: <date> <time>                         ->      #GPS: TIME,<date> <time>
#GPS: TTFF <t> sec                          ->      #GPS: TTFF,<t>
```

Known Issues

Using a hostname for a TLS secure socket will result in a memory leak in the Nordic co-processor firmware, resulting in a likely system hang after ~22 iterations of socket opening, connecting, and closing. The TLS credentials ("tags") can still be used.
".noinit" linker sections for RAM will not work properly in application firmware
The MQTT client in the AT interface firmware does not support hostname verification
No DFU URC is generated when stopping using either AT#XFOTA=0 or AT#FWUPD=0
The AT%XMAGPIO set command does not work and returns an error
In certain circumstances, the LWM2M operation can get into a looping mode where it issues AT+CFUN=4 and then AT+CFUN=1 rapidly and continuously. This stems from a pre-shared key being erronously deleted. This issue has been fixed in all newer versions of firmware. There is a section about correcting a device in this mode in our Troubleshooting Guide.