Platform: Linux, macOS, Windows (logs attached are from macOS) Board: B-L4S5I-IOT01A (https://os.mbed.com/platforms/B-L4S5I-IOT01A/) Toolchain: ARMC6 (but I'm pretty sure that issue is also reproducible for GCC_ARM) pyOCD: 0.30.3 (issue exists also on previous versions) Python: 3.7+ (Issue exists also on other Python versions)

Steps to reproduce:

1. Import https://github.com/ARMmbed/mbed-os-example-blinky
2. Build a program. Using Mbed Studio or Mbed CLI (https://github.com/ARMmbed/mbed-cli)
3. Download a CMSIS-Pack (Keil.STM32L4xx_DFP.2.5.0.pack) for the target from: https://developer.arm.com/tools-and-software/embedded/cmsis/cmsis-packs
4. Run pyOCD:

> pyocd gdbserver --pack {path/to/Keil.STM32L4xx_DFP.2.5.0.pack} --erase=chip --target STM32L4S5VITx -O connect_mode=under-reset

5. Run arm-none-eabi-gdb:

> arm-none-eabi-gdb {path/to/binary.elf}
> target remote localhost:3333

GDB logs: gdb.log pyOCD logs: pyocd.log

Summary of changes

Using MBED_SLEEP_TRACING_ENABLED is not reliable with STM32 targets.

See discussions in #11497 #14580 ...

[edit] This new MBED_SLEEP_STAT_ENABLED macro is the same one removing prints at each sleep_manager_lock/unlock_deep_sleep

• deepsleep stats can be enabled now with json config
• default configuration is not changed (full verbosity adding a console line for each lock/unlock command)
• except for STM32 targets, verbosity is reduced by default

Impact of changes

Migration actions required

Documentation

STM32 readme file is updated

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

@ARMmbed/team-st-mcd

Description of defect

The program is crashing on the wisun TLS process for the NUCLEO_WB55RG when using the hardware acceleration (MBEDTLS_CONFIG_HW_SUPPORT), which is active by default. This happens for both, border router and node.

Mbed log:

[INFO][wsbs]: authentication start
[INFO][fhss]: fhss Configuration set, UC channel: 44, BC channel: 45, UC CF: 2, BC CF: 0, channels: BC 43 UC 43, uc dwell: 255, bc dwell: 255, bc interval: 0, bsi:0, ch retries: 0
[INFO][wsps]: Delete old keys, new PAN ID: 54349 network name: Wi-SUN Network
[INFO][ksep]: Initial-key init
[INFO][wsps]: EAPOL target: 6e:70:0f:5f:97:16:50:d6
[INFO][wsps]: Initial EAPOL-Key trickle I: [360,500] 468, t: 462
[INFO][ksep]: Initial EAPOL-Key send, PMKID not set PTKID not set GTKL 0
[INFO][ksep]: Initial-key finished
[INFO][fhss]: fhss Configuration set, UC channel: 44, BC channel: 255, UC CF: 2, BC CF: 2, channels: BC 43 UC 43, uc dwell: 255, bc dwell: 255, bc interval: 1020, bsi:64198, ch retries: 0
[INFO][fhss]: TX slot length: 54ms
[INFO][eaps]: EAP-TLS init
[INFO][eaps]: EAP-TLS recv REQ type IDENTITY id 1 flags 0 len 5
[INFO][eaps]: EAP-TLS start
[INFO][eaps]: EAP-TLS: send RESPONSE type IDENTITY id 1 flags ff len 18
[INFO][eaps]: EAP-TLS recv REQ type TLS id 2 flags 20 len 6
[INFO][eaps]: EAP-TLS: send RESPONSE type TLS id 2 flags 0 len 92
[INFO][eaps]: EAP-TLS recv REQ type TLS id 3 flags c0 len 610
[INFO][eaps]: EAP-TLS: send RESPONSE type TLS id 3 flags 0 len 10
[INFO][eaps]: EAP-TLS recv REQ type TLS id 4 flags 0 len 79
[INFO][tlsl]: no wisun fields on cert

++ MbedOS Fault Handler ++

FaultType: HardFault

Context:
R   0: 2000B5AC
R   1: FFFFFFFF
R   2: 00000000
R   3: 20030000
R   4: 00000000
R   5: 2000B5AC
R   6: 20013250
R   7: 200123CC
R   8: 2000B4C4
R   9: 00000000
R  10: 2000B4E8
R  11: 00000034
R  12: 08001319
SP   : 2000B478
LR   : 08004515
PC   : 0805A844
xPSR : 610F0000
PSP  : 2000B410
MSP  : 2002FFC0
CPUID: 410FC241
HFSR : 40000000
MMFSR: 00000082
BFSR : 00000000
UFSR : 00000000
DFSR : 00000008
AFSR : 00000000
MMFAR: 00000000
Mode : Thread
Priv : Privileged
Stack: PSP

-- MbedOS Fault Handler --



++ MbedOS Error Info ++
Error Status: 0x80FF013D Code: 317 Module: 255
Error Message: Fault exception
Location: 0x805A844
Error Value: 0x2000E568
Current Thread: nanostack_event_thread Id: 0x2000BAE8 Entry: 0x801BD65 StackSize: 0x1800 StackMem: 0x2000A2E8 SP: 0x2000B478 
For more info, visit: https://mbed.com/s/error?error=0x80FF013D&tgt=NUCLEO_WB55RG
-- MbedOS Error Info --

Info from https://github.com/ARMmbed/mbed-os-example-fault-handler project

Crash Info:
	Crash location = HAL_CRYP_DeInit [0x0805A844] (based on PC value)
	Caller location = mbedtls_aes_free [0x08004515] (based on LR value)
	Stack Pointer at the time of crash = [2000B478]
	Target and Fault Info:
		Processor Arch: ARM-V7M or above
		Processor Variant: C24
		Forced exception, a fault with configurable priority has been escalated to HardFault
		Data access violation. Faulting address: 00000000

Target(s) affected by this defect ?

NUCLEO_WB55RG

Toolchain(s) (name and version) displaying this defect ?

GCC_ARM - arm-none-eabi-gcc (GNU Arm Embedded Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.12.0, but it seems not be working since mbed-os-6.9.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli 1.10.4

How is this defect reproduced ?

Just run the https://github.com/ARMmbed/mbed-os-example-mesh-minimal project for the node and the https://github.com/PelionIoT/nanostack-border-router project for the border router, using for both one of the the wisun configs

Description of defect

When running a bare-metal profile on a STM32F401RE and using an external crystal, ThisThread::sleep_for never returns. This was tested on both a custom PCB and the Nucleo F401RE with a 8Mhz crystal soldered on. The external crystal definitely works since setting BOOT0=1 creates the manufacturer DFU USB bootloader successfully.

Target(s) affected by this defect ?

STM32F401RE / Nucleo-F401RE

Toolchain(s) (name and version) displaying this defect ?

Mbed-studio with GCC Compiler

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.10.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Mbed Studio v1.4.1

How is this defect reproduced ?

main.cpp:

#include <mbed.h>

DigitalOut led(LED1);

int main()
{
  led = !led;
  ThisThread_sleep_for(500ms);  //This causes everything to freeze
  /*
  //Using old-school delay method works:
  for (int i = 0; i < 500; i++)
    wait_us(1000);
  */
}

mbed_app.json

{
    "requires": ["bare-metal","drivers-usb","events"],
    "target_overrides": {
        "*": {
          "target.c_lib": "std",
          "target.printf_lib": "minimal-printf",
          "platform.minimal-printf-enable-floating-point": true,
           "platform.minimal-printf-set-floating-point-max-decimals": 6          
        },
        "NUCLEO_F401RE": {                    
          "target.device_has_add": ["USBDEVICE"],
          "target.clock_source": "USE_PLL_HSE_XTAL"
        }
      }
}

Description of defect

In order to determine if somebody listens on the CAN bus there is a function tderror() which is exactly for this purpose, nice article here. The problem is that on STM32F303RE this counter always gives zero even when the can bus is disconnected. I know this mechanism works because i run the same code for the STM32F091RC and it works as expected-ich, why? because if i understad correctly the tderror counter should start from zero and with next error it should add another 8 points, but on the STM32F091 it starts with 128 (Error passive) straight away and then adds another 8. But i can put this into another issue so we don't mix this up with F303 (if this is actually an issue)

F091 log:

tderr_prev:0, tderr: 0, sent: 1
tderr_prev:0, tderr: 0, sent: 1
--- bus disconnected here ---
tderr_prev:0, tderr: 128, sent: 1
Error Passive
tderr_prev:128, tderr: 128, sent: 1
tderr_prev:128, tderr: 128, sent: 0
tderr_prev:128, tderr: 128, sent: 0
tderr_prev:128, tderr: 128, sent: 0
tderr_prev:128, tderr: 128, sent: 0
--- bus reconnected here ---
tderr_prev:128, tderr: 133, sent: 1
tderr_prev:133, tderr: 132, sent: 1
Bus recovered
tderr_prev:132, tderr: 131, sent: 1
tderr_prev:131, tderr: 130, sent: 1
tderr_prev:130, tderr: 129, sent: 1
tderr_prev:129, tderr: 128, sent: 1
tderr_prev:128, tderr: 127, sent: 1
tderr_prev:127, tderr: 126, sent: 1

F303 log

tderr_prev:0, tderr: 0, sent: 1
tderr_prev:0, tderr: 0, sent: 1
tderr_prev:0, tderr: 0, sent: 1
--- bus disconnected here ---
tderr_prev:0, tderr: 0, sent: 1
tderr_prev:0, tderr: 0, sent: 1
tderr_prev:0, tderr: 0, sent: 1
tderr_prev:0, tderr: 0, sent: 0
tderr_prev:0, tderr: 0, sent: 0
tderr_prev:0, tderr: 0, sent: 0
tderr_prev:0, tderr: 0, sent: 0
tderr_prev:0, tderr: 0, sent: 0
--- bus reconnected here ---
tderr_prev:0, tderr: 0, sent: 1
tderr_prev:0, tderr: 0, sent: 1

Please see the code below

Target(s) affected by this defect ?

STM32F3 family

Toolchain(s) (name and version) displaying this defect ?

GCC ARM 9.3.1

What version of Mbed-os are you using (tag or sha) ?

bc01a4e063bd23c31a04448d0a0525b327e102e9

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli 1.10.1

How is this defect reproduced ?

#include <mbed.h>
RawCAN can(CAN_RXD_pin, CAN_TXD_pin);

int main() {
    can.frequency(250000);
    can.mode(CAN::Normal);

    uint8_t tderr_prev = 0;
    bool bus_state = true;

    while (1) {
        CANMessage msg;
        msg.id = 0;
        msg.id |= 6 << 26; // priority
        msg.id |= 0xFF00 << 8; // SPN
        msg.id |= 0xA0; // SA
        msg.len = 8;
        msg.type = CANData;
        msg.format = CANExtended;
        memset(msg.data, 0, 8);

        int sent = can.write(msg);
        uint8_t tderr = can.tderror();
        printf("tderr_prev:%u, tderr: %u, sent: %i\n", tderr_prev, tderr, sent);

        if (tderr > 127) {
            // (maximum tderror count 255) - (each error is + 8 for counter)
            if (tderr > 247) {
                if (tderr == tderr_prev) {
                    printf("Bus Off\n");
                }

            } else {
                if (tderr >= tderr_prev) {
                    if (bus_state) {
                        bus_state = false;
                        printf("Error Passive\n");
                    }

                } else {
                    if (!bus_state) {
                        bus_state = true;
                        printf("Bus recovered\n");
                    }
                }
            }

        } else if (!bus_state) {
            bus_state = true;
            printf("Bus Active\n");
        }


        tderr_prev = tderr;

        ThisThread::sleep_for(1000ms);
    }
}

Description of defect

Using the USB mass storage device example does not work. Reading data fails and causes Linux to reset loop the device hoping it will work.

Target(s) affected by this defect ?

DISCO_F769NI

Toolchain(s) (name and version) displaying this defect ?

GCC_ARM

What version of Mbed-os are you using (tag or sha) ?

9dd6fb4495655a40645216d7abf2314c7c05f1dc with #15128 applied.

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli 1.10.5 gcc 11.2.0 Linux 5.14.6

How is this defect reproduced ?

Build and run the USB mass storage example. Wireshark supports looking at Linux USB data, which roughly shows this:

No.	Time	Source	Destination	Protocol	Length	Info
31925	492.662852	host	1.5.1	USBMS	95	SCSI: Read(10) LUN: 0x00 (LBA: 0x00000000, Len: 8)
Frame 31925: 95 bytes on wire (760 bits), 95 bytes captured (760 bits) on interface usbmon1, id 0
    Interface id: 0 (usbmon1)
    Encapsulation type: USB packets with Linux header and padding (115)
    Arrival Time: Oct  6, 2021 22:11:10.230344000 AEDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1633518670.230344000 seconds
    [Time delta from previous captured frame: 0.006633000 seconds]
    [Time delta from previous displayed frame: 0.007306000 seconds]
    [Time since reference or first frame: 492.662852000 seconds]
    Frame Number: 31925
    Frame Length: 95 bytes (760 bits)
    Capture Length: 95 bytes (760 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: usb:usbms]
USB URB
    [Source: host]
    [Destination: 1.5.1]
    URB id: 0xffff98dc1327ef00
    URB type: URB_SUBMIT ('S')
    URB transfer type: URB_BULK (0x03)
    Endpoint: 0x01, Direction: OUT
    Device: 5
    URB bus id: 1
    Device setup request: not relevant ('-')
    Data: present (0)
    URB sec: 1633518670
    URB usec: 230344
    URB status: Operation now in progress (-EINPROGRESS) (-115)
    URB length [bytes]: 31
    Data length [bytes]: 31
    [Response in: 31926]
    [bInterfaceClass: Mass Storage (0x08)]
    Unused Setup Header
    Interval: 0
    Start frame: 0
    Copy of Transfer Flags: 0x00000004, No transfer DMA map
    Number of ISO descriptors: 0
USB Mass Storage
    Signature: 0x43425355
    Tag: 0x00000011
    DataTransferLength: 4096
    Flags: 0x80
    .000 .... = Target: 0x0 (0)
    .... 0000 = LUN: 0x0
    ...0 1010 = CDB Length: 0x0a
SCSI CDB Read(10)
    [LUN: 0x0000]
    [Command Set:Direct Access Device (0x00) ]
    Opcode: Read(10) (0x28)
    Flags: 0x00
        000. .... = RDPROTECT: 0x0
        ...0 .... = DPO: Disable page out is DISABLED (cache this data)
        .... 0... = FUA: Read from cache if possible
        .... ..0. = FUA_NV: Read from volatile or non-volatile cache permitted
    Logical Block Address (LBA): 0
    ...0 0000 = Group: 0x00
    Transfer Length: 8
    Control: 0x00
        00.. .... = Vendor specific: 0x0
        ..00 0... = Reserved: 0x0
        .... .0.. = NACA: Normal ACA is not set
        .... ..0. = Obsolete: 0x0
        .... ...0 = Obsolete: 0x0

31926	492.662872	1.5.1	host	USB	64	URB_BULK out
Frame 31926: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface usbmon1, id 0
    Interface id: 0 (usbmon1)
    Encapsulation type: USB packets with Linux header and padding (115)
    Arrival Time: Oct  6, 2021 22:11:10.230364000 AEDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1633518670.230364000 seconds
    [Time delta from previous captured frame: 0.000020000 seconds]
    [Time delta from previous displayed frame: 0.000020000 seconds]
    [Time since reference or first frame: 492.662872000 seconds]
    Frame Number: 31926
    Frame Length: 64 bytes (512 bits)
    Capture Length: 64 bytes (512 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: usb]
USB URB
    [Source: 1.5.1]
    [Destination: host]
    URB id: 0xffff98dc1327ef00
    URB type: URB_COMPLETE ('C')
    URB transfer type: URB_BULK (0x03)
    Endpoint: 0x01, Direction: OUT
    Device: 5
    URB bus id: 1
    Device setup request: not relevant ('-')
    Data: not present ('>')
    URB sec: 1633518670
    URB usec: 230364
    URB status: Success (0)
    URB length [bytes]: 31
    Data length [bytes]: 0
    [Request in: 31925]
    [Time from request: 0.000020000 seconds]
    [bInterfaceClass: Mass Storage (0x08)]
    Unused Setup Header
    Interval: 0
    Start frame: 0
    Copy of Transfer Flags: 0x00000004, No transfer DMA map
    Number of ISO descriptors: 0

31927	492.662881	host	1.5.1	USB	64	URB_BULK in
Frame 31927: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface usbmon1, id 0
    Interface id: 0 (usbmon1)
    Encapsulation type: USB packets with Linux header and padding (115)
    Arrival Time: Oct  6, 2021 22:11:10.230373000 AEDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1633518670.230373000 seconds
    [Time delta from previous captured frame: 0.000009000 seconds]
    [Time delta from previous displayed frame: 0.000009000 seconds]
    [Time since reference or first frame: 492.662881000 seconds]
    Frame Number: 31927
    Frame Length: 64 bytes (512 bits)
    Capture Length: 64 bytes (512 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: usb]
USB URB
    [Source: host]
    [Destination: 1.5.1]
    URB id: 0xffff98dcd5435e00
    URB type: URB_SUBMIT ('S')
    URB transfer type: URB_BULK (0x03)
    Endpoint: 0x81, Direction: IN
    Device: 5
    URB bus id: 1
    Device setup request: not relevant ('-')
    Data: not present ('<')
    URB sec: 1633518670
    URB usec: 230373
    URB status: Operation now in progress (-EINPROGRESS) (-115)
    URB length [bytes]: 4096
    Data length [bytes]: 0
    [Response in: 32250]
    [bInterfaceClass: Mass Storage (0x08)]
    Unused Setup Header
    Interval: 0
    Start frame: 0
    Copy of Transfer Flags: 0x00000201, Short not OK, Dir IN
    Number of ISO descriptors: 0

32250	492.831667	1.5.1	host	USBMS	128	SCSI: Data In LUN: 0x00 (Read(10) Response Data) 
Frame 32250: 128 bytes on wire (1024 bits), 128 bytes captured (1024 bits) on interface usbmon1, id 0
    Interface id: 0 (usbmon1)
    Encapsulation type: USB packets with Linux header and padding (115)
    Arrival Time: Oct  6, 2021 22:11:10.399159000 AEDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1633518670.399159000 seconds
    [Time delta from previous captured frame: 0.000430000 seconds]
    [Time delta from previous displayed frame: 0.168786000 seconds]
    [Time since reference or first frame: 492.831667000 seconds]
    Frame Number: 32250
    Frame Length: 128 bytes (1024 bits)
    Capture Length: 128 bytes (1024 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: usb:usbms]
USB URB
    [Source: 1.5.1]
    [Destination: host]
    URB id: 0xffff98dcd5435e00
    URB type: URB_COMPLETE ('C')
    URB transfer type: URB_BULK (0x03)
    Endpoint: 0x81, Direction: IN
    Device: 5
    URB bus id: 1
    Device setup request: not relevant ('-')
    Data: present (0)
    URB sec: 1633518670
    URB usec: 399159
    URB status: Remote I/O error (-EREMOTEIO) (-121)
    URB length [bytes]: 64
    Data length [bytes]: 64
    [Request in: 31927]
    [Time from request: 0.168786000 seconds]
    [bInterfaceClass: Mass Storage (0x08)]
    Unused Setup Header
    Interval: 0
    Start frame: 0
    Copy of Transfer Flags: 0x00000201, Short not OK, Dir IN
    Number of ISO descriptors: 0
USB Mass Storage
SCSI Payload (Read(10) Response Data)
    [LUN: 0x0000]
    [Command Set:Direct Access Device (0x00) ]
    [SBC Opcode: Read(10) (0x28)]
    [Request in: 31925]

32251	492.831676	host	1.5.1	USB	64	URB_BULK in
Frame 32251: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface usbmon1, id 0
    Interface id: 0 (usbmon1)
    Encapsulation type: USB packets with Linux header and padding (115)
    Arrival Time: Oct  6, 2021 22:11:10.399168000 AEDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1633518670.399168000 seconds
    [Time delta from previous captured frame: 0.000009000 seconds]
    [Time delta from previous displayed frame: 0.000009000 seconds]
    [Time since reference or first frame: 492.831676000 seconds]
    Frame Number: 32251
    Frame Length: 64 bytes (512 bits)
    Capture Length: 64 bytes (512 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: usb]
USB URB
    [Source: host]
    [Destination: 1.5.1]
    URB id: 0xffff98dc1327ef00
    URB type: URB_SUBMIT ('S')
    URB transfer type: URB_BULK (0x03)
    Endpoint: 0x81, Direction: IN
    Device: 5
    URB bus id: 1
    Device setup request: not relevant ('-')
    Data: not present ('<')
    URB sec: 1633518670
    URB usec: 399168
    URB status: Operation now in progress (-EINPROGRESS) (-115)
    URB length [bytes]: 13
    Data length [bytes]: 0
    [Response in: 32728]
    [bInterfaceClass: Mass Storage (0x08)]
    Unused Setup Header
    Interval: 0
    Start frame: 0
    Copy of Transfer Flags: 0x00000204, No transfer DMA map, Dir IN
    Number of ISO descriptors: 0

32728	493.079826	1.5.1	host	USB	64	URB_BULK in
Frame 32728: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface usbmon1, id 0
    Interface id: 0 (usbmon1)
    Encapsulation type: USB packets with Linux header and padding (115)
    Arrival Time: Oct  6, 2021 22:11:10.647318000 AEDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1633518670.647318000 seconds
    [Time delta from previous captured frame: 0.000561000 seconds]
    [Time delta from previous displayed frame: 0.248150000 seconds]
    [Time since reference or first frame: 493.079826000 seconds]
    Frame Number: 32728
    Frame Length: 64 bytes (512 bits)
    Capture Length: 64 bytes (512 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: usb]
USB URB
    [Source: 1.5.1]
    [Destination: host]
    URB id: 0xffff98dc1327ef00
    URB type: URB_COMPLETE ('C')
    URB transfer type: URB_BULK (0x03)
    Endpoint: 0x81, Direction: IN
    Device: 5
    URB bus id: 1
    Device setup request: not relevant ('-')
    Data: present (0)
    URB sec: 1633518670
    URB usec: 647318
    URB status: Value too large for defined data type (-EOVERFLOW) (-75)
    URB length [bytes]: 0
    Data length [bytes]: 0
    [Request in: 32251]
    [Time from request: 0.248150000 seconds]
    [bInterfaceClass: Mass Storage (0x08)]
    Unused Setup Header
    Interval: 0
    Start frame: 0
    Copy of Transfer Flags: 0x00000204, No transfer DMA map, Dir IN
    Number of ISO descriptors: 0

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

the low level SPI write calls msp_write_data and passes data in single bytes. Sending data formats with more than 8 Bit are sending only 8 Bit with leading zeros for larger data. This PR passes the data as pointer to make the type casting depending on the bitshift value working.

Impact of changes

fix sending 16 Bit Problem as in #15113

Migration actions required

Documentation

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

urgent fix

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Allows MBED_ROM_SIZE/"target.mbed_rom_size" to go up to 0xE1000 instead of 0xE0000 if using stm32wb5x_BLE_HCILayer_fw.bin with a version >=1.12 since the install address increased from 0x080E0000 to 0x080E1000 in version 1.12.0.

Impact of changes

This assumes any future bump to major or minor version will maintain the new install address. This may be a problem if a future version reduces the install address back. See https://github.com/STMicroelectronics/STM32CubeWB/blob/master/Projects/STM32WB_Copro_Wireless_Binaries/STM32WB5x/Release_Notes.html

Migration actions required

Documentation

None

Pull request type

Target update

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

Ran the BLE_SecurityAndPrivacy example in a STM32WB55 compiled with "target.mbed_rom_size" : "0xE1000" with BLE stack version 1.12.1 and connected to nRF connect.

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

Summary of changes

Add Nucleo STM32F722ZE port

Impact of changes

Migration actions required

Documentation

Add board page

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[x] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers