Help Needed: Issues Programming and Communicating via USB after PCB Redesign (STM32F429ZIT6)

[edsousa84]

Hello everyone

I've hit a bit of a snag with my PCB redesign (V2) featuring an STM32F429ZIT6. While the initial version (V1) worked like a charm, some layout changes and component swaps (SN74ABT16245ADL to two SN74HCT245DWR) in V2 are causing issues with programming via DFU and USB communication.

Here's a quick rundown of my troubleshooting so far:

• JTAG/SWD Programming: Successful via STCubeProgramer Stlink, so no problems there.

• PCB Assembly: Hand-soldered all PCBs, and continuity tests for USB lines and power tracks look solid.

• DFU Programming: Jumper on BOOT0 enabled, but no luck with DFU. I'm testing on a Linux machine, using lsusb to check for the DFU or USB device in normal mode.

Attached Schematic: I've included the schematic for your reference.

Now, I'm seeking fresh perspectives and additional help:

• Crystal Signals: What should I expect on the crystal signals to ensure they're operating correctly? Any recommended frequency checks?

• Fuse Flags: Are there specific "fuse" settings that need enabling for DFU capability on a fresh chip? I want to make sure everything is configured as it should be.

• Additional Debugging Tips: Any other suggestions for new ways to debug and narrow down the issue would be greatly appreciated.

The V1 worked seamlessly, and I'm a bit stumped with the V2 hiccup. Your insights would mean a lot!

Cheers!

[AScha.3]

Just - sure, you didnt swap D+ / - ?

What telling you linux, when connect the usb ? ( see terminal -> dmesg )

+

debug (swd) is working ok ?

[edsousa84]

Hello @AScha.3 thanks for your input.

As far as I can tell no I did not swap the D+ and D- (I have used the exact same circuit as the previous version)
The D+ line is connected to the PA12 (Pin 104) and then connects to the pin 3 of the mini usb connector.
The D- line is connected to the PA11 (Pin 103) and then connects to the pin 2 of the mini usb connector.

dmesg does not issue anything about the USB device (it simply does not detect it).

dmesg output on a working V1 board:

$ sudo dmesg
[90327.020890] usb 3-1: USB disconnect, device number 73
[90328.639326] usb 3-1: new full-speed USB device number 74 using xhci_hcd
[90328.789052] usb 3-1: New USB device found, idVendor=0483, idProduct=df11, bcdDevice=22.00
[90328.789058] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[90328.789059] usb 3-1: Product: STM32  BOOTLOADER
[90328.789061] usb 3-1: Manufacturer: STMicroelectronics
[90328.789062] usb 3-1: SerialNumber: 354B324D3331
$

 dmesg on a non working board:

$ sudo dmesg
$

 
I did not try to debug the firmware yet. I will try it as soon as I possibly can (good idea)

[AScha.3]

dmesg -> nothing.  So nothing at the usb port , no connect to D+ , thats pulled hi , to start enumeration.

Check, if with boot0 hi, reset/startup: then  is D+ pulled up on your board ( about 3v + ) --- and at the plug ?

+

still unknown : debug (swd) is working ok ?

[edsousa84]

Ok so for the DFU Boot0 pin I have a jumper that I insert to put it in DFU mode. Without the jumper I read ~1.2V. With the jumper (it should enter DFU mode) it reads 3.3V

As for the D+. The board is powered by USB so I cannot check the signal before connecting the USB cable. But after I connect the cable:
GND: 0V
D+:  0V
D-: 0V
ID: 0V
VBUS: 5V


As for the debugger:
It runs but gets stuck!

It hangs on the function:  HAL_RCC_OscConfig(&RCC_OscInitStruct)
main.c:

    __HAL_RCC_PWR_CLK_ENABLE();
    __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE3);
    /** Initializes the RCC Oscillators according to the specified parameters
    * in the RCC_OscInitTypeDef structure.
    */
    RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE;
    RCC_OscInitStruct.HSEState = RCC_HSE_ON;
    RCC_OscInitStruct.HSIState = RCC_HSI_ON;
    RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
    RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
    RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
    RCC_OscInitStruct.PLL.PLLM = 4;
    RCC_OscInitStruct.PLL.PLLN = 72;
    RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
    RCC_OscInitStruct.PLL.PLLQ = 3;
    if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
    {
        Error_Handler();
    }

stm32f4xx_hal_rcc.c:

while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) == RESET)
{
    if((HAL_GetTick() - tickstart ) > HSE_TIMEOUT_VALUE)
    {
        return HAL_TIMEOUT;
    }
}

Can I assume there is a problem with some Cristal? How can I check this?

[AScha.3]

First set scale to 1:

If not working with your HSE crystal, just set (ioc Mx edit) to HSI and try connect debug then.

+

Boot0: > Without the jumper I read ~1.2V.

Thats wrong. Has to be ~ 0V , with pulldown. _Check this...or short to gnd , for run or debug ;

boot0 hi , 3.3V , only for bootloader /test , (later..).

[edsousa84]

So I checked the Boot solder on the pull down resistor it it was not soldered correctly. I fixed that, but the issue is still there.

As for the Scaling we used the values generated by the cubemx software.
Is it possible htat the HSE is not working because of some problem with the external cristal/oscilator? What kind of signal should I see with the osciloscope on the 8MHz and 32KHz  cristal/oscilators?

[AScha.3]

No - first set clk source to HSI , no LSE (disable) ,  check debug ok... ?

THEN we look for hse etc.

[JTP1]

Hello

Try to pulldown PB2 pin or connect it to Gnd, it seems to be BOOT1.

Datasheet:

Ref.manual:

Br JTP

[FBL]

Hello @edsousa84 

You can probe the clock source via MCO. It could indicate a problem with the external oscillator.