Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32F429I Discovery debugging issue #1349

Open
ThePatrickMartin opened this issue Aug 21, 2023 · 6 comments
Open

STM32F429I Discovery debugging issue #1349

ThePatrickMartin opened this issue Aug 21, 2023 · 6 comments

Comments

@ThePatrickMartin
Copy link

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
Copy link
Member

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

@josesimoes
Copy link
Member

josesimoes commented Aug 22, 2023

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

@ThePatrickMartin
Copy link
Author

ThePatrickMartin commented Aug 22, 2023 via email

@ThePatrickMartin
Copy link
Author

ThePatrickMartin commented Aug 23, 2023

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
Copy link
Author

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
Copy link
Member

networkfusion commented Sep 29, 2023

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!

josesimoes added a commit to nanoframework/nf-interpreter that referenced this issue Jul 31, 2024
josesimoes added a commit to nanoframework/nanoframework.github.io that referenced this issue Aug 1, 2024
TerryFogg pushed a commit to TerryFogg/nf-interpreter that referenced this issue Dec 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants