Is it possible to enable readout protection on STM32 discovery board?
First I've tried STM32F429I-DISC1 but after enabling RDP with "stm32f4x lock 0" command (I'm using Linux/OpenOCD) MCU doesn't seem to work until sending unlock command (and writing new firmware).
Then I found following statement in this board documentation: 'Known limitation:
• Activating the readout protection on the ST-LINK/V2-B target, prevents the target application from running afterwards. The target readout protection must be kept disabled on the ST-LINK/V2-B boards.'
After that I've tried TM32L100CDISCOVERY - its documentation doesn't have such limitation note, and also its ST-LINK/V2 board, not ST-LINK/V2-B. But I've got exactly same behaviour - everything works fine - LEDs blinking as I programmed, but after locking (with 'stm32lx lock 0' command and subseqyent power cycle) - target MCU doesn't do anything.
So, it looks like no one discovery board support RDP protection at all and if I want to play with this feature - I anyway need to make a custom device? Or its possible with stock demo board but I did something wrong?
The full commands sequence to lock looks so:
init
reset halt
stm32lx lock 0
reset halt
exit
.. or stm32F4x instead of stm32lx for STM32F429I board
Related
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 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've been developing a web interface for a simple raspberry pi project. It's only turning lights on and off, but I've been trying to add a dimming feature with PWM.
I'm using modWSGI with Apache, and RPi.GPIO for GPIO access. For my prototype I'm using (3) SN74HC595's in series for the LED outputs, and am trying to PWM the OE line to dim the lights.
Operating the shift registers is easy, because they hold the outputs in between updates. However, for PWM to work the GPIO.PWM instance must stay active between WSGI sessions. This is what I'm having trouble with. I've been working on this for a few days, and saw a couple similar questions here. But nothing for active objects like PWM, only simple counters and such.
My two thoughts are:
1) Use the global scope to hold the PWM object, and use PWM.ChangeDutyCycle() in the WSGI function to change brightness. This approach has worked before, but it seems like it might not here.
Or 2) Create a system level daemon (or something) and make calls to that from within my WSGI function.
Very important with mod_wsgi if you need things in memory to persist across requests, is that you must use mod_wsgi daemon mode and not embedded mode. Embedded mode is the default though, so you need to make sure you are configuring it. The default for daemon mode is single process and so requests will always hit the same process. It is still multithreaded though, so make sure you are protecting global data access/update with thread locking.
Details on embedded vs daemon mode in:
http://modwsgi.readthedocs.io/en/develop/user-guides/processes-and-threading.html
You will see some example about daemon mode in document which also explains how you should be configuring your virtual environment.
http://modwsgi.readthedocs.io/en/develop/user-guides/virtual-environments.html
For anyone looking at this in 2020:
I changed mod_wsgi to single thread mode. I'm not sure if it's related to Python, mod_wsgi, or bad juju, but it still would not last long term. After a few hours the PWM would stop at full off.
I tried rolling my own PWM daemon, but ultimately went with the pigpio module (is Joan on SE?). It's been working perfect for me.
I am working on a project using STM32F103 and I have finished development of the firmware. I use ST-Link Utility for downloading stuff to the microcontroller. When I activate read out protection on my chip, it stops working. And I need to protect my firmware. What is the problem?
Just a bit more info to the accepted answer:
From ST32F10XXX docs, section "2.4.1 Read protection":
The read protection is activated by setting the RDP option byte and
then, by applying a system reset to reload the new RDP option byte.
Note: If the read protection is set while the debugger is still
connected through JTAG/SWD, apply a POR (power-on reset) instead of a
system reset (without debugger connection).
Once the protection byte
has been programmed:
Main Flash memory read access is not allowed
except for the user code (when booting from main Flash memory itself
with the debug mode not active).
Pages 0-3 (for low- and
medium-density devices), or pages 0-1 (for high-density and
connectivity line devices) are automatically write-protected. The rest
of the memory can be programmed by the code executed from the main
Flash memory (for IAP, constant storage, etc.), but it is protected
against write/erase (but not against mass erase) in debug mode or when
booting from the embedded SRAM.
All features linked to loading code into and executing code from the embedded SRAM
are still active (JTAG/SWD and boot from embedded SRAM) and this can be used to
disable the read protection. When the read protection option byte is altered to a
memory-unprotect value, a mass erase is performed.
When booting from the embedded SRAM, Flash memory accesses through the code
and through data read using DMA1 and DMA2 are not allowed.
Flash memory access through data read using JTAG, SWV (serial wire viewer), SWD
(serial wire debug), ETM and boundary scan are not allowed
Unprotection
To disable the read protection from the embedded SRAM:
Erase the entire option byte area. As a result, the read protection code (RDP) will be
0xFF. At this stage the read protection is still enabled.
Program the correct RDP code 0x00A5 to unprotect the memory. This operation first
forces a Mass Erase of the main Flash memory.
Reset the device (POR Reset) to reload the option bytes (and the new RDP code) and,
to disable the read protection.
Note: The read protection can be disabled using the boot loader (in this case only a System Reset
is necessary to reload the option bytes). For more details refer to AN2606.
There's also a write protection on the chip, see the doc.
ADDED: STM32 readout protection has problems: https://blog.zapb.de/stm32f1-exceptional-failure/ so be aware.
You have to unlock the flash first. There should be a call in the STM32 StdPeriph library. My code looks something like this:
/* Read protect the flash. NEVER EVER set this to level 2. You can't
* write to the chip ever again after that. */
FLASH_OB_Unlock();
FLASH_OB_RDPConfig( OB_RDP_Level_1 );
if (FLASH_OB_Launch() != FLASH_COMPLETE)
{
err_printf("Error enabling RDP\n");
}
FLASH_OB_Lock();