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.
Related
I am trying to make some custom firmware for a MIDI controller (AKAI LPD8).
There is an STM32F102R8T6 chip in the unit.
I am trying to reach it with a programmer to wipe it, but it seems to not be responsive.
Some information and thing I have tried:
The firmware that came with the unit works, so the chip is not broken
Removed the components connected to the programming pins (PA9-PA10 and PA13-PA14)
I am able to pull BOOT0 high and have it not run the main program, but I am however not able to get a life sign using either an ST-Link2(clone) connected to PA13/14, nor a USB to serial adapter connected to PA9/PA10, so I am not sure what mode it is in
The connection has been checked, and RX-TX etc is the correct way around (but also for the sake of trying it all, I reversed the connections as well...).
Tried both the STM32CubeProgrammer and stm32flash, but none connects.
I am actually not sure if AKAI have locked the chip in such a way that you cannot even do a full chip erase and use the chip for something new? The NRST pin is strangely not doing anything to the running of the firmware either when I try to pull it low.
Is there a way to reprogram these chips when they come off of a commercial product, or are they permanently locked?
Any solution/tips?
Many of the STM32 parts have "proprietary code read-out protection" (google PCROP) which but you might be lucky and they haven't enabled it in the option bytes. Read the documentation for that and the bootloader documentation and get a good idea of what you expect it to do if it is enabled and if it isn't.
If you have a scope, try watching the SWD/JTAG pins to see if there is any response from the device. (If you aren't even sure if it is in reset then scope the crystal if there is one).
If you haven't got a scope, you might be able to to verify what it is doing by seeing if it sets the pins and pull-resistors to how they would be expected to be in the bootloader mode, eg: UART TX should be high if it is enabled, even it it isn't transmitting anything. Put a strong pull-down (~1k) on there and see if it still reads high.
After hours of trying different ways of making it work (also tried the alternate mapping of the UART port), and probed the TX pin as suggested by Tom V to no avail, I have given up working on that specific chip and ordered an upgrade from the STM32F4 family instead to replace it with. A lot more power and useful peripherals.
A bit of a non-answer to the specific question. Frustrating to not have found out what was wrong (chip or approach) but being mindful of the sunk cost fallacy, I think it was best to just replace the chip with a fresh one and start development from there.
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 encountered the following issue while using Keil MDK 5 for STM32H743.
I had a communication problem with my SPI code and after a while I found out that it was due to the Periodic Windows Update.
When it is activated, it seems that the debugger is reading regularly the SPI data register, which reads the FIFO (so changes the state of the FIFO). Consequently when the software reads the FIFO, some bytes have been "lost" (or consumed by the debugger).
Is it an expected behaviour ? Do you know if it is due to Keil or to the STM32 ?
I don't fully understand how an access from the debugger to a register is working: I guess there is a read command sent over SWD but then, internally does the access to memory go through AHB / APB like for code executing on the CPU ?
Any registers that modify behaviour by being read (such as clearing status bits) can be problematic when debugging and the registers are shown in the debug window.
The best bet is to only look at the registers when you stop (close the DR window for the peripheral), and always be aware that you may clear status bits etc.
It is the way the processor works and nothing to do with the debugger.
It is a very common debug issue with serial comms etc.
if you have DR display in your watch window (or any other similar windows on the debugger screen) and you step through the code every time you step (or generally break) the data is read.
That is the only possible reason.
I have a weird problem on hand, I never saw it before.
Yet, I'm still trying to pinpoint the problem.
I have an STM32H753VIT and a LAN8742 ethernet controller connected to it.
I run LwIP in NO-SYS mode.
It only works fine after a cold power-up, but not after a hardware reset (button or ST-LINK probe).
It runs a simple TCP echo server. If it runs, I can ping it, and it responds to a TCP client.
But after a hardware reset, I no longer can ping it, and it does not respond as an echo server.
I noticed the green (link) LED on the interface will remain off after the reset.
I could see the LAN8742_Init function executes successful after a hardware reset, but it sees no longer RX data available in the function low_level_input.
On a Nucleo-H743ZI, I run the same code, and this also works after a hardware reset.
Note the code is only slightly different as pin mapping is slightly different.
Code for well working Nucleo-H743ZI:
https://github.com/bkht/Nucleo-H743ZI_LAN8742_LwIP_NO-SYS
Code for strange behaving STM32H753VIT:
https://github.com/bkht/STM32H753VIT_LAN8742_LwIP_NO-SYS
The nRST of the MCU is connected to the nRST of the LAN8742A and a capacitor of 100nF is used to GND. I've a reset switch and I tried a Pull-up resistor, nut no luck.
I have added a reset button, and this found that a longer hardware reset does not work either.
I'm thinking in the direction of timing, or memory contents.
Has anybody ever seen such start-up behavior?
Solved, after the code that performs a software reset of the LAN8942A, I added one line to set the auto-negotiation bit (bit 12) in the BCR (0x00) register.
pObj->IO.WriteReg(pObj->DevAddr, LAN8742_BCR, LAN8742_BCR_AUTONEGO_EN);
I will update the code in github, for those people interested.
I have been having an issue in my project with LWIP. I am using a ST32F4 MCU and running with no OS. The network seems to run fine, the protocols all work, but then (usually a day or two later) the stack just stops running. It seems to happen when trying to make a new connection, but I can't confirm that because I haven't been able to locate what is causing it in the code.
Has anyone else come across this issue? I think it may be the same as this guy.
Do you call any LwIP functions from any interrupt-handlers, like UART etc?
How do you feed packets in/out of LwIP? Directly via interrupt handlers, or do you push them in from your "main-loop" ?
Lock-ups can also be signs of double free, or use-after-free of pbufs.
I also experiences that one project was unstable with wierd random locks-ups when running at the top-rated frequency of the STM32. If I clocked my STM32 at 100MHz instead of 120MHz, all my problems went away....