MCU : STM32L496
JFlash version: v6.32i
We are facing the "Connection to target under reset failed" issue, when we try to program the board with STM32 MCU.
We were programming the board before with no issues. This error started appearing suddenly and now we are not able to program the board. When we scoped the reset pin of the MCU, the reset pin is going low when we click the connect button in the JFlash and clearly the board is resetting (We can see the firmware functionality restarting).
We tried the following:
Tied the BOOT0 pin to VDD and tried booting to the system memory and then tried programming. But this doesn't made any difference.
Tried always pulling down the reset pin to GND while trying to flash.
We have ensured that there are no issues with the track leading to the JTAG interface of the MCU.
Could you please help to resolve this situation?
Is there any possibility that the firmware currently running in the MCU could prevent the flashing and lock the device?
STM32L4 has a feature called Read-out Protection (RDP). See section 1.1 of AN4758. If your firmware application sets (intentionally or accidentally) the RDP level to 1 or 2 in the "option bytes" memory area then the SWD/JTAG port is disabled from accessing flash memory (read, write, and erase).
If the RDP is level 0 or 1 then you should be able to read the option byte memory area. If RDP is level 1 then you should be able to set it back to level 0. The flash memory will be erased when setting RDP back to level 0 but the SWD/JTAG port will get re-enabled. If the RDP level is 2 then I believe there is no way to reset it.
This is a common problem with STM32 SWD interface. For successful programming you should not power your custom board/ other hardware with the ST link power, instead you should make the GND connection common and supply from external source. And if you are using ST link only for programming and not for debugging then you should use the STM32 bootloader(easier).
Related
When connecting a Black Magic Probe to my mac i'm not able to receive any data when connecting UART RX to UART TX. I tried updating the firmware to the latest version without success.
I tried multiple Black Magic probes, both on Mac and Windows without success. The UART TX led on the board blinks when transmitting. I verified the connection was to the correct device endpoint (second interface of the device). When using an oscilloscoop I did not see and data transmitted on the TX output port.
By default the Black Magic Probe does not power the target. The Black Magic Probe uses levels shifters that require a reference voltage provided by the target to be present. Without this reference level the levels shifter buffer will not output any signals or receive any signals.
It is possible to use the 3.3V LDO on the Black Magic Probe as a reference by using this command in GDB: "monitor tpwr enable". Use the command: "monitor tpwr" to validate the target is powered by the Black Magic Probe. Please be careful the target supports 3.3V power and the total power consumption is limited. By supplying the power to the target the level shifters have a reference level and a UART loopback should work by connecting the RX and TX pin.
I'm playing around with an old Trackball I purchased from Sparkfun. My trackball powers on, but it doesn't actually work. All the lights flash, and it indicates that I've left and right clicked, but the mouse on my screen does nothing.
I want to monitor the input values of the trackball across a USB port so I can track down the problem. I've looked for code I can run on Netbeans, but came up empty handed.
Please advise
You didn't specified what OS are you using. You need dedicated driver for this device. In case of Linux you would need to write your own driver for the kernel. But first you need to have specification of protocol which this device is using over usb and also usb protocol itself. It is quite sophisticated task to do...
In case of Windows there are some programs for dumping transmission between usb host (PC) and device (trackball), but at the moment I can't give you any name of such program. In case of Linux you can dump the transmission using tcpdump or wireshark commands.
The STM32 family of microcontrollers features a read-out protection feature so proprietary code can't be read out via the debug interface (JTAG or SWD).
Using OpenOCD, how can I enable/disable the read-out protection via a SWD/JTAG interface? How secure is the RDP read-out protection?
If possible, please give an answer valid for the entire STM32 family.
RDP levels
First, you have to know which level of readout protection you want to set (refer e.g. to section 3.7.3 of the STM32F4 reference manual):
RDP level 1: This level is reversible. Once you disable it, the system memory is mass-erased and you can re-program
RDP level 2: This level is irreversible and disables the debug interface altogether. The only way of updating your firmware is via some bootloader mechanism.
Usually you want to activate RDP level 1. In order to avoid mistakes that will certainly brick the microcontroller, I will not show how to enable RDP level 2 in this answer. Refer to the reference manual for details.
Activating it using OpenOCD
The activation feature is actually built-in into OpenOCD using the lock command. Just like executing the program command to flash your firmware, you can use the stm32f1x lock command (or stm32f2x lock for STM32F2/F4) to activate it.
A typical OpenOCD configuration file would look like this (you need to flash the correct firmware before running this):
# Set RDP to level 1
init
reset halt
stm32f1x lock 0
reset halt
exit
Note that the readout-protection will only be in effect once the microcontroller is reset or powered off (that's why there's a second reset in the command sequence).
A typical OpenOCD call could look like this:
openocd -d0 -f stlink-v2.cfg -f ocd-stm32f0.cfg -f ocd-lock.cfg
where ocd-lock.cfg contains the command sequence shown above.
Once activated, you can verify that the RDP is active by trying to flash the MCU using your usual programming command sequence
Deactivating RDP
Deactivating it is just as simple: Just use stm32f1x unlock (or stm32f2x unlock for F2/F4 devices) like this:
# Set RDP to level 0
init
reset halt
stm32f1x unlock 0
reset halt
exit
How secure is it?
That's a tough question that can't really be answered without additional information. One summary answer I can give is that it's pretty secure if you assume the protection has no inherent bugs and someone uses software tools only.
One of the most popular methods of resetting the RDP bit without mass-erasing the flash is to disable the RDP with a laser. Given the fact that the STM32 family is not a family of dedicated security microcontrollers with specific countermeasures, this is rather easy if you have the right equipment and sufficient experience in this area. Even some specific security MCUs have some security issues, see e.g. the Security from the IC backside talk. However, most low-level attackers will usually refrain from the cost of doing so.
Another solution is using Segger Jlink 6.60c (or later if available)
with J-Link unlock STM32 software.
Just run it, it will notify about following: "If read protection of the device is enabled, reset the option bytes will cause a mass erase". Click OK. It will ask for device family. Enter device family (my choice was 12 for STM32L4R9ZI) and press Enter.
If all good the output will be like this:
Please select the correct device family: 12
Connecting to J-Link via USB...O.K.
Using SWD as target interface.
Target interface speed: 1000 kHz.
VTarget = 3.396V
Reset target...O.K.
Reset option bytes to factory settings...
Resetting FLASH_OPTR...
Reset target...O.K.
Reset target...O.K.
Resetting Write protection (WRP) and PCROP...O.K.
Reset target...O.K.
Option bytes reset to factory settings.
Press any key to exit.
I have an embedded system that controls a motor using pwm and some other things, I send commands through a serial connection, which is connected to a Fastrack Wavecom Supreme GSM Module. However, the module connected to the embedded system (the client), fails to send the message to the server module.
I have been able to send messages back and forth between the two wavecom modules, however, when I try and send from my PIC18F45k22 to the wavecom module, it fails.
Any ideas of what could be going wrong?
You did not specify what type of serial communication you are using. For instance, if you are using the PIC's SPI module you may be sampling on the wrong edge of the clock. There are at least 2 common SPI modes widely used and 4 all together. If you are using the PIC's UART there are "a whole bucket full" of setting that may be off. Speed, number of bits, in band signaling, out of band signaling, parity, ect.
I have a Netduino Plus with at transeiver attached via SPI. I would like to reset the transiever every time the Netduino restarts. Is it possible to programmatically power on/off the 3V3 pin?
I would recommend using a FET (controlled by one of the I/O) pins to enable/disable 3V3 power to your transceiver. When you say transceiver, I think "more than a few mA" :)
BTW, we took this feedback into account with the new Shield Base module for Netduino Go. It has an integrated FET on both 3V3 and 5V power headers, so you could enable/disable power to your shield in code. Once the new Ethernet go!bus module ships and the Shield Base comes out of beta (soon), your solution can be redeployed to Netduino Go + Shield Base with few/no code changes.
Chris
Secret Labs LLC
Looking at the circuit diagram ( http://www.netduino.com/netduinoplus/schematic.pdf ), I can see only the Micro SD Card Slot having its power controlled programmatically. You could rig up a relay to control it (via a transistor, of course) instead, or if the transceiver uses less than 130mA (the current limit of the device shown: http://www.datasheetarchive.com/BSS84W-7-F-datasheet.html) you could copy the circuit from the Netduino Plus. Buying a relay shield looks like overkill, but you might have other uses for it.
Have you looked into resetting the transceiver programmatically instead of the brute-force method of power-cycling it?
Just to provide another view. You could use a transistor powered off the netduino RESET line, this will reset the device every time the netduino reboots. Or you can just link the transistor to a spare digital pin and power it in code..
What specific SPI device are you using? You mention that it's a transceiver but we could probably provide better information if we know the exact part number. If your device requires less than 8mA the Netduino Plus specs seem to indicate that one option could be using a digital output pin as the power source.
Unfortunately Secret Labs don't use exactly the language I'd expect and call out the sink and source current maximums so I would contact them directly first to see if you risk blowing your chip. I'll see if I can get an answer from them and amend this post if/when I do.
Update: Sink and source current is the same on the Netduino. See my post on their forums about sink vs. source current for a more in depth explanation. So, if your device can run off of just a few milliamps you should be able to use a digital I/O pin to power it.
Also, a lot of devices have enable pins. You can usually reset them with that line instead of pulling the power if that helps. Sometimes with flaky hardware it is better to pull the power though.