armmbed / mbed-os-tools Goto Github PK

Before we publish the versions of the legacy packages that import mbed-tools, we need to be sure to pin them to a version of mbed-tools (with what ever version number we end up going with).

To support the changes in our infrastructure we need greentea to support connecting with GRM over HTTPS. Looks like the necessary change is small and belongs here.

Currently, to add a mock, you have to do some odd things:

mbedls -m "C006:VLBUNO51"

mbedls --mock="C006:VLBUNO51"

both add a mock for the target id C006 and the platform name VLBUNO51.

While that my seem reasonable, it can also be done by:

mbedls --mock="+C006:VLBUNO51"

Which is a bit complicated.

Removing mocks are where things get nasty:

mbedls -m "-C006"

is in theory part of the syntax, but -C006 is parsed as a flag.

mbedls --mock="-C006"

is the only working way to actually remove a mock.
The readme also gives the impression that:

mbedls --mock="!C006"

should work, but it does not. Instead, it gives you a lovely trackback:

Traceback (most recent call last):
  File "/usr/bin/mbedls", line 11, in <module>
    load_entry_point('mbed-ls==1.3.2', 'console_scripts', 'mbedls')()
  File "/usr/lib/python3.6/site-packages/mbed_lstools/main.py", line 258, in mbedls_main
    ret_code = args.command(mbeds, args)
  File "/usr/lib/python3.6/site-packages/mbed_lstools/main.py", line 127, in mock_platform
    mbeds.mock_manufacture_id(mid, 'dummy', oper=oper)
  File "/usr/lib/python3.6/site-packages/mbed_lstools/lstools_base.py", line 231, in mock_manufacture_id
    raise ValueError("oper can only be [+-]")
ValueError: oper can only be [+-]

A much better interface would be:

mbedls add-mock C006 VLBUNO51

for add and:

mbedls rm-mock C006

or

mbedls remove-mock C006

for mock removal.

@yennster @bridadan Does this cover our offline discussion?

Currently test spec is missing version number. With time we would modify/enhance the test spec. In order maintain compatibility and may be some level of backward compatibility we need to version the test spec.

New test spec version will be instantiated by the build system as that is the source of the spec. Test spec version can not be build system version as spec does not need to change for every new build system version.

Greentea will have hard code to the version(s) that it supports. It can raise error for versions is does not support. Example: "Version p.q.r is no more supported" or "Update Greentea to support version x.y.z".

The less we change test spec version is better. This will keep build system and Greentea compatible most of the times.

Currently, mbedls prints for users through logging inside of the object created by mbed_lstools.create This is a policy decision, and should be left up to consumers of the library or the command line interface.

In short:

• Policy decisions, like what to do when a target does not have a mount point, should be decided by the API consumer.
• Any printing, logging or other side effect outside of the defined API indicates a bug in mbedls, or in the consumer (similar to deprecation warnings).
• Conditions that may indicate bugs should be logged.

This implies that:

1. several warning invocations should become debug or info
2. the list_mbeds() function must provide enough information to the API user to reconstruct the warnings that are currently logged
3. the list_mbeds() function should provide an "ergonomic" method for an API user to discover that one of the warning conditions has been encountered, making this discovery easy and/or explicit. This may be a documentation task, or include new API design.

1 and 2 should come as a single PR, possibly before 3.

@c1728p9 Did this capture our offline discussion?

The apis contained within https://github.com/ARMmbed/htrun/tree/master/mbed_host_tests/host_tests_toolbox do not seemed to be used within htrun (with the exception of handle_send_break_cmd, which can be relocated).

It is being used by Mbed CLI: https://github.com/ARMmbed/mbed-cli/blob/master/mbed/mbed.py#L2689

It would be good to know if any other tools are using this API so we can maintain it as a public API. Currently what we define as "public" is a bit ambiguous.

Description

Hi

Idea is to be able to configure in my local system some specific HW boards.

Ex:

• 1 board with a Arduino shield
• 1 board configured with a non default setting

I could use the mock command :

$ mbedls

$ mbedls -m 0764:DISCO_V1

$ mbedls

WARNING:mbedls.platform_database:Duplicate platform ids found: daplink.0764, ignoring the definitions from

My “ideal” command would be:

$ mbedls -m 076402216E2E6517516AF34E:DISCO_V1

Which change the name of only 1 board, other DISCO_L475VG_IOT01A will keep the original name

Do you think it could be possible ?

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

Please remove https://github.com/ARMmbed/mbed-tools/blob/master/CONTRIBUTING.md#contributor-agreement

Instead, this should be in Readme: https://github.com/ARMmbed/mbed-os#license-and-contributions (we updated this recently).

If you got any questions, let me know. I've been on this topic recently and update is ongoing for our docs/repositories.

I noticed some files do not contain license (no SPDX license identifier)

Please make sure all license info is there. Our license guide : https://os.mbed.com/docs/latest/reference/license.html (soon will be update to In all cases, whatever license you use, please use an SPDX license identifier in every source file following the recommendations to make it easier for users to understand and review licenses.)

This came up during #363. It may be helpful to users to print a warning if multiple devices share a mount point. Linux lets you do this but it will cause Mbed LS to give bogus results. Typically multiple Mbed devices sharing a mount point is a mistake anyway, so this would give users a helpful reminder.

Negative return codes have additional meaning on some platforms:

https://docs.python.org/3/library/subprocess.html#subprocess.Popen.returncode:

A negative value -N indicates that the child was terminated by signal N (POSIX only).

There are some recommended guidelines about return codes.

• https://www.freebsd.org/cgi/man.cgi?query=exit

  The C Standard (ISO/IEC 9899:1999 (``ISO C99'')) defines the values 0, EXIT_SUCCESS, and EXIT_FAILURE as possible values of status. Cooperating processes may use other values; in a program which might be called by a mail transfer agent, the values described in sysexits(3) may be used to provide more information to the parent process.

• https://www.freebsd.org/cgi/man.cgi?query=sysexits:

  According to style(9), it is not a good practice to call exit(3) with arbitrary values to indicate a failure condition when ending a program. Instead, the pre-defined exit codes from sysexits should be used, so the caller of the process can get a rough estimation about the failure class without looking up the source code.

Negative return codes can be misinterpreted easily because:

(unsigned)rc & 0xFF == (int)rc & 0xFF == (unsigned)(rc && 0xFF) != (int)((char)rc && 0xFF))

Only the last style gets sign extension right.

There are some legacy tests present here: https://github.com/ARMmbed/mbed-ls/blob/master/test/mbed_htm.py#L49-L71

I don't think they add much value and it should be ok to remove them.

We're just now upgrading to mbedos 11...we used to keep one .mbedignore file in the root directory, where we would skip some tests that weren't passing on our system. Since the upgrade, it seems greentea only skips tests if the .mbedignore file is under the TESTS directory. does that sound right? Where will greentea look for .mbedignore files in the directory tree?

Description: [DISCO_L475VG_IOT01A]LED Blinker: Fails to connect with LED app

Target: DISCO_L475VG_IOT01A
Toolchain: GCC_ARM
mbed-cli version: 1.8.3
mbed-os->5.11.1

App used: mbed-os-example-ble-LEDBlinker

Steps to Reproduce:
Import project from https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-ble-LEDBlinker/
Edit the mbed-os.lib file to below link to
https://github.com/ARMmbed/mbed-os/#2fd0c5cfbd83fce62da6308f9d64c0ab64e1f0d6
Do mbed deploy to update mbed-os to use the above revision
Do mbed compile -target DISCO_L475VG_IOT01A -toolchain GCC_ARM
In another setup make LED app ready and should be advertising

Expectation: Soon after download LEDBlinker app should connect with LED app

Observation: LEDBlinker connection with LED is not successful, Also in the teraterm unable to see any logs (apart from MAC device BD Address)

Note: Recently they have made some changes to the code, LEDBlinker older version of app is working fine, We have downloaded the latest version of app from https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-ble-LEDBlinker/ site

When the bootloader takes more time than expected, the sync message never reaches the test application.

Steps to reproduce:

1. Import https://github.com/ARMmbed/smcc-tests
2. Checkout branch htrun-bl-desync
3. Run tests with mbed test -t ARM -m K64F -n simple-mbed-cloud-client-tests-dev_mgmt-connect* -v

If you connect to the board using mbed sterm -b 115200 you can pass it a fake sync message, e.g. {{__sync;0}} and the test will start normally.

@bridadan @theotherjimmy

Hi @theotherjimmy and @bridadan , thanks again for all the great info yesterday!

It's looking like we can't buy those DIPdaps anymore, so can we revisit the idea of programming an mbed target via a flasher that does not enumerate as a mass storage device? It would be used via the command line. I know yesterday we were talking about how there would be an issue around target detection, any more thoughts on the direction we should head in trying to work around that? Happy to back contribute whatever we come up with!

Hey guys,
i am working on linux and i was wondering if you could include a copy/reset module for this:
st-flash
this tool works also on windows but there i would use the stlink plugin
the commandline is pretty straight forward

copy: st-flash [--serial <serial>] write <image_path> 0x80000000
reset: st-flash [--serial <serial>] reset

thank you

Many of the submodules import other submodules within mbed_tools. They should import them consistently, currently its a mixture of import mbed_tools.*, import ., and other things in between.

We are trying to test pelion-enablement.
But the command, mbed test -t ARM -m SDT64B -n simple-mbed-cloud-client-tests-* --run -v, is typed, the error is occurred like below.
Our colorama's version is 0.4.1. So we think it caused this error.
Is the only solution for this error lower colorama's version than 0.4.0??

C:\mbed\Workspace\Test\pelion-enablement>mbed test -t ARM -m SDT64B -n simple-mbed-cloud-client-tests-* --run -v
[mbed] Working path "C:\mbed\Workspace\Test\pelion-enablement" (program)
[mbed] Exec "mbedgt --test-spec .\BUILD\tests\SDT64B\ARM\test_spec.json -n simple-mbed-cloud-client-tests-* -V" in "C:\mbed\Workspace\Test\pelion-enablement"
Traceback (most recent call last):
  File "C:\mbed\Tools\mbed-CLI\Python27\Scripts\mbedgt-script.py", line 6, in <module>
    from pkg_resources import load_entry_point
  File "c:\mbed\tools\mbed-cli\python27\lib\site-packages\pkg_resources\__init__.py", line 3088, in <module>
    @_call_aside
  File "c:\mbed\tools\mbed-cli\python27\lib\site-packages\pkg_resources\__init__.py", line 3072, in _call_aside
    f(*args, **kwargs)
  File "c:\mbed\tools\mbed-cli\python27\lib\site-packages\pkg_resources\__init__.py", line 3101, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "c:\mbed\tools\mbed-cli\python27\lib\site-packages\pkg_resources\__init__.py", line 576, in _build_master
    return cls._build_from_requirements(__requires__)
  File "c:\mbed\tools\mbed-cli\python27\lib\site-packages\pkg_resources\__init__.py", line 589, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "c:\mbed\tools\mbed-cli\python27\lib\site-packages\pkg_resources\__init__.py", line 778, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'colorama<0.4,>=0.3' distribution was not found and is required by mbed-greentea
[mbed] ERROR: "mbedgt" returned error.
       Code: 1
       Path: "C:\mbed\Workspace\Test\pelion-enablement"
       Command: "mbedgt --test-spec .\BUILD\tests\SDT64B\ARM\test_spec.json -n simple-mbed-cloud-client-tests-* -V"
       Tip: You could retry the last command with "-v" flag for verbose output
---

Description: Unable to communicate with BLE APIs through greentea testing

Target: DISCO_L475VG_IOT01A
Toolchain: GCC_ARM
mbed-cli version: 1.8.3
mbed-os->5.11.1

Steps to Reproduce:

1. Create directory structure like below
   inside mbed-os -> TESTS->Group1->TestCase1->main.cpp(I have attached my main.cpp which i tried)
2. Create the BLE object like below
   BLE &ble = BLE::Instance();
   ble.gap().startAdvertising();
3. Add all necessary (BLE.h, BLE.cpp... ) files to the same directory where you are running the test case
4. Try to run the testcase using below command
   mbed test -m DISCO_L475VG_IOT01A -t GCC_ARM -n tests-Group1-TestCase1

Observation: Other existing test cases are passing, When we try to create BLE object and try to call any API it is failing with the below error

"Please provide the implementation for MBED BLE"

Please find the attached logs and main.cpp file

GreenTeaErrorForBLEAPI.txt
main.txt

Our tools historically haven't supported Cygwin: ARMmbed/mbed-ls#98

We should investigate this use case and see if it is straightforward to add support.

Description

There's a considerable number of repeated messages coming from the mbedls module during greentea testing.

Here's an example:

[1549383037.57][mbedls.platform_database]Duplicate platform ids found: daplink.2042, ignoring the definitions from C:\Users\campesc\AppData\Local\mbedls\mbedls\platforms.json
[1549383039.14][mbedls.lstools_base]No valid file found to update JLink device details
[1549383039.65][mbedls.platform_database]Duplicate platform ids found: daplink.2042, ignoring the definitions from C:\Users\campesc\AppData\Local\mbedls\mbedls\platforms.json
[1549383041.30][mbedls.lstools_base]No valid file found to update JLink device details
[1549383041.80][mbedls.platform_database]Duplicate platform ids found: daplink.2042, ignoring the definitions from C:\Users\campesc\AppData\Local\mbedls\mbedls\platforms.json
[1549383043.51][mbedls.lstools_base]No valid file found to update JLink device details
[1549383044.01][mbedls.platform_database]Duplicate platform ids found: daplink.2042, ignoring the definitions from C:\Users\campesc\AppData\Local\mbedls\mbedls\platforms.json
[1549383044.93][mbedls.lstools_base]No valid file found to update JLink device details
[1549383045.44][mbedls.platform_database]Duplicate platform ids found: daplink.2042, ignoring the definitions from C:\Users\campesc\AppData\Local\mbedls\mbedls\platforms.json
[1549383047.14][mbedls.lstools_base]No valid file found to update JLink device details

Perhaps these should be shown once as a warning, rather than repeated messages.

Issue request type

[ ] Question
[X] Enhancement
[ ] Bug

There are a few device results that are returned as 'unknown' instead of the more Pythonic None. One of these data points is device_type. I think there may be more. 'unknown should really only be used when printing results, if then at all.

Steps to reproduce:
1.Install mbedls - 1.7.1 version.
2.Do mbedls and observe below error.

 mbedls --version
Traceback (most recent call last):
  File "/home/cy-user/.local/bin/mbedls", line 10, in <module>
    sys.exit(mbedls_main())
  File "/home/cy-user/.local/lib/python2.7/site-packages/mbed_lstools/main.py", line 183, in mbedls_main
    logger.debug("mbed-ls ver. %s", get_version())
  File "/home/cy-user/.local/lib/python2.7/site-packages/mbed_lstools/main.py", line 41, in get_version
    return pkg_resources.require("mbed-ls")[0].version
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 943, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 834, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (urllib3 1.19.1 (/usr/local/lib/python2.7/dist-packages/urllib3-1.19.1-py2.7.egg), Requirement.parse('urllib3<1.25,>=1.21.1'), set(['requests'])).

Ubuntu 17.04 zesty
mbedls --version 1.3.3

1. mount board as userA
2. run mbedls as userB

It dies without mentioning that there might be a permission issue. This can happen easily if userA has an automounter.

$ mbedls -d
DEBUG:mbedls.main:mbed-ls ver. 1.3.3
DEBUG:mbedls.main:host: ('posix', 'Linux', '4.10.0-19-generic', '#21-Ubuntu SMP Thu Apr 6 17:04:57 UTC 2017', 'linux2')
DEBUG:mbedls.lstools_linux:Converting device list ['/dev/disk/by-id/usb-MBED_VFS_0217000033514e45002b5015846c00486cb1000097969900-0:0', '/dev/disk/by-id/wwn-0x5000c500a3a88231-part1', '/dev
/disk/by-id/ata-ST1000DM003-1SB102_Z9AFJ9QY-part1', '/dev/disk/by-id/wwn-0x5000c500a3a88231-part2', '/dev/disk/by-id/ata-ST1000DM003-1SB102_Z9AFJ9QY-part2', '/dev/disk/by-id/wwn-0x5000c500a
3a88231', '/dev/disk/by-id/ata-ST1000DM003-1SB102_Z9AFJ9QY', '/dev/disk/by-id/ata-PLDS_DVD-RW_DA8AESH_DX0K84169L1CB7401493', '/dev/disk/by-id/nvme-eui.002538b671b4fd39-part1', '/dev/disk/by
-id/nvme-SAMSUNG_MZVLW256HEHP-000L7_S35ENX0J677706-part1', '/dev/disk/by-id/nvme-eui.002538b671b4fd39', '/dev/disk/by-id/nvme-SAMSUNG_MZVLW256HEHP-000L7_S35ENX0J677706']
DEBUG:mbedls.lstools_linux:Found disk devices by id {'0217000033514e45002b5015846c00486cb1000097969900': '/dev/sdb'}
DEBUG:mbedls.lstools_linux:Converting device list ['/dev/serial/by-id/usb-ARM_DAPLink_CMSIS-DAP_0217000033514e45002b5015846c00486cb1000097969900-if01']
DEBUG:mbedls.lstools_linux:Found serial devices by id {'0217000033514e45002b5015846c00486cb1000097969900': '/dev/ttyACM0'}
DEBUG:mbedls.lstools_linux:Mount mapping {u'/dev/sdb': u'/media/arm/FRDM-K82FD'}
DEBUG:mbedls.lstools_base:Candidates for display [{'mount_point': u'/media/arm/FRDM-K82FD', 'serial_port': '/dev/ttyACM0', 'target_id_usb_id': '0217000033514e45002b5015846c00486cb1000097969
900'}]
WARNING:mbedls.lstools_base:MBED with target id '0217000033514e45002b5015846c00486cb1000097969900' is connected, but not mounted. Use the '-u' flag to include it in the list.
DEBUG:mbedls.main:Return code: 0

cc @theotherjimmy

Description: [DISCO_L475VG_IOT01A]Privacy: App compilation fails with fatal error

Target: DISCO_L475VG_IOT01A
Toolchain: GCC_ARM
mbed-cli version: 1.8.3
mbed-os->5.11.1
App used: mbed-os-example-ble-privacy

Steps to Reproduce:

1. .Import project from https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-ble-privacy/
2. Edit the mbed-os.lib file to below link to
   https://github.com/ARMmbed/mbed-os/#2fd0c5cfbd83fce62da6308f9d64c0ab64e1f0d6
3. Do mbed deploy to update mbed-os to use the above revision
4. Do mbed compile -target DISCO_L475VG_IOT01A -toolchain GCC_ARM

Expectation: App compilation and download should be successful

Observation: Privacy app compilation fails with below error
"[ERROR] .\source\main.cpp:19:21: fatal error: ble/BLE.h: No such file or directory"

Please find the attached logs for compilation error
PrivacyFailureOnDisco.txt

Description

Issue request type

[ x] Question
[ ] Enhancement
[ ] Bug

Short summary: I propose to rename this repository (and eventual pip package) from mbed-os-tools to mbed_os_tools.

Background: This is a usability question.

To install: pip install mbed-os-tools
To clone: git clone mbed-os-tools
To import import mbed_os_tools <- Uh, oh

PEP8 actually discourages the use of underscores (doesn't even mentions dashes). That would lead to mbedostools, which I don't think is that helpful. Perhaps mbed_os_tools would be more appropriate for this repository name and package? Thoughts @theotherjimmy @SenRamakri ? I'm very actively trying to avoid the mess that is the current situation with our tools (greentea/mbed-greentea/mbedgt, htrun/mbed-host-tests/mbedhtrun, etc...).

On a NRF52_DK:

I am using a host test as a server side emulation. I need to pass base64 encoded strings back and forth. This works fine for DUT -> HOST, but HOST -> DUT fails if the value is longer than approx. 45 characters. You can use the host test @event_callback below to test this. If you remove the last 5-9 characters it works.

    @event_callback("messageLength")
    def __messageLength(self, key, value, timestamp):
        self.send_kv("testLongMessage", "1234567890123456789012345678901234567890123456789")

The corresponding Test is:

void TestLongMessage() {
    char k[48], v[255];
    greentea_send_kv("messageLength", "start");
    greentea_parse_kv(k, v, sizeof(k), sizeof(v));
    greentea_send_kv(k,v);
}

Side note: debugging this appeard to read more than 45 characters but at some point only trash was read from the serial, so I cannot say whether it's the python side that might break things.

The Mbed LS README says you can execute mbedls --mock="-*" to remove all mocks. This does not seem to be working. I tested this using mbed-ls version v 1.6.2 on Windows.

I noticed there's a plugin system in place for adding additional reset logic.

It would be awfully convenient to have a reset option that simply queries the user to reset the device, and waits for the user to push a key or something.

I'm currently dealing with a board that must be power cycled for the necessary hardware blocks to initialize correctly (it's a long story). Having a user-based reset would be very convenient.

cc @studavekar, @theotherjimmy

Run command: mbedhtrun --version on Ubuntu
It prints:

[1538563017.99][root]Generating grammar tables from /usr/lib/python2.7/lib2to3/Grammar.txt
[1538563018.03][root]Generating grammar tables from /usr/lib/python2.7/lib2to3/PatternGrammar.txt
1.4.1

Where those lib2to3 message should not be shown

If i try to execute any testcase using below command it is failing with below error, I have created dummy main.cpp in TESTS\Group1\TestCase1\ and tried to execute it
C:\mbedOSExample\mbed-os-example-blinky>mbedgt -n tests* -t GCC_ARM -m DISCO_L475VG_IOT01A
mbedgt: greentea test automation tool ver. 1.2.5
mbedgt: using multiple test specifications from current directory!
using 'BUILD\tests\DISCO_L475VG_IOT01A\GCC_ARM\test_spec.json'
mbedgt: detecting connected mbed-enabled devices...
[1547031484.20][mbedls.lstools_base]Call to deprecated function list_mbeds_ext. Functionality has been moved into 'list_mbeds'. Please use list_mbeds with 'unique_names=True' and 'read_details_txt=True'
mbedgt: detected 1 device
mbedgt: shuffle seed: 0.1498640650
mbedgt: no platform/target matching tests were found!
mbedgt: no matching platforms were found!
mbedgt: completed in 0.96 sec
mbedgt: exited with code -110

C:\mbedOSExample\mbed-os-example-blinky>mbedhtrun --version
1.4.4

C:\mbedOSExample\mbed-os-example-blinky>mbedgt -l
mbedgt: greentea test automation tool ver. 1.2.5
mbedgt: using multiple test specifications from current directory!
using 'BUILD\tests\DISCO_L475VG_IOT01A\GCC_ARM\test_spec.json'
mbedgt: available tests for built 'DISCO_L475VG_IOT01A-GCC_ARM', location 'BUILD/tests/DISCO_L475VG_IOT01A/GCC_ARM'

if I compile program with mbed test --build option, the host test detection will fail.

This method used to detect host test direction is not robust https://github.com/ARMmbed/greentea/blob/master/mbed_greentea/mbed_test_api.py#L160

In theory, the test_spec.json already give a "base_path" field to tell mbedgt what the base build directory is. This would be a more robust way to detecting relative path of host tests.

when I use the -n "tests-unit-unittest"
the host test can be detected in "TESTS/unit/host_tests"

But if I don't use the -n option
the host test have to reside in "TESTS/host_tests" in order to be detected.

There are quire a few #!/usr/bin/env python lines throughout the source. I don't believe all of these are necessary, so it would be good to clean them up to reduce the propagation of these through copy-paste.

we are using our own company platforms.
while doing mbedls, platform name is coming as "unknown".

cy-user@cyuser-Latitude-E6430:~$ mbedls
WARNING:mbedls.lstools_base:daplink entry: "1901" not found in platform database
| platform_name | platform_name_unique | mount_point            | serial_port  | target_id                                        | daplink_version |
|---------------|----------------------|------------------------|--------------|--------------------------------------------------|-----------------|
| unknown       | None[0]              | /media/cy-user/DAPLINK | /dev/ttyACM0 | 190100006c0f181f036c0f1800000000000000002e127069 | 0251            |

There is now a public https://www.mbed.com/api/v1/boards/ endpoint. It exposes all public boards. It contains information about product code, features, targets (classic, mbed os 5, yotta) and more. There is also similar endpoint on developer.mbed.org site but it requires token to get this information.

See IOTWEB-1105 for more details.

Consider the following example logs.

Good log

** Hello Example **
Main loop count: 0
Main loop count: 1
Main loop count: 2
Main loop count: 3
Main loop count: 4
Main loop count: 5
Main loop count: 6
Main loop count: 7
Main loop count: 8
Main loop count: 9
Main loop count: 10
IRQ 1 from Button 1 Pressed
Main loop count: 11
Main loop count: 12
Main loop count: 13
Main loop count: 14
Main loop count: 15

Bad log

** Hello Example **
Main loop count: 0
Main loop count: 1
Main loop count: 2
Main loop count: 3
Main loop count: 4
Main loop count: 5
** Out of memory
Main loop count: 6
Main loop count: 7
Main loop count: 8
Main loop count: 9
Main loop count: 10
IRQ 1 from Button 1 Pressed
Main loop count: 11
Main loop count: 12
Main loop count: 13
Main loop count: 14
Main loop count: 15

Good log

** Hello Example **
Main loop count: 0
Main loop count: 1
Main loop count: 2
Main loop count: 3
Main loop count: 4
Main loop count: 5
Main loop count: 6
Main loop count: 7
Main loop count: 8
Main loop count: 9
Main loop count: 10
Main loop count: 11
IRQ 1 from Button 1 Pressed
Main loop count: 12
Main loop count: 13
Main loop count: 14
Main loop count: 15

These logs are impossible to match with the current log matching functionality. The current log matching feature (for both programmer implementation and user cognitive overhead) would be simplified by matching with a single multi-line regular expression.

Example log matcher

The following multi-line regular expression would deal with the asynchronicity of the previous logs, where the IRQ could come at basically any time relative to the "Main loop count" lines. It would also fail to match if the ** Out of memory print happened at any time from some other thread in the system.

(\*\* Hello Example \*\*\r\n)(Main loop count: \d+\r\n)+(IRQ \d+ from Button \d+ Pressed\r\n)(Main loop count: \d+\r\n)

I was wondering why ST-boards are listed under "daplink" section in the DEFAULT_PLATFORM_DB? The device_type seems to be correctly resolving to "stlink" from VID. Turns out mbed-flasher depends on the right content in DEFAULT_PLATFORM_DB, when choosing the right flashing method.

I am testing against v1.6.2, the behavior in e.g. v1.4.6 is different (ST boards tell they are "daplink").

Mbed LS (and maybe htrun) will continue to have contributions made to them while mbed-tools is under construction. This is a reminder to be sure and reconcile the divergent histories before releasing mbed-tools.

This one I need to add to our docs, as I noticed some projects did it recently. This might also benefit using the templates (I assume PR template might have different types). Issues might be the same, so our jira bot can scrape the info with no changes :)

in automation point of view we would like to update daplink softare and identify devices with mbed-ls just like before. Problem is now that mbed-ls give totally different target_id when device is in bootloader mode and therefore we cannot identify same board than when daplink is in normal mode.

Proposal changes:

• mbed-ls give information when device is in bootloader or in normal mode (in json result only is enough for me)

• mbed-ls give exactly same target_id in bootloader mode as well as normal mode.

  This probably needs more work and investigate how to do, because it might affect daplink implementation as well (@c1728p9 comments?)

Anyway, this is almost mandatory because otherwise we have to create hacky solution to avoid these "missing features".

@PrzemekWirkus @bridadan @c1728p9 @RomanSaveljev

Description: [DISCO_L475VG_IOT01A]GAP Button: Service data field is not changing upon pushing USER button
Target: DISCO_L475VG_IOT01A
Toolchain: GCC_ARM
mbed-cli version: 1.8.3
mbed-os->5.11.1
App used: mbed-os-example-ble-GAPButton

Steps to Reproduce:
Import project from https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-ble-GAPButton/
Edit the mbed-os.lib file to below link to
https://github.com/ARMmbed/mbed-os/#2fd0c5cfbd83fce62da6308f9d64c0ab64e1f0d6
Do mbed deploy to update mbed-os to use the above revision
Do mbed compile -target DISCO_L475VG_IOT01A -toolchain GCC_ARM
Scan the device from nRF or lightblue peer app
Push on the APP button from the device to see whether it reflects the button press count from starting value 0 in the Service Data field

Expectation: The Service Data field value of the advertisement packet should change every time you press the button.
Observation: Service data value is not changing when we press the APP button from the device

Please find the attached image file

For whatever reason, the subtrees did not preserve the history. I'm wondering if instead merging those changes through a PR we instead need to just push directly to master. Eww @theotherjimmy

If user wants to downgrade mbed-ls to earlier release platforms.json must be manually deleted since the newer version might not be backwards compatilble. This happens at least when downgrading from 1.4 to 1.3.7.

Pip uninstall should remove platforms.json.

At: https://github.com/ARMmbed/mbed-os-tools/tree/master/packages/mbed-greentea

The link leads to https://github.com/ARMmbed/mbed-os-tools/tree/master/src/mbed_os_tools and the test directory has no readme for greentea.

As an aside who is still using yotta I must know.

Close at your leisure.

Hi

I would prefer that test case status is not sorted during mbedgt execution.

Ex:
Tested command: mbed test -t ARM -m NUCLEO_F070RB -vv -n tests-mbedmicro-rtos-mbed-threads

We can see the test suite execution :

[1473239592.78][CONN][RXD] >>> Running case #1: 'Testing single thread'...
[1473239592.98][CONN][RXD] >>> Running case #2: 'Testing parallel threads'...
[1473239593.18][CONN][RXD] >>> Running case #3: 'Testing serial threads'...

Then the test suite status:

mbedgt: test suite 'tests-mbedmicro-rtos-mbed-threads' ............................................... TIMEOUT in 50.15 sec
test case: 'Testing parallel threads with wait' .............................................. OK in 0.17 sec
test case: 'Testing single thread with wait' ................................................. OK in 0.15 sec
test case: 'Testing serial threads with yield' ............................................... OK in 0.06 sec
test case: 'Testing single thread with yield' ................................................ OK in 0.06 sec
test case: 'Testing serial threads with wait' ................................................ OK in 1.06 sec
test case: 'Testing single thread' ........................................................... OK in 0.06 sec
test case: 'Testing parallel threads with child' ............................................. ERROR in 0.00 sec

==> Can this status can be displayed in the right order?

For report, I think we can keep the sort.

Thx

This is very very redundant. I'm not sure if anyone even imports them.

Original Issue raised here : ARMmbed/mbed-cli#454 (comment)

Problem

When using the test -n command the test name must be input in lower case, even if the folders represented by the test name are all in caps. This has lead to a great deal of confusion for developers.

example

CI Test shield test for SPI is located in the folder TESTS/API/SPI, so to run this test you would use test -n tests-api-spi. I have observed multiple developers try to use test -n TESTS-API-SPI because the name of the folders are in caps, so they understand the folder names seperated by dashes, but the lower case conversion almost always throws them.

Proposal

To make the tool more intuitive I propose accepting either caps lock or lower case and then munging it as appropriate before passing it on. That way the tool becomes more intuitive to use.