hi we haveseveral boards in need of the stm32L151C8t6 and we have some stock of the mcu in question the problem is that all the pcbs 'from JLCPCB' have this weird issue were the mcu is stuck and i have to manually poke thenrst pin multiple time for it to run normally "poke as in pull it to gnd for it to reset " please i need help with this i'll share some the the designs
example 1:
PCB design
example 2:
PCB design
made a dac output from 0 to max
start the program nothing happens
try to jump the nrst multiple times until it starts
using stm studio and changing a value i in the program so i can see where it stopped
video explaining
Video
Related
I am using Raspberry pi and I want to get a digital sign when a specific process runs, to trigger another measurement tools (e.g oscilloscope or spectrum analyzer) to start measure things.
I didn't find any workaround to do it (If you know any please share) so I want to create a costume scheduler.
My plan is to create a process with special priority and whenever the process gets CPU time I want to turn on a GPIO and when the process is preempted I want to turn off the GPIO.
How would you recommend to start implementing it? are there any existing open source projects which did something similar?
Any help would be appreciated.
we are using a STM32H743VIT6 on a custom board with a JLink debugger. Out of the blue the processor jumps in a state where it isn't possible to flash the ECU anymore. The board is running but nether JMem nor our IDE (uVision) are able to access or detect the controller. Has anyone else encountered this behaviour so far? Google wasn't helpful either.
It is almost impossible to archive unless you enable RDP (which is very hard to archive if it was not the intention of the programmer).
You probably have screw-up the board design. You should have pull-up resistors on the debug lines and NRST connected to the programmer.
If you do not have NRST available simple solder the wire to the NRST, and when the programming probe connects to the uC, connect it to the GND.
If the NRST line is connected to the programmer you need to select nn the configuration "Connect under Reset"
We found the answer to our problem. Like #0___________ suggested we had an error in the board design. The NRST line had a condensator which after sufficient loading was pulling the pin up and causing the board to permanently stay in Reset until it had time to unload. After a bit of soldering the problem was solved.
I'm facing an unexpected problem with stm32f103c8. I'm programming the chip and after reset, it starts to run the program, but after a few seconds the microcontroller getting mixed up and stops running the program. After that when I try to reprogram the microcontroller, IDE(IAR EWARM) tells "target held in reset state".
It's very unusual issue because sometimes when I connect nRST pin directly to the VCC(3.3V), microcontroller runs program but unfortunately the current goes over 120mA and chip breaks down finally.
I'm using STM32CubeMX to generate the codes and my programmer is STLINK V2(clone), also tried Jlink V8.0(clone) but didn't change the result.
Could it be because of the clone programmers?
Can anyone help me solve this problem?
Thanks
Never connect nRST directly to VDD/VCC. This is a bi-directional input-output which must only ever be connected to an open-drain/open-collector signal. It can be pulled low externally or from within, it must never ever be pulled or driven high other than by the internal pull-up resistor.
When your debugger or programmer has finished programming the flash and wants to start running the new program then it requires to be able to pull this line low, which it might do externally if you connect this line to it in hardware, or else it has to be able to pull it low by software using the internal reset pulse-generator. If it does this and you have tied the line high externally then you are effectively shorting out your power supply, which is the cause of the over-current condition that you have observed.
Maybe the original problem is that your counterfeit ST-Link has its reset output configured as push-pull when it should be open-drain.
I would suggest that the easiest way to proceed is to leave the nRST line unconnected and configure your programming tool to use a software reset only.
I'm having trouble with i2c communication. In my i2c bus, i have 4 boards (STM32L4 Sensortiles) and sometimes one of them blocks the bus and the others stop communicating consequently. When I reset that one that blocks the bus, all boards starting working again.
In my debugs, this bug happened when HAL_I2C_GetState(&hi2c3) returns HAL_I2C_STATE_BUSY_RX, even my others i2c functions HAL_I2C_Slave_Receive_IT and HAL_I2C_Slave_Transmit_IT returns HAL_OK:
Any ideas what Im doing wrong? Thanks.
Using libraries like HAL leads to problems like this one. Why?
HAL users feel free from knowing your hardware as magic library will do everything for you.
HAL users usually do not know how the peripheral works and how to debug it.
HAL users do not bother to go through the magic HAL function to see what the problem is.
Posting some images form debugger will not help.
What you need to do:
Get even the cheapest logic analyzer (there are $10 on ebay) and record the communication. See if the slave keeps the clock or data line low. If yes toggle the clock pin 9 times to unblock the line
If nothing helps reset the I2C peripheral using RCC register (it has to be implemented on all connected boards).
I'm working on a project that is using a Raspberry Pi with Raspbian and an SGTL5000 based sound card (FePi.) I have no problem selecting the card and getting samples in both directions - once I have configured the multiplexer to properly select line In/Out. I did this with Alsamixer. I want to automate the process so that the only step required is to run the application.
I don't see a way to do this using PyAudio/PortAudio. Is my only option the ALSA API or is there a way to do this with PyAudio (or PortAudio) that I'm not spotting?
Thanks in advance for any insight you can provide.
Oz (in DFW)
I ran into a similar problem, I wanted to automate changing mux settings but I wanted to adjust inputs not exposed by alsamixer too.
To deal with the limitations of the driver I ended up porting over the Teensy 3.x sgtl5000 control software to the pi yesterday
https://github.com/Swap-File/pi-sgtl5000
You could force feed the same commands via i2c via python.
The only downside is, once you start force feeding the sound card i2c commands, you break alsamixer (and anything else that might try to adjust it's own volume settings).