Mbed OS cellular connectivity #6082

AriParkkila · 2018-02-13T12:52:18Z

Description

First implementation for Mbed OS cellular connectivity in the folder mbed-os/features/cellular

easy_cellular : simplified usage based on CellularBase.h

framework :
    API             Application Programming Interface for Cellular
    AT              AT implementation based on 3GPP TS 27.007 specification
    common    Common and utility sources
    mux           MUX implementation based on 3GPP TS 27.010 specification
    targets       Vendor specific cellular module adaptations

Status

READY

Migrations

NO

Related PRs

NO

0xc0170 · 2018-02-13T13:20:22Z

Please look at jenkins CI failure, compiler error related. Also travis docs failed

0xc0170 · 2018-02-13T13:21:12Z

features/cellular/.gitignore

@@ -0,0 +1,13 @@
+coverage/


isn't this covered in root gitignore? thus this file could be removed?

FIle can't be removed because of unit tests. That one line can be removed.

0xc0170 · 2018-02-13T13:23:16Z

features/cellular/UNITTESTS/at/at_cellularinformation/test_at_cellularinformation.cpp

+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+#include "CppUTest/TestHarness.h"


is there a documentation how to run these tests (where cpputest icomes from, etc)?

Not yet. There is ongoing discussion around unittesting in general. CppUTest is one of the options, but we might switch to something else as well. When we have decided the mbed OS wide unittest tool, we need to document that for the whole mbed OS, not just for Cellular. There is a run_tests script in UNITTESTS folder and I think it is quite self-explanatory. Do you think we should add "readme" or similar under UNITTESTS folder?

just want to understand why UNITTEST folder is also part of this PR . If it is added, then it needs to be documented how it is used, otherwise it can ber considered "dead" code - why it is here then?

Product decision. README.md updated with instructions

0xc0170 · 2018-02-13T13:31:47Z

features/cellular/easy_cellular/CellularConnectionUtil.h

+
+#include <UARTSerial.h>
+#include <NetworkInterface.h>
+#include <EventQueue.h>


why are <> used here (how are they different from line 25/26)

Fixed to double quotations. Brackets now used only for headers that come from toolchain.
AriParkkila@85f05f4

0xc0170 · 2018-02-13T13:33:06Z

features/cellular/easy_cellular/CellularConnectionUtil.cpp

+#define MBED_TRACE_MAX_LEVEL TRACE_LEVEL_INFO
+#endif
+#include "CellularLog.h"
+/*#define log_debug printf


Removed dead code.

0xc0170 · 2018-02-13T13:54:37Z

features/cellular/framework/API/CellularNetwork.h

+
+    /* PDP Context information */
+    struct pdpcontext_params_t {
+        char apn[100+1];


are these numbers defined anywhere (100 and 63) ?

3gpp defines lengths, added defines

0xc0170 · 2018-02-13T13:59:31Z

features/cellular/framework/AT/AT_CellularSMS.h

+//     *
+//     *  @return              zero for success
+//     */
+//    nsapi_error_t set_csms(int msg_service);


0xc0170 · 2018-02-13T14:42:34Z

features/cellular/framework/common/CellularTargets.h

+
+namespace mbed {
+
+#define UART 1


very short names that might conflict with targets (UART or MUX). what is the use of these?

Not used --> removed

kjbracey · 2018-02-14T07:39:55Z

features/cellular/framework/AT/AT_CellularStack.cpp

+    if (socket->localAddress.get_port() == 0) {
+        socket->localAddress.set_port(get_dynamic_ip_port());
+    }
+


bind() can independently set local port and local address. If either are zero, that's a no-op for that field. This should be more like "if address is non-zero, set address; if port is non-zero, set port". A call with port 0 shouldn't affect any already-chosen port.

kjbracey · 2018-02-14T07:48:31Z

features/cellular/framework/AT/AT_CellularStack.cpp

+    if (!socket) {
+        return NSAPI_ERROR_DEVICE_ERROR;
+    }
+    socket->localAddress = addr;


bind() sets address and port independently. If they're zero it's a no-op. This should be "if address is non-zero, set address; if port is non-zero, set port". If they're zero, don't change what's already been set.

Mirela fixed this : 5e04288

kjbracey · 2018-02-14T07:52:54Z

features/cellular/framework/targets/QUECTEL/BC95/QUECTEL_BC95_CellularStack.cpp

+    nsapi_size_or_error_t recv_len=0;
+    int port;
+    char ip_address[NSAPI_IP_SIZE];
+    char hexstr[BC95_MAX_PACKET_SIZE*2 + 1] = {0};


You're wasting a lot of CPU time setting this temporary array to zero.

kjbracey · 2018-02-14T08:36:57Z

features/cellular/framework/AT/ATHandler.cpp

+           return;
+       }
+#ifdef MBED_CONF_RTOS_PRESENT
+        rtos::Thread::yield();


Yield doesn't really achieve very much - you're still using 100% of CPU power and it won't let lower-priority threads run. You should use a timed poll() similar to the existing ATCmdParser or the PPP glue code.

internal ticket created: IOTCELL-556

kjbracey · 2018-02-14T08:37:33Z

features/cellular/framework/AT/ATHandler.cpp

+void ATHandler::reset_buffer()
+{
+    log_debug("%s", __func__);
+    memset(_recv_buff, 0, sizeof(_recv_buff));


Waste of CPU time/power? No need to set unused buffer space to anything.

kjbracey · 2018-02-14T09:03:48Z

features/cellular/framework/AT/AT_CellularNetwork.cpp

+
+nsapi_error_t AT_CellularNetwork::set_registration_urc(bool urc_on)
+{
+    RegistrationType reg_types[] = {C_EREG,        C_GREG,       C_REG};


These should be a bit more const, and possibly static - const RegistrationType & const char * const cmd_on

Added static const, commit
AriParkkila@9ec4cb8

kjbracey · 2018-02-14T09:04:05Z

features/cellular/framework/AT/AT_CellularNetwork.cpp

+    return _at.get_last_error();
+}
+
+nsapi_error_t AT_CellularNetwork::set_registration(char *plmn)


AriParkkila@5d47ac6

kjbracey · 2018-02-14T09:17:39Z

features/cellular/framework/mux/cellular_mux.h

+    virtual off_t seek(off_t offset, int whence = SEEK_SET);
+
+    /** Not supported by the implementation. */
+    virtual int close();


Even if this internal file handle doesn't support blocking, it still should support poll() so that readable and writable work.

Managed by IOTCELL-571

kjbracey · 2018-02-14T09:18:46Z

features/cellular/framework/mux/cellular_mux.cpp

+                       action was taken. */
+
+                    tx_callback_pending_bit_set(dlci_id);
+                    write_ret = 0;


-EAGAIN is the correct return value for "I'm not sending anything because buffers full". Write never normally returns 0 unless asked to send 0.

Managed by IOTCELL-567

kjbracey · 2018-02-14T09:26:53Z

features/cellular/framework/mux/cellular_mux.cpp

+
+ssize_t Mux::user_data_tx(uint8_t dlci_id, const void* buffer, size_t size)
+{
+    MBED_ASSERT(size <=


You seem to be providing the basic "unstructured octect stream" convergance layer, which means you should be acting as a stream file handle. You must accept any size here.

If we accept the non-blocking limitation (which will work with PPP and the AT Parser), I believe that means you just need to limit the size to your maximum, and return how much you actually managed to fit in 1 frame. Any user that knows they're using a non-blocking FileHandle will cope with that.

For blocking (eg if you just want to printf from the C library over the mux), you would need to construct a loop to write however many frames are necessary.

I would say blocking really must be implemented if this is to be generally useful, but that can wait until later. You do need to make sure poll() works though. Is the lack of poll why the ATHandler is spinning?

IOTCELL-566 created for possible future implementation change regarding this feedback.

Blocking mode is not supported by the current implementation and for my knowledge no plans to implement that in the future.

Regarding "ATHandler is spinning" feedback: Propably managed by IOTCELL-556: added comment there for tracking

The poll() functionality and write size functionality are clearly broken and not acceptable for merging to master as-is. This mux has one job to do, and that's to present itself as a functioning virtual serial port.

The limitation on no blocking support is something that could be documented, but the non-blocking support has to actually work correctly.

How does this even work with PPP as it is? I guess it doesn't?

On future blocking support, I think it would make sense to introduce some sort of "make blocking from non-blocking" helper to avoid having to implement extra logic for blocking in every non-blocking-capable FileHandle provider.

That's the way sockets work, and it's super convenient - you can just keep returning -EAGAIN and not worry whether it's blocking mode or not. FileHandle just lacks that because it historically was always blocking-only and non-blocking was bolted on as an extension afterwards.

I'll look into what this would look like. It would be continuing work from the "poll wake" stuff here: https://github.com/kjbracey-arm/mbed-os/commits/cv_cs

We have created JIRA tasks for future improvements and no implementation changes are planned at this point.

Do you consider that these are blocking the PR merge at this point?

Yes. See my comment below.

Fixed with commits:
1245c14
ee5d27f

kjbracey · 2018-02-14T09:36:33Z

features/cellular/framework/common/CellularLog.cpp

+
+void log_init(PinName tx, PinName rx, int baud)
+{
+#ifdef FEATURE_COMMON_PAL


I think I would just turn on FEATURE_COMMON_PAL, if you want to use mbed-trace. Any reason why not? (Anyone?)

mbed_trace was taken into use in cellular AriParkkila@5c8a2cb

kjbracey · 2018-02-14T09:38:31Z

features/cellular/framework/common/CellularLog.cpp

+    mbed_trace_mutex_release_function_set(serial_unlock);
+    mbed_trace_init();
+#else
+    serial_init(&stdio_uart, tx, rx);


This is a bit evil, touching these structures. I don't think you should be interfering with the console/stdio output settings. (You aren't in the mbed trace case).

(Besides, who's to say the console is even serial? mbed_trace just defaults to stdout, and debug() to stderr, whatever they are.).

File was removed in AriParkkila/mbed-os@5c8a2cb

kjbracey · 2018-02-14T09:40:53Z

features/cellular/framework/common/CellularLog.cpp

+    serial_baud(&stdio_uart, baud);
+    stdio_uart_inited = 1;
+#endif
+    log_info("\r\n\r\n**************************************");


If actually using mbed trace, each output should be a complete line, so if you want blank lines, you should technically do just two "" calls

File was removed in AriParkkila@5c8a2cb

kjbracey · 2018-02-14T09:43:46Z

features/cellular/framework/targets/QUECTEL/BC95/QUECTEL_BC95_CellularPower.cpp

+
+#include <QUECTEL_BC95_CellularPower.h>
+
+#include "onboard_modem_api.h"


Not actually using this?

no, removed include

kjbracey · 2018-02-14T09:46:52Z

features/cellular/framework/targets/UBLOX/C027/UBLOX_C027.h

+
+namespace mbed {
+
+class UBLOX_C027 : public AT_CellularDevice


This seems like a misnomer? The C027 is the board, not the modem.

Indeed, is there even anything C027-specific here? Isn't this just the "generic onboard PPP modem, using onboard power APIs?"

As a placeholder, renamed AT module to LISA_U
AriParkkila@7392e73

kjbracey · 2018-02-14T12:56:12Z

features/cellular/easy_cellular/EasyCellularConnection.h

+#define EASY_CELLULAR_CONNECTION_H
+
+#include "CellularConnectionUtil.h"
+#ifdef CELLULAR_DEVICE


Having done this, you should be able to cross-link to "OnboardCellularInterface.h" so that it includes this and typedefs OnboardCellularInterface as this object (ifdef CELLULAR_DEVICE), which should(?) totally eliminate the need for any app changes.

The intent was always that people providing onboard modems should arrange for them to appear as OnboardCellularInterface.

If application has defined CELLULAR_DEVICE (in mbed_app.json or mbed target for onboard modem) then modem is selected from cellular/targets/ folder. If application wants to use OnboardCellularInterface.h then it needs to specifically instantiate some class implementing that. That choice has now been intentionally left to application developers.

When designing the last round of cellular, what we ended up with was an attempt to achieve the "best of both worlds" for modem selection, while aligning with general design mbed OS architectural style.

For Ethernet, applications can usually just say EthernetInterface, because the target arranges for that to "do the right thing", accessing the Ethernet usually built into the main chip. For an add-on Wi-fi board, the application has to say XXXWiFi(pin, pin, pin).

The style in mbed OS so far has been for "on-main-chip" devices to be part of the "target", and hence automatically available to portable applications without explicit specification. You just specify the target. Plug-in things have to be explicitly specified, so applications doing that are not automatically portable.

Part of what I've been trying to work toward generally, and discussing with @sg-, is to allow the same driver (or a variant) to be both available for manual specification, and to be "just there" if it is actually built in to a target. The bulk of review (and redesign) last time was on this point.

The intent with OnboardCellularInterface was that someone could have a custom XXXModem(pin, pin, pin) that would work flexibly, and on any target. But if they actually built it into a target, the target would arrange for OnboardCellularInterface to be based on that general driver, with default constructor using all the correct pins and power controls, so that the application gets the same ease of use they get for EthernetInterface, due to it being target-specified.

Your framework would fit into that mechanism. If your target.json is defining CELLULAR_DEVICE to arrange for the right driver to be present because it's on the board, it makes sense for you to be pointing OnboardCellularInterface at that.

If you were talking about a non-target-specified modem, then the general style would be for the application to specify the modem by invoking its specific class, rather than JSON/define setting. I don't think applications should be setting CELLULAR_DEVICE (or its equivalent) - they should be giving it by name. That does mean you wouldn't have an equivalent to "easy cellular" for the offboard, but my understanding that that was out of immediate scope, and we were assuming on-board for now.

I'll spend some time discussing this with @sg- today or tomorrow to try to make sure we've got common architectural agreement here, then we can agree what to do on this.

Oh, for reference and comparison with other non-cellular things, which are works in progress, see: #6108

There you see "OnboardModemInterface" as fitting in as one of the sub-defaults of the overall "default network interface".

It's not following the new pattern I'm establishing - that would be CellularBase::get_default_instance() - but it achieves a similar effect. Maybe it could be deprecated in favour of that sort of call?

Right, the decision is that we will be doing the CellularBase::get_default_instance() and its the equivalents for non-cellular for 5.9, but for 5.8 we just stick with the existing 5.7 abstraction design - use OnboardCellularInterface as the abstraction point.

Now that you have something which should be a fully-fledged replacement for the 4 in-tree targets defining MODEM_ON_BOARD_UART (Ublox C027 & C030 and the 2 Dragonfly boards) including that APN functionality, I think you can switch those to the new code by changing the structure of OnboardCellularInterface to flow something like this:

#include "EasyCellularConnection.h" #ifdef CELLULAR_DEVICE typedef EasyCellularConnection OnboardCellularInterface; #elif MODEM_ON_BOARD && MODEM_ON_BOARD_UART && NSAPI_PPP_AVAILABLE #include "UARTCellularInterface.h" class OnboardCellularInterface : public UARTCellularInterface; #endif

That should mean that the client and cellular examples work without modification on those 4 targets and your new ones, as long as CELLULAR_DEVICE is being set automatically by the FEATURE_TARGET filtering. (Are there any remaining issues about necessary defines/configs?)

Any other targets we don't know about which set MODEM_ON_BOARD_UART will continue to use the 5.7 PPP driver. (In principle though, can't you're framework have a generic/default driver that would be able to act like UARTCellularInterface - I still think the Lisa U one is basically generic? Something to think about when removing that functionality).

In 5.9, we will have CellularBase::get_default_instance(), and that will give you more flexibility than that simple typedef - you would be able to construct something and maybe do more configuration. The OnboardCellularInterface point would be deprecated in favour of that.

We can also do CellularDevice::get_default_instance() for the full API then.

Annoyingly I see one error in mbed-os-example-cellular - it's calling iface.modem_debug_on, and that's not a CellularBase method, so would fail. Docs do say

Depending on the type of on-board modem, OnboardCellularInterface could be derived from different implementation classes. Portable applications should only rely on it being a CellularBase.

Adding that method to EasyCellular would avoid that compile failing, or we could remove the call from the app or make it compile time conditional somehow.

Typedef onboard cellular to easy cellular:
AriParkkila@a3d8783

Now after typedef https://github.com/ARMmbed/mbed-os-example-cellular can use this PR without any changes.

kjbracey · 2018-02-14T13:14:54Z

features/cellular/easy_cellular/EasyCellularConnection.h

+     *  @remark Must be called before any other methods
+     *  @return see nsapi_error_t, 0 on success
+     */
+    nsapi_error_t init();


NetworkInterface objects are generally self-initialising. Initialisation that require power and/or cause errors, so you don't want to do them in your constructor, can normally be deferred to first connect.

(Ideally disconnect would be a full power shutdown, so whatever you do in init would always happen on every new connect. Most current drivers don't really close everything though - they leave serial ports open, etc, so those are first connect only).

Doing that would be part of making this a transparent OnboardCellularInterface provider.

init is no longer needed to call from application

kjbracey · 2018-02-14T13:54:20Z

features/cellular/easy_cellular/EasyCellularConnection.cpp

+
+NetworkStack *EasyCellularConnection::get_stack()
+{
+#if NSAPI_PPP_AVAILABLE


Why does this knowledge extend out here to a user of the framework? Why doesn't the underlying CellularDevice return the PPP stack transparently?

kjbracey · 2018-02-14T13:55:39Z

features/cellular/easy_cellular/EasyCellularConnection.cpp

+
+static CellularConnectionUtil cellularConnection;
+static rtos::Semaphore cellularSemaphore(0);
+static UARTSerial cellularSerial(MDMTXD, MDMRXD, MBED_CONF_PLATFORM_DEFAULT_SERIAL_BAUD_RATE);


You can't just define these objects as static - they will be constructed and included in the image even if an EasyCellularConnection is never used.

Make them normal class members to avoid this issue.

👍 or use SingletonPtr class

Changed as class member variables

mirelachirica · 2018-02-15T07:48:09Z

features/cellular/framework/AT/AT_CellularNetwork.cpp

+
+    RegistrationType reg_types[] = { C_EREG,       C_GREG,       C_REG};
+    const char *cmd[] =            { "AT+CEREG",   "AT+CGREG",    "AT+CREG"};
+    const char *rsp[] =            { "+CEREG: ",    "+CGREG: ",     "+CREG: "};


Extra whitespace after ":" is preventing matching the response, in case modem returns the response without the whitespace, like "+CEREG:". AT Handler is already looking for possible whitespaces when trying to match, so no need to have the whitespace in this definition.

kjbracey · 2018-02-15T07:53:16Z

features/cellular/framework/AT/AT_CellularNetwork.cpp

+
+    memset(_apn, 0, MAX_ACCESSPOINT_NAME_LENGTH);
+
+#ifdef MBED_CONF_APP_CELLULAR_APN


This is an (hypothetical) application config setting - you can't access that from here.

If you want a default APN setting JSON it needs to be in your own cellular mbed_lib.json.

Changed APN initialization from CellularNetwork to application responsibility
AriParkkila@31c4e40

kjbracey · 2018-02-15T07:56:16Z

features/cellular/framework/mux/cellular_mux.h

+#define MUX_DLCI_INVALID_ID       0    /* Invalid DLCI ID. Used to invalidate MuxDataService object. */
+#define MUX_CRC_TABLE_LEN         256u /* CRC table length in number of bytes. */
+
+#ifndef MBED_CONF_MUX_DLCI_COUNT


If you're adding mbed conf options, you need to actually have a mbed_lib.json, otherwise no-one can change them.

You can also put the defaults and help in there - no need to have a default here unless it needs to compile outside mbed OS.

Managed by IOTCELL-570

juhoeskeli · 2018-02-15T13:03:26Z

Implemented status callbacks introduced by PR #6032 to cellular connectivity. Added missing functionality to AT_CellularNetwork::disconnect()

kimlep01 · 2018-02-15T14:09:34Z

Greentea tests are missing

kjbracey

Okay, so I've provided quite a long list of comments so far.

My trickier "efficiency"-related issues can be deferred.

On the details of the internal framework design I don't have much to say, except that you better be pretty certain that your public APIs are solid, because I'm sure you will get pushback if you decide you want to start redesigning things in 5.9. I'm still not clear how much this is intended to be a "draft". I'd be fine with that, but if that is the case it should have some sort of big disclaimer that "as a first release, framework APIs are subject to change".

But for the places where you are implementing existing core APIs - they have to be solid and correct. By going into the tree, you become one of the few core implementers of those APIs, and people will end up copying your example, and apps using those APIs will expect them to work in the conventional fashion. So my comments on flaws in the FileHandle, NetworkStack, NetworkInterface and CellularBase implementations must be addressed. I don't think any of those comments are that hard to fix.

Major functional omissions (no mux blocking support, no TCP support) must be explicitly stated.

kjbracey · 2018-02-16T11:40:26Z

features/cellular/framework/AT/AT_CellularStack.cpp

+
+nsapi_error_t AT_CellularStack::socket_listen(nsapi_socket_t handle, int backlog)
+{
+    return 0;


This needs to return an "unsupported" error.

AriParkkila@3a884aa

kjbracey · 2018-02-16T11:40:37Z

features/cellular/framework/AT/AT_CellularStack.cpp

+
+nsapi_error_t AT_CellularStack::socket_accept(void *server, void **socket, SocketAddress *addr)
+{
+    return 0;


This needs to return an "unsupported" error.

AriParkkila@3a884aa

kjbracey · 2018-02-16T11:41:09Z

features/cellular/framework/AT/AT_CellularStack.h

+/**
+ * Class AT_CellularStack.
+ *
+ * Implements NetworkStack and introduces interface for modem specific stack implementations.


You should document that the current implementation supports only UDP here.

I see IPv6 code - is it functional?

ticket created: IOTCELL-592

0xc0170 · 2018-02-19T16:24:39Z

Please review travis failure , looks related to this changes

mirelachirica · 2018-02-20T08:53:10Z

features/cellular/framework/AT/AT_CellularNetwork.cpp

+
+    if (success) {
+        _ip_stack_type = tmp_stack;
+        _cid = cid;


If context created successfully it should be deleted if connect(CGACT for this context) fails.
Internal ticket: IOTCELL-538

Fixed in: 55992a1

kjbracey · 2018-02-20T10:15:51Z

features/cellular/framework/mux/cellular_mux.cpp

+    _mutex.lock();
+
+    const bool writable = (_tx_context.tx_state == TX_IDLE);
+    const bool readable = (_rx_context.rx_state == RX_SUSPEND);


@this looks correct for writable, but I'm not sure about the readable. I think the condition should be _rx_context.is_user_ready - this should be the indication "read will now give you something, not just say -EAGAIN".

Using _state.is_user_rx_ready should be also fine but prefer doing it with like this at it maps to design description:
http://trac.oulu.arm.com/trac/nanoservice/wiki/NBIoT/Mux

ch Multiplexer frame RX statemachine - BASIC MODE

As thinking now _state.is_user_rx_ready could be removed completely as RX SM should have all required information available => tracked in IOTCELL-584

I'm not famililar with the structure, but the thing that prompted the comment was the fact the "I'm ready" condition is apparently different to that in the user_data_rx routine that implements read() above. Whichever you prefer, you should align the routines.

kjbracey · 2018-02-20T11:26:51Z

Great work addressing the majority of my points. Think we're mostly there on the code.

I'm not seeing any JSON yet - whichever settings you're expecting targets/applications to set should be present and documented in one or more mbed_lib.jsons. That would include CELLULAR_DEVICE, and some of the mux settings I've already mentioned.

AriParkkila · 2018-02-20T14:23:28Z

Added documentation about cellular with known limitations
https://github.com/AriParkkila/mbed-os/tree/master/features/cellular/README.md

# Cellular Connectivity ## Provides a new network option in mbed_app.json configuration file: "network-interface": { "value": "CELLULAR" } ## Related PRs Cellular implementation is coming to Mbed OS (5.8) in ARMmbed/mbed-os#6082

0xc0170 · 2018-02-21T14:39:51Z

Please remove 92a872b commit (rebase instead)

mirelachirica · 2018-02-21T15:28:04Z

features/cellular/framework/AT/ATHandler.cpp

+const char* ATHandler::mem_str(const char* dest, size_t dest_len, const char* src, size_t src_len)
+{
+    if (dest_len > src_len) {
+        for(size_t i = 0; i < dest_len-src_len; ++i) {


Comparration stops too early. Fixed in 49cffc2

jarvte · 2018-02-22T11:59:54Z

"Please remove 92a872b commit (rebase instead)"
I don't think there is need to rebase if commits are squashed when merging to master.

0xc0170 · 2018-02-22T12:03:12Z

"Please remove 92a872b commit (rebase instead)"
I don't think there is need to rebase if commits are squashed when merging to master.

We don't squash by default. And the aim for this PR is to be squashed into one commit? Based on the files changed (over 200), I do not think this is a good idea. To rebase (to clean up) the history, yes that would be nice.

mbed-ci · 2018-03-02T12:40:26Z

Exporter Build : SUCCESS

Build number : 981
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6082/

adbridge · 2018-03-02T12:40:45Z

Retrying
/morph test

AriParkkila · 2018-03-02T12:44:54Z

Rebased to mbed-os/master commit 'a137444: Merge pull request #6142 from scartmell-arm/feature-deep-sleep-tracing'

adbridge · 2018-03-02T12:47:46Z

/morph build

adbridge · 2018-03-02T12:48:55Z

@kjbracey-arm You will need to re-approve :)

kjbracey · 2018-03-02T12:49:01Z

Ah, if this was testing merge, then maybe the "test over longer period" fix in 6225 is still insufficient. This time it got a 0.6% error on that clock test, greater than the demanded 0.5%. Don't believe there's any way this PR affects that test.

adbridge · 2018-03-02T12:50:26Z

As @AriParkkila rebased the PR we will have to fully retest, fingers crossed it works this next time!

mbed-ci · 2018-03-02T13:25:50Z

Build : FAILURE

Build number : 1323
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6082/

adbridge · 2018-03-02T13:56:28Z

Actual failure here http://mbed-os.s3-eu-west-1.amazonaws.com/builds/6082/FAIL/NUMAKER_PFM_M453/ARM/f91cc33fca6e25537db447b6b7aab66b8fcdc17c_build_log_NUMAKER_PFM_M453_ARM.txt

BUILD/tests/NUMAKER_PFM_M453/ARM/TESTS/mbed_drivers/timerevent/main.o ./TESTS/mbed_drivers/timerevent/main.cpp
[DEBUG] Return: 1
[DEBUG] Output: Fatal error: A1023E: File "/tmp/filejCBVGt" could not be opened: No such file or directory
[DEBUG] Output: 1 Error, 0 Warnings

adbridge · 2018-03-02T13:58:24Z

Looks possibly like a CI failure rather than an issue ?

kjbracey · 2018-03-02T14:08:10Z

Yep, some sort of server glitch - out of disk space?

adbridge · 2018-03-02T14:15:16Z

That's my thinking too!
Will ping @studavekar

adbridge · 2018-03-02T15:00:52Z

Seems to be CI issue, re-triggering
/morph build

mbed-ci · 2018-03-02T15:38:23Z

Build : SUCCESS

Build number : 1324
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6082/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

mbed-ci · 2018-03-02T17:00:49Z

Test : SUCCESS

Build number : 1108
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6082/1108

mbed-ci · 2018-03-02T17:30:51Z

Exporter Build : FAILURE

Build number : 983
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6082/

cmonr · 2018-03-02T17:31:42Z

Last one.

/morph export-build

mbed-ci · 2018-03-02T18:31:11Z

Exporter Build : SUCCESS

Build number : 984
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6082/

0xc0170 added the needs: work label Feb 13, 2018

AriParkkila force-pushed the master branch from 550c24e to 8d912b7 Compare February 13, 2018 13:51

0xc0170 reviewed Feb 13, 2018

View reviewed changes

0xc0170 requested review from sg- and kjbracey February 13, 2018 15:06

kjbracey reviewed Feb 14, 2018

View reviewed changes

mirelachirica reviewed Feb 15, 2018

View reviewed changes

kjbracey reviewed Feb 15, 2018

View reviewed changes

kjbracey suggested changes Feb 16, 2018

View reviewed changes

sg- removed their request for review February 19, 2018 01:16

AriParkkila force-pushed the master branch 2 times, most recently from 5c8a2cb to 0e9a839 Compare February 19, 2018 11:28

mirelachirica reviewed Feb 20, 2018

View reviewed changes

kjbracey reviewed Feb 20, 2018

View reviewed changes

AriParkkila force-pushed the master branch from 96381fc to 9b4db25 Compare February 20, 2018 14:17

mirelachirica reviewed Feb 21, 2018

View reviewed changes

Ari Parkkila and others added 6 commits March 2, 2018 14:38

Changed std::snprintf to sprintf in cellular ATHandler.cpp

e183923

Changed cellular device as not static

bfed2ba

Removed mux.

7c9f5f3

Fixed unit test after removing mux.

dc87629

Removed mux comments from code.

9e2da6a

Updated readme document

f91cc33

AriParkkila dismissed kjbracey’s stale review via f91cc33 March 2, 2018 12:40

AriParkkila force-pushed the master branch from 7aeacc3 to f91cc33 Compare March 2, 2018 12:40

kjbracey approved these changes Mar 2, 2018

View reviewed changes

adbridge added release-version: 5.8.0-rc1 and removed needs: work labels Mar 2, 2018

adbridge merged commit a6e27b1 into ARMmbed:master Mar 2, 2018


		#include <QUECTEL_BC95_CellularPower.h>

		#include "onboard_modem_api.h"


		memset(_apn, 0, MAX_ACCESSPOINT_NAME_LENGTH);

		#ifdef MBED_CONF_APP_CELLULAR_APN


		namespace mbed {

		#define UART 1

Mbed OS cellular connectivity #6082

Mbed OS cellular connectivity #6082

Conversation

AriParkkila commented Feb 13, 2018

Description

Status

Migrations

Related PRs

0xc0170 commented Feb 13, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

blind-owl Feb 19, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kjbracey Feb 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kjbracey Feb 14, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

blind-owl Feb 19, 2018 •

edited

Loading

kjbracey Feb 20, 2018 •

edited

Loading

kjbracey Feb 14, 2018 •

edited

Loading