Struggling with a rather weird problem
I am using the STM32F072 in an application that needs both USB CDC and CAN.
Currently the peripherals are working as expected. However, if the USB is connected after the CANBUS, USB wont initialize. If I connect USB first then CAN, both work fine.
USB has the higher priority (lower number) , interrupts all appear to be working. No hard faults. I know these devices share a buffer so I set the USB CDC buffer to half the default, 256B for each TX and RX.
Where do i start to debug this?
I wanted to ask question on this separate.
"However, if the USB is connected after the CANBUS, USB wont initialize" , am assuming the device in powered on already for some time doing CAN bus things and you need to plug in USB while running to do things like change values etc.
Are you doing full bring up of the USB even though it's not connected at the time or do you have a trigger mechanism to initialize USB? or is a hybrid of "set registers then do init when required" in which case maybe the register need to be set later on just before init ? I personally have often had issue with cubemx and not doing full init of USB right at the start as if connected and powered by USB.
Now in a lot of canbus related stm reverse engineering i've done of OBD devices i've noticed that on many the device is vector reset on USB connect and is still present in the stm clones like gd32f0x chip code. Most devices with a display would just now show text "USB connected" an show you the first menu(reset) , A good example here would be the MKS robin, BTT lcd devices where they reset the device but saved info to skip the logo and just displayed the text then main menu (sources on github)
You can save registers and then do reset and initialize as well , you can also force stack memory locations so they are kept too between reset (trick used by official STM DFU software+h/w firmware tool allowing full dump of any dfu based STM/GD/AIR devices because of this quirk ) , But the vector table can be your friend too , I heavily use it for crash tracing and as well as bootloader tricks and hacking stm32 devices (eg adding functions to a obd reader or causing it to spill its nand via uart/usb etc)
Another thing i ran into but i'am afraid i cant explain as i switched IDE's then was that in cubemx i would have to sometimes switch build type (debug, platform, production) , clean, rebuild, clean and switch back to original build type because some how a peripheral would just not start up right, It was mentioned once in one page that was due to windows AV scanning files so could not be cleared after code change and another said the was a no save bug and only way past was switch build type and back. this ment code changes were not applied and lots of wasted time.
I switched to VS Code and custom Make files after this as at the time I could not trace the issue in any way. I also started to use more device headers and custom written full inits for such,
this has given me more flexibility in writing code for me as most of my work was on stm 0xx,103 ,407, and the register styles are very different between them forcing me to write a more common layer between them , a example would be on 0xx device you may set a high and then a low register for clock where as on a 4xx you set one register
One final tip i would also give is whatever system you are using you must setup a good planned debug path so you can real time see registers and set breakpoints through out your code, in most case when i write something quick/simple as test or example i dont care about backend and whatever is stm cubemx/arduino/cm3 system around i will use, but when i am writing something more solid then my device folder is including all the code base used and does not change , normally here I force a makefile (can be done in windows too ) , this is from too many times i've left the backend up to my ide to update and something has changed in code or build system , stm once missed out a makefile statement that included a .o file but as there was a prior header declaring those calls __weak so it would still compile to a flashable file that "kinda worked" , this was around the time they took over providing the arduino interface (which fair call to STM was well done by them and they did the current maintainers well , even the passing of the domains to stm was well handled and no complaints about the fair treament on the stm32duino.com site owners/mods/users, i've not been banned for discussing RDP bypass techniques!)
Anyways
darkspr1te
Home
Help
Search
Login
Register
