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.
Related
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).
I have an existing embedded system with an existing developed C code.
Sometimes the microSD card can lock down giving responses outside of the scope of the existing system.
I'm currently unsure why but suspect the handler in the existing system allows subsequent calls to be made too quickly.
The card is being used in Spi mode to have direct I/O.
The circuit diagram does not show any control over the power to and from the card so I cannot just reset and re-connect to the fresh Spi.
My only option seems to be finding a way to get it to reset through an Spi call, or look at creating a function to recover the sd back to its' expected state from whatever lock it is in.
With that in mind, is there a command or set of commands I can use to cause the equivalent of a reset, or to cancel whatever the microSD controller is expecting?
Looking at the SD associations' specs, the only reset reference is the CMD0 and that isn't applicable once into Spi mode.
Any thoughts are welcome, and thank you in advance.
-Chris
I am migrating to using Vivado and want to add interupt generation to my custom AXI perph. In ISE I have previously done this by using one of the templates given in the AR records (http://www.xilinx.com/support/answers/51138.htm). What is the best way to achieve this in Vivado?, do I need to add the interupt signal port and controller IP into the AXI perph in a similar manner?
Just to clarify with a simple example of what I want to acheive:
1) Send two numbers to the AXI perph
2) Does some operation (i.e. add) and puts the result in the result register
3) An interupt is generated in the perh to tell the CPU the result is ready.
The documentation is very sparse on this topic
So far I have enabled the Core0-nIRQ port on the Zynq system, I just don't know the intermediate steps to interface with this port, from the custom AXI perh.
Sam
If you are using Vivado's "Create and Package IP", click the box to "Enable interrupt support" on your peripheral.
You already enabled the interrupt on the Zynq side, so now you should be able to connect them.
I find the whole "Create Block Design" GUI to be annoying, so I just use HDL to define the top level and Vivado tcl scripts to automate the coregen runs.
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.