![]() ![]() I will post an update once I have the "programmer". Perhaps as the poster suggested the USB has been damaged, however the device is meant for low power RF purposes and even has a low power generator for measuring S21, I would be surprised if RF killed the USB, *but* you never know. I need to thoroughly read the datasheet for this device. The poster tells me this will make no difference, and he appears to be correct.Īnd yes I have been lazy. ![]() I did try heating up the package but with no success. Again a big guess is that the oscillator frequency might have drifted out of spec, as hinted at in the article. (*) Since there is no crystal on the PCB, I assume that it must be using the internal RC oscillator, which is possible factory calibrated. Push comes to shove I can remove the CPU and replace with a new one. Since it was "broken" he gave it to me, since I have an interest in microcontrollers and he thought that I might be able to "fix" it. This is an open source design, and since it's release much improved versions of firmware have been released, which is why my friend wanted to connect the device to USB. The original firmware is actually working. I hope that it might be possible to burn the firmware using this programmer, but I have no idea. Additionally, the lib folder contains the FatFs library as well. The bootloader source code and corresponding header file can be found in lib/stm32-bootloader folder. Although I have familiarity with many different micros, I know virtually nothing about the STM32(*), so it will be a bit of a chance to learn. The drivers folder contains the CMSIS (Cortex Microcontroller Software Interface Standard) as well as the HAL (Hardware Abstraction Layer) drivers from ST. I have no idea if this will work, or even what the programmer can do. The SW pins are brought out to an edge connector. I have purchased a cheap gadget which apparently does SWD (OpenOCD programmer). Power State : D0 (supported: D0, D3, wake from D0)Ĭhild Device 1 : HID-konformes, vom Hersteller definiertes Gerätĭevice ID : HID\VID_0483&PID_572A\7&F3C2821&0&0000 Status : 0x0180600A (DN_DRIVER_LOADED, DN_STARTED, DN_DISABLEABLE, DN_REMOVABLE, DN_NT_ENUMERATOR, DN_NT_DRIVER) Manufacturer Info : (Standardsystemgeräte)Ĭapabilities : 0x94 (Removable, UniqueID, SurpriseRemovalOK) In that mode the USB device looks fine with STM VID (0483) and some PID 572A (read: communication/temp. I also confirmed that changing the CPU for an STM32 obtained from Farnell on one of these boards fixed the USB issue.Physically all should be well: There seems to be a demo programm running right after reset, that dimms and brightens the LED cyclically. It also rather looks to me like a large batch of these particular boards with suspect chips is now in circulation, as I have 6 boards obtained in 3 different orders, 2 from UK stock and 4 in 2 lots from China direct (all last couple of months though). I did successfully get the openCM3 CDC example project to work in VSC/Platformio (after sorting out the STlink programming issue discussed in the link) and Macbeth got the USB to work another way, but as it stands the, it looks as though the current STM32duino code and these chips are incompatible. INF file, the compatible hardware model will be displayed in the model list. Once Windows has found the required driver. The PC autoselects the correct INF file, in this case STDFU.INF. I followed the doc and got to the point where I have to change the driver. the driver directory is located in your install path (C:Program filesSTMicroelectronicsDfuSeDriver), then click OK. I have not found any of the STM32duino code (including bootloaders) to work with these chips, whatever they are. I’m trying to upgrade the firmware to the latest version. I have tested my boards and the configuration bits at 0圎00FFFC0 are a match for Macbeth's when read using using ST-Link Utility, so the manufacturer as read from the chip is not ST if I understand correctly. While the discussion is about not being able to program STM32's with STlink, it turns out that the reason it doesn't work is because the CPUID was different than that which would be read from a genuine STM32 part. The link below, second page, has more on these boards. there may of course be versions of the chip with correct markings, not STM32) that that also don't work. I have concluded that while the boards were sold as STM32F103C8T6 system minimum boards and the chips are labelled as STM32F103C8T6, they are in fact something else with STM32 markings. I was have been having problems getting USB to work with recent STM32F103C8T6 system minimum boards, getting 'device not recognised' messages and 'device descriptor request failed' message in device manager (Win 10). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |