STM32F429I Discovery debugging issue

[ThePatrickMartin]

Tool

Visual Studio extension

Description

Unable to debug in VS2022 using nanoFramework per the instructions here: Getting Started Guide for managed code (C#) | .NET nanoFramework Documentation

I am able to use nanoff to flash the board so that it shows up on the Devices window, but unable to debug on the board, even using the template console app which doesn't talk to the hardware itself. More specifically, when I start the debugging session in VS 2022, the output log indicates that the assemblies are deployed to the board but afterward the debugging session immediately ends - no breakpoints are hit. After that, the board no longer appears in the nanoFramework Extension's Devices list.

How to reproduce

1. Verify that both of the board's USB ports are connected to the computer and that the board is visible in the Windows Device Manager on one of the COM ports.
2. In the developer command prompt, flash the board using nanoff, specifying the appropriate target for STM32F429I Discovery.
3. Create a new console application from nanoFramework Extension template.
4. Verify that the board is listed in the Devices window in VS2022.
5. Set a breakpoint on the first line of code in the Main routine and click the green button to start a debugging session.
6. Problematic behavior is that the breakpoint is not hit and the debugging session thread ends
7. Further, the board is no longer visible in the Devices list in VS2022 and needs to be re-flashed.

Expected behaviour

Breakpoint should have been hit.

Screenshots

No response

Aditional context

Windows 10
Visual Studio 2022
nanoFramework extension
Target STM32F429I Discovery

[josesimoes]

@ThePatrickMartin can you please provide details on the hardware version of STM32F429I Discovery you're using?

[josesimoes]

For the record, the current fw has been tested against the board STM32F419I-DISCO (MB1075 B-01).

[ThePatrickMartin]

My board is MB1075-F429I-E01

…

________________________________ From: José Simões ***@***.***> Sent: Tuesday, August 22, 2023 3:54 AM To: nanoframework/Home ***@***.***> Cc: Patrick Martin ***@***.***>; Mention ***@***.***> Subject: Re: [nanoframework/Home] STM32F429I Discovery debugging issue (Issue #1349) B-For the record, the current fw has been tested against the board STM32F419I-DISCO (MB1075 B-01). — Reply to this email directly, view it on GitHub<#1349 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAPIPOEGZHDRIBXR3PCKYSLXWRXTXANCNFSM6AAAAAA3YZXKJU>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ThePatrickMartin]

ST has closed my support case, stating they don't officially support nanoFramework. I did take the liberty of asking them if they could provide any specifics on hardware differences between the two versions (B01 and E01). Let's see how magnanimous they are.

[ThePatrickMartin]

From ST MCU support:

Looks like the hardware differences are mainly related to the discovery board and STLINK and not the actual MCU chip.

Limitation from version C01 were removed:
It looks like the STLINK chip was replaced by a slight different chip
"Embed Enabled" feature was added for STLINK communication
STLINK is now connected to USART1 by default so virtual comport is enabled. This done by having SB11 and SB15 closed by default ("ON").
In addition:

1. U3: L3GD20 replaced by I3G4250D and R75, C54 added
2. Old STMPE811QTR kept and SX8651 added for two footprints, and U9, C55, and R74 added for SX8651, and original STMPE811QTR circuit kept
3. CN5 SF-TC240T-9370-T replaced by FRD240C48003-B: pin1 and pin3 for YU and YD swapped, pin8 connected with 3V
4. Updated solder bridges: – ON: SB3, SB5, SB7, SB13, SB19 – OFF: SB4, SB6, SB8, SB14, SB18
5. For BOM for SX8651: as U9 SX8651IWLTRT is soldered, added R29, R30, and R45 4.7 KΩ resistors
6. Updated CN6 footprint
7. Line added on top silkscreen for CN5 when FPC is mounted

[networkfusion]

Given the changes, it is likely possible to support using 1 USB connection now.

As a first change, the common/usbcfg.h and common/usbcfg.c should be replaced with common/serialcfg.h with a content like:

//
// Copyright (c) .NET Foundation and Contributors
// See LICENSE file in the project root for full license information.
//

// clang-format off

#ifndef SERIALCFG_H
#define SERIALCFG_H

// define which serial driver the Wire Protocol will be using 
#define SERIAL_DRIVER           SD3

#endif /* SERIALCFG_H */

/** @} */

// clang-format on

The #define SERIAL_DRIVER SD3 might need updating to match the boards expectations.

Other changes "may" be required for board.h and/or mcuconf.h.

How we handle the different hardware revisions is a different matter!