0

so I'm somewhat of a noob when it comes to anything around STM chips. I have received an STM32F042F6 chip from my school, worked with it successfully on one Windows laptop. Since then I haven't had time to tinker with it at all and I have bought a new laptop. The chip is able to connect to the old laptop just fine, can be read and programmed using STM32CubeProgrammer. Issues arise when I attempt to connect to it from the new laptop - while CubeProgrammer finds the USB device, attempting to connect prompts an error message about the device being under readout protection. (on the old laptop I have verified that the readout protection option is set to 0 - no protection)

Old laptop (running win11, connection via USB):

  • can connect via STM32CubeProgrammer (v2.11.0)
  • can read, erase, write to board

New laptop (running win11, connection via USB):

  • STM32CubeProgrammer (v2.10.0, v2.13.0) reports device under readout protection
  • attempt to connect with Readout Unprotect results in:
    • "Error: DFU connection error.Please reset the target and try again" (under version v2.10.0)
    • message prompting me to "turn off turn on device" (under v2.13.0)
  • no amount of reconnecting the device has helped

I'm not sure about the differing behaviors under those two version of CubeProgrammer on new laptop, however between those two version I have reinstalled drivers several times, so that might be the reason? The v2.11.0 that's working on my old laptop is no longer available on stm webpage (no idea why), therefore I wasn't able to download this exact same version.

I've tried to uninstall-reboot-reinstall everything stm related, including drivers. I have exported the driver being used for the board from the old laptop (using pnputil) and installed it on the new one - just to be sure that I'm running the same version. I've tried to connect via UART instead of USB to rule out cable issues (using my FlipperZero as UART to USB adapter). I'm starting to be hopeless and have no clue what the issue could be or what to do next. I'd be extremely grateful for any guidance or direction about what to try to do.

Further info:

It's not a nucleo board, it's just a standalone chip in TSSOP20 package, wire bonded to a breadboard adapter. This all sits on a breadboard with minimum extra stuff, just buttons for RESET and BOOT0, LEDs (power and extra one), and power supply + data via USB (on a daughter board); see picture below for reference.
STM32F042F6 on the page of manufacturer (I have the version in TSSOP20 packaging) MCU in question on a breadboard showing all described connections to it

Patrik Drozdík
  • 36
  • 4
  • What interface do you connect to MCU with? SWD? UART? Is it a nucleo board with built-in ST-Link debugger? If you connect via UART, you need to connect to bootloader, which needs to be activate, which, in turn, means you need correct logic levels on BOOT0 and BOOT1 upon power-on reset. – Ilya May 16 '23 at 13:18
  • Most of the time I've been connecting via USB (connected to pin17-USB_D- and pin18-USB_D+) - is there any further distinction about "what goes through" the USB (please forgive my dumbness)? I've tried UART connection on pins 8 and 9 which belong to USART2_TX and USART2_RX respectively. The working connection on my old laptop was established via USB. I don't believe this has ST-LINK support, since I have it as a standalone chip in TSSPOP20 package. Oh, and all the attempts to connect have been made after having BOOT0 triggered on power-on, so in bootloader mode. – Patrik Drozdík May 16 '23 at 16:09
  • 1
    This question doesn't seem to be about programming but rather about [Electrical Engineering](https://electronics.stackexchange.com/) which has it's own Stack Exchange – cafce25 May 16 '23 at 16:27
  • 1
    I have a theory(more like a guess). I went through bootloader application not and the reference manual, and it says when it boots into the bootloader, the USART2 is supported, as well as USB, but they share a pin, so if USART2 is activated, USB bootloader is inaccessible until reset (explicitly stated). In order for USART2 to be activated, there needs to be a byte 0x7F, which is 0x01111111, which is just a GPIO switch from low to high, which could happen when you plug in the USB cable. It could be the difference between how laptop USB controllers handle data line voltages? – Ilya May 16 '23 at 23:20
  • 1
    Could be one USB controller on a laptop isn't handling your hardware implementation of USB routing, so things on the data lines happen differently, and the system locks with USART2 and prompts to reset in cubeprogrammer 2.13 as you stated. Try adding small resistors (30-100 Ohm, I guess no point in going precise) in the middle of the data lines. You could also add 100k pulldowns on them to make them more stable on power up, it should not affect performance. And if works, then this belongs to electrical engineering. But I could be all wrong, it's a pretty big speculation – Ilya May 16 '23 at 23:24
  • @cafce25 my (admittedly quite uninformed) guess was, that this might be possibly an issue of drivers / incorrect version of tooling / something on the software side. That's why I chose to put it here on SO. I'd suggest leaving it here for a while more, I'm gonna test what Ilya suggested as soon as I can and then we'll see. What do you think? – Patrik Drozdík May 17 '23 at 13:38
  • @Ilya thanks for loads of suggestions and info, I'll try it ASAP and report back. Could you please tell me in what manual did you find the info about USART2 activation? I struggle to find it and I'd like to get more savvy at finding STM related info. Another idea I had is possibly trying a USB-C to USB-A dongle - do you think it'd address the issue you mention, or would it hit the same USB controller? – Patrik Drozdík May 17 '23 at 13:39
  • 1
    @PatrikDrozdik unless you're writing the driver / tooling that's still off topic for Stack Overflow. – cafce25 May 17 '23 at 14:12
  • 1
    @PatrikDrozdík search "STM32 bootloader application note", it has a summary on how the bootloader works on different STM MCUs. If this happens to be signal integrity issue, then it will really belong to electronics stackexchange. Yeah, my two passages of text can be boiled down to "signal integrity issue". Still, just a theory, but fits the evidence. – Ilya May 17 '23 at 14:39
  • Big thank you, I've managed to resolve the issue. After Ilya's suggestion about USB controller issue, I've plugged the chip in through USB-C hub and IT WORKS! I understand however, that this belongs to Electrical Eng., so what is the proper course of action now? I believe I should flag this question and wait for the mods to move it to EE, and only there I should answer myself how I solved it (+wait for ppl there to post more explanatory answers and accept one of those). I'd like to make this right, so please help this SO noob to not screw it up more :) – Patrik Drozdík May 18 '23 at 09:34

0 Answers0