jeromecoutant

jeromecoutant

Member Since 6 years ago

STMicroelectronics, Le Mans, France

Experience Points
27
follower
Lessons Completed
8
follow
Lessons Completed
2
stars
Best Reply Awards
22
repos

670 contributions in the last year

Pinned
⚡ Arm Mbed OS is a platform operating system designed for the internet of things
⚡ Open source Python library for programming and debugging Arm Cortex-M microcontrollers
⚡ The tools to test and work with Mbed OS
⚡ mbed CI Test Shield
⚡ ISM43362 WiFi driver
Activity
Oct
28
21 hours ago
Activity icon
issue

jeromecoutant issue comment pyocd/pyOCD

jeromecoutant
jeromecoutant

L4S5I-IOT01A - STLink error (20): DP wait

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
  1. 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

Activity icon
issue

jeromecoutant issue comment ARMmbed/mbed-os

jeromecoutant
jeromecoutant

Power management stat : add verbosity level for MBED_SLEEP_TRACING_ENABLED

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


Activity icon
issue

jeromecoutant issue comment ARMmbed/mbed-os

jeromecoutant
jeromecoutant

Wisun: crash on TLS handshake for NUCLEO_WB55RG

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

jeromecoutant
jeromecoutant

If you have applied the patch, please raise a PR :-) Thx

Activity icon
issue

jeromecoutant issue comment ARMmbed/mbed-os

jeromecoutant
jeromecoutant

ThisThread::sleep_for never returns on Nucleo-F401RE with external crystal and bare-metal

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"
        }
      }
}
jeromecoutant
jeromecoutant

Maybe a while(true) loop is missing in main() ?

Any feedback ?

Activity icon
issue

jeromecoutant issue comment ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F303 CAN tderror() gives always zero

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);
    }
}
jeromecoutant
jeromecoutant

Hi Did you have time to check F3 board? There is no USB sharing the same pins ? There is no extra pull up/down than with F091 ?

Activity icon
issue

jeromecoutant issue comment ARMmbed/mbed-os

jeromecoutant
jeromecoutant

disco f769: USB mass storage device is broken

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
jeromecoutant
jeromecoutant

If that seems like a decent enough solution (and it does actually fix things), I'll be happy to do a PR for it.

Maybe you can start with this kind of patch ? https://github.com/jeromecoutant/mbed/commit/33f9c9cccdeff0e30da941c11190058971e1f585

Activity icon
created branch

jeromecoutant in jeromecoutant/mbed create branch DEV_USB_HS

createdAt 5 hours ago
pull request

jeromecoutant merge to ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant

MPU test is OK on my side!

PS: maybe you should squash commits related to F722 into 1, and make a separate commit for each other STM32F7 patches ?

pull request

jeromecoutant merge to ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant

MPU test is OK on my side!

Activity icon
issue

jeromecoutant issue comment ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32: fix SPI write with data >8 Bit

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


jeromecoutant
jeromecoutant

its driving me nuts. I have used the test program from @vznncv on a H743. There the known problem was shown, but also the last asynch transfer was completely missing. Then I used a F407, with different result: 3-wire does not work at all with this mix, 4-wire looks ok exept bulk write.

Note that ST SPI IP has changed with STM32H7: https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32H7/spi_device.h#L22

Oct
27
1 day ago
Activity icon
issue

jeromecoutant issue comment ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant

[] 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)

Check 'Patch update'

Thx

open pull request

jeromecoutant wants to merge ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant
open pull request

jeromecoutant wants to merge ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant

Keep lower case for file name

open pull request

jeromecoutant wants to merge ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant
pull request

jeromecoutant merge to ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant

FLASH support has to be updated to support STM32F722

You can check/cherry pick my commits from https://github.com/jeromecoutant/mbed/tree/DEV_STM32F722

pull request

jeromecoutant merge to ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant

FLASH support has to be updated to support STM32F722

You can check/cherry pick my commits from https://github.com/jeromecoutant/mbed/tree/DEV_STM32F722

Activity icon
created branch

jeromecoutant in jeromecoutant/mbed create branch DEV_STM32F722

createdAt 1 day ago
Activity icon
issue

jeromecoutant issue STMicroelectronics/STM32CubeF7

jeromecoutant
jeromecoutant

FLASH sector description is wrong for NUCLEO F722ZE

Hi

FLASH sector description is wrong for NUCLEO F722ZE: https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Projects/STM32F722ZE-Nucleo/Examples/FLASH/FLASH_EraseProgram/Inc/main.h#L33-L44

I propose:

#define ADDR_FLASH_SECTOR_0     ((uint32_t)0x08000000) /* Base @ of Sector 0, 16 Kbytes */
#define ADDR_FLASH_SECTOR_1     ((uint32_t)0x08004000) /* Base @ of Sector 1, 16 Kbytes */
#define ADDR_FLASH_SECTOR_2     ((uint32_t)0x08008000) /* Base @ of Sector 2, 16 Kbytes */
#define ADDR_FLASH_SECTOR_3     ((uint32_t)0x0800C000) /* Base @ of Sector 3, 16 Kbytes */
#define ADDR_FLASH_SECTOR_4     ((uint32_t)0x08010000) /* Base @ of Sector 4, 64 Kbytes */
#define ADDR_FLASH_SECTOR_5     ((uint32_t)0x08020000) /* Base @ of Sector 5, 128 Kbytes */
#define ADDR_FLASH_SECTOR_6     ((uint32_t)0x08040000) /* Base @ of Sector 6, 128 Kbytes */
#define ADDR_FLASH_SECTOR_7     ((uint32_t)0x08060000) /* Base @ of Sector 7, 128 Kbytes */
Oct
26
2 days ago
pull request

jeromecoutant merge to ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32WB55 HCI driver: version dependent rom size

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


open pull request

jeromecoutant wants to merge ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant

no, code is not working if you are using SPI5 :-) I think we need to move endif at line 63

pull request

jeromecoutant merge to ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


open pull request

jeromecoutant wants to merge ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant

not sure if correct, but should work as a placeholder

Please check Arduino pins with the Board User Manual...

pull request

jeromecoutant merge to ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


Activity icon
issue

jeromecoutant issue comment ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant
open pull request

jeromecoutant wants to merge ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant

There is no I2C4 for STM32F722...

I suggest to use script as explained in https://github.com/ARMmbed/mbed-os/tree/master/targets/TARGET_STM#board-specific-files-pinmap

python targets/TARGET_STM/tools/STM32_gen_PeripheralPins.py -t NUCLEO-F722ZE
pull request

jeromecoutant merge to ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


Activity icon
issue

jeromecoutant issue comment ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant

Now I'm getting an error in the emac driver, although EMAC is not listed in device_has_add array: Am I missing some kind of switch somewhere?

OK, all other STM32F7 was supporting ETHERNET, not STM32F722... So you need to add a protection in https://github.com/ARMmbed/mbed-os/blob/master/connectivity/drivers/emac/TARGET_STM/TARGET_STM32F7/stm32f7_eth_conf.c

#ifdef ETH
... // _eth_config_mac
#endif
open pull request

jeromecoutant wants to merge ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant

I think you should remove this ?

open pull request

jeromecoutant wants to merge ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant

Add it only if you have tried USB feature

pull request

jeromecoutant merge to ARMmbed/mbed-os

jeromecoutant
jeromecoutant

STM32F722ZE port

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


jeromecoutant
jeromecoutant

Hi For me this is nice work :-) Remove patches in tools directories as they are not allowed any more. I will see if I could find a nucleo around me.

Previous